Obscure protocol features (OSPF/BGP)

Hello, i am looking for some help around obscure protocol features that are touched on so very lightly or far and few between that i have some trouble retaining their exact use, and sometimes in cases like BGP where there are a few things that are very similar.

OSPF
-timers, my issue is normally around the wording of the question and what/how a specific timer is tweaked when they often look the same when going to configure
-obscure features that may look alike when worded in a question and i always find myself knowing both options but guessing at the correct one.
BGP
-many of the BGP table walking/scan/advertisement and the wording around the question that helps select the correct choice.
-obscure features, as with the OSPF ones above i find myself guessing quite a few times but knowing that many different options do exist.

I know this is somewhat of a vague question but after revisting INE Vol1 workbooks, ATC videos and other various books/resources im just having an issue with these very few things and any help would be appreciated on resources or guidance to help grab on and remember these topics.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

fredrikjj

sea_turtle wrote: »

OSPF
-timers, my issue is normally around the wording of the question and what/how a specific timer is tweaked when they often look the same when going to configure
-obscure features that may look alike when worded in a question and i always find myself knowing both options but guessing at the correct one.

I'm kind of struggling with this myself, but I doubt there's any shortcut. You just need to know all the timers and what they do.

Any specific timers that you want to discuss?

fredrikjj

Obscure OSPF Timers Part 1,

timers pacing lsa-group

Every LSA has a maximum age of 60 minutes, and if that age is reached, it is removed from the database. To prevent this from happening each LSA is reflooded by the originator every 30 minutes. Early in OSPF's history in IOS, all LSAs were refreshed at the same time which caused a spike in CPU and bandwidth usage every 30 minutes, and potentially overloading weaker routers. To prevent this from happening, each LSA is refreshed based on its own individual age. However, treating each LSA completely independently would be inefficient because you would be constantly processing OSPF packets and sending very little data in each packet. Instead, LSAs that are ready to be refreshed are grouped together and sent all at once according to the group pacing timer. The default is 240 seconds. Sources say that you could lower this timer if your LSDB is absolutely massive to the point where you would accumulate too many LSAs to be refreshed in 240 seconds.

PS.
This timer also controls how LSAs are checksummed. I assume that this is to spread the CPU load from that activity.

fredrikjj

Obscure OSPF Timers Part 2,

timers pacing flood

This timer is conceptually similar to the previous one, except that it deals with how LSAs are sent out interfaces in a more general sense. Each interface has a list of LSAs that are to be sent out (the 'flood list'), and instead of sending as soon as possible, LSAs are grouped together and sent every 33 ms by default. This is a CPU and bandwidth optimization if multiple LSAs need to be sent because if LSAs were sent immediately they would naturally require their own OSPF packet and IP packet, packets that would be very small.

When would you change with this timer? If you have a need to speed up convergence and you don't anticipate that lowering the timer would cause CPU issues on your routers. Remember, when an event happens that requires OSPF to converge (i.e. run SPF), the LSA that has been changed must be flooded throughout the area. The 33 ms pacing on each interface would add up. Minmum value is 5 ms. I imagine that it would be safe to run the minimum value on a modern router, but I really have no idea.

to be continued...

fredrikjj

Obscure OSPF Timers Part 3,

timers pacing retransmission

This timer has the same function as the previous one, but it specifically groups retransmissions of unacknowledged LSAs. It defaults to 66 ms, but it's less obvious to me when you would want to lower this one, and what the effect would be. It wouldn't really have a major effect on convergence because the limiting factor here is the time from when the LSA was first sent to when the router decided that it is unacknowledged (retransmit timer). If you actually have unacknowledged LSAs, you probably have an issue in your network and probably don't want to retransmit a bunch of tiny OSPF packets.

fredrikjj

Obscure OSPF Timers, part 4

interface command, ip ospf transmit-delay

I imagine that this is the most useless timer in modern OSPF. Essentially, it adds a set time to the age of all LSAs that are sent out the interface. The idea is that if you have an impossibly slow link, setting this timer allows you to take into account the time it actually takes to send the LSA. Even if you do have a slow link and it takes a few seconds to the send the LSA, I don't see what adding a few seconds to the age time would do.

sea_turtle

hi there and thanks for the help, i am in the process of finding some of the verbiage i am running into on practice exams for the OSPF timers.

fredrikjj

Obscure OSPF Timers, part 5

interface command, ip ospf dead-interval minimal hello-multiplier (aka. "fast hellos")

This probably isn't particularly obscure but I decided to add to the list anyway. The normal OSPF hello timer has a minimum value of 1 second. Using the dead-interval minimal command sets the dead interval to 1 second and the hello-multiplier specifies how many hellos are sent within this one second. What's strange about this feature is that you are limited to a one second dead interval, but you are allowed to send a hello every 50 ms with the maximum hello-multiplier (20). Why is this strange? Well, why would you need to refresh a particular hold time that often? The point of sending multiple keepalives within a particular hold time is to prevent your neighbor relationship from going down if one, two or three keepalives are lost in transit. If you lose more than that, your link is probably of such a poor quality anyway that the neighbor should go down. Feel free to inform me why you would ever send 20 hellos per second with a 1 second dead interval.

sea_turtle

here is a good example:

• the OSPF database is growing quickly, and the router spends
considerable time on the database maintenance.
• Configure the router so that OSPF LSA are grouped, checksummed, and max
aged six times more often than by default.
• In order to protect the router against flooding with the same LSA during network
instability times, ensure it holds for twice the default interval before
accepting the same LSA again from its peers.

answer:

router ospf 1
timers lsa arrival 2000
timers pacing lsa-group 40

i know where to find the defaults under a "sh ip ospf <pid>" but when it comes to trying to decipher what EXACTLY is needed im just at a loss

sea_turtle

also i have read this a few times:

Tuning OSPF Performance

but again its only helped me so much.

fredrikjj

I don't really see the issue with that question as long as you know what all the timers do.

sea_turtle

after reading your posts and the fact that it is fresh on my brain at this exact moment it does make more sense.

may i ask where you pulled the definitions from? and if you happen to have any that relate to more obscure bgp features?

also ty

fredrikjj

I wrote the posts based on various sources, the mind map that I have, some cisco documents, and my own unsubstantiated ideas. I'm actually curious about how many timers OSPF has so I'll cover a few more of them tomorrow I think.

sea_turtle

here is a BGP one i was just burned on:

-router D will be added to ibgp soon, configure these new device as part of the peer group, however, do not
allow router A to attempt to initiate the BGP session.

i configured on router A:

"neighbor d.d.d.d transport connection-mode passive"

the correct answer was:

"neighbor d.d.d.d shutdown"