CCIE Topic: 1.4e OSPF LSA Throttling, SPF Throttling, and Fast Hello

hey everyone charles judd here and it's been a little while since i've gotten to release some new training so thanks for your patience with that had lots of great folks reaching out just to see how things were going so i want to assure you everything is just fine things have just been super super busy in preparation for some upcoming live courses that i have and i've also been hard at work developing some new training courses namely the cisco escort training that we'll have coming out after the first of the year so in any event i'm happy to report that my ccie studies have continued throughout all of the busyness so today i wanted to share with you some of the 1.4 e topic regarding the optimization convergence and scalability of ospf now some of these topics have been covered in prior videos under the ospf section things like metric calculation and using different area types to control lsa propagation but there are a few things that we need to wrap up before we move on to bgp and there's actually a lot under this particular section so i'm going to break this topic up into a couple of videos here i'm going to specifically look at lsa and spf throttling and the ospf fast hello mechanism first let's talk about some throttling techniques in ospf namely lsa throttling and spf throttling shortest path first spf of course refers to the dijkstra shortest path first algorithm used by ospf to find the shortest path between two nodes as you're aware ospf is a link state protocol and it uses lsas to advertise topology changes to other ospf routers so if there's a failure or topology change in the network lsas are used to allow ospf to recover and converge alternate paths this causes ospf to run the spf algorithm so why would we want to throttle these mechanisms well let's say we have an issue where we have a link flapping going up and down continuously in the network this causes a situation where we're receiving lots of lsas in a short window of time each of those triggering spf calculation and that's utilizing cpu resources it's possible that this high cpu usage can cause instability or at the very least we're wasting our cpu resources and we're slowing down the router and that's what throttling is used to circumvent these throttling techniques can delay spf calculations in the case of spf throttling and can also slow down the frequency at which lsas are generated in the case of lsa throttling it's worth noting that although this does make ospf more efficient it also increases the convergence time so that's an important consideration let's begin with spf throttling i have a very simple two router network here just a couple of routers connected to each other with an ospf configuration in place if i say show ip ospf neighbor you're going to see that i have a full adjacency with the other router nothing very complicated here at all so let's start by going under global configuration mode we want to go under our ospf process so i'll say router ospf 1 and let's use the command timers throttle and if we look at contextual help you'll see that we have both lsa and spf options so let's start with spf and let's look at contextual help once again we're going to configure three timer values overall for this the start timer the hold timer and the maximum weight timer first here is the start timer this is how long the router will wait to begin spf calculations after the initial topology change lsa is received and by default that's set to 5000 milliseconds i'm just going to set that really low here as an example i'll set that to 5 milliseconds and if we look at contextual help again next we have our hold timer this is how long the router will wait until the next spf calculation occurs so this is really where the throttling of spf calculation happens i'm going to set that to 10 000 milliseconds in this case and so what i'm saying so far is after we receive a topology change lsa the router is going to wait five milliseconds then it's going to perform the spf calculation and additionally i'm saying there should not be another spf calculation occur until this 10 000 millisecond hold timer expires so what happens if we have a link flapping and we do receive more lsas during this 10 000 millisecond window what's going to happen is our hold timer is going to double so the whole timer would automatically be set to 20 000 milliseconds in my case if we receive another lsa before this whole timer expires then it would jump up to 40 000 milliseconds and so on so let's look at contextual help and you'll see that we can limit this with our third timer the maximum weight timer this is the maximum amount of time the rider will wait between two spf calculations so in my case i'll just set that to 90 000 milliseconds so if we have a link that's flapping and we're receiving multiple lsas which continue to double our weight timers the maximum value that we can reach in this configuration when that timer is being doubled is 90 000 milliseconds so once we cross the 90 000 millisecond threshold regardless of what's happening the next spf calculation is going to take place so under normal operating conditions we would receive an lsa we would start spf calculation after 5 milliseconds we would wait for 10 000 milliseconds and if we didn't receive another lsa then the timers would reset and it would continue to operate in this manner but if we have an issue with flapping we'll receive that lsa we'll still wait our five milliseconds to start spf calculation then we start our 10 000 millisecond wait timer because of the flapping issue we're going to still receive lsas it's going to double the weight timer to 20 040 000 and eventually we'll reach the maximum weight timer after which it's going to perform the second spf calculation so the question is what happens to these timers if we resolve the issue how do those resets well whatever we configure our maximum timer at which you can see here in this case is 90 000 milliseconds whatever we set that to once double this amount of time has elapsed without an lsa being received the router is going to reset all the timers back to their configured values so in our case if we pass 180 milliseconds without an lsa being received the timer is going to be reset and that way timer is going to go all the way back to 10 000 milliseconds as we would expect so let's go back here and let's take a look at those values let's say show ip ospf pipe 2 section including spf so this is going to get us a very specific output you can see our initial spf schedule delay which is the start timer of 5 milliseconds that we configured we see our minimum hold time value of 10 000 milliseconds this is our actual hold timer and then we see our maximum wait time listed here at 90 000 milliseconds so let's go under back under router ospf 1 and let's take a look at lsa throttling now this of course allows us to change the frequency of lsa creation if we're having stability issues in the network this is enabled by default but we can customize that to our needs and just like with the spf timers we're going to have three distinct pieces we have the start interval the hold interval and the maximum interval so let's once again say timers throttle and of course we'll see our two options this time we want to choose lsa and we'll take a look at our contextual help so by default this is set to zero meaning the first lsa is always sent immediately when there is a topology change and i'm actually just going to leave that in place i'm going to choose zero next we have our weight timer and i'm going to make that 10 000 milliseconds just as with spf this is the amount of time we wait for the same lsa to be sent again and then finally we're going to see the maximum weight timer which is the maximum amount of time between identical lsas and i'll set that to 45 000 milliseconds this works just like spf in the way that the timer doubles so if we have an event that has created an lsa and it's causing the same lsa to be generated a second time before our 10 000 millisecond hold time expires then it's going to double that timer so if we have an event that has created an lsa and it's causing the same lsa to be created a second time before this whole timer expires the whole timer is going to be doubled to 20 000 milliseconds if the lsa is generated a third time it's going to double again to 40 000 milliseconds and it's going to do that over and over until the maximum wait time is reached by the way when i say identical lsas lsas are considered to be the same if they share the same lsa id number the same lsa type and if they are from the same advertising router so i'm going to hit enter here and we also have an additional command we can use we can say timers lsa arrival and this is going to allow us to set the minimum interval that must pass before we accept the same lsa by default this is set to a value of one thousand milliseconds cisco recommends that if we change this value the value should be configured as less than or equal to the hold interval that we previously configured so in my case you can see our previous hold interval of 10 000 milliseconds so we would want to set this to a maximum value of 10 000 milliseconds and what happens is if we have the same lsa arrive sooner than the interval configured here that lsa is going to be dropped i'm just going to set that to the default value of 1000 milliseconds let's break out of here and we can verify this with the command show ip ospf type 2 section including lsa and you can see our initial delay listed here our initial lsa throttle delay of zero milliseconds you can also see our minimum hold time value that we configured ten thousand milliseconds and of course our maximum weight timer of 45 000 milliseconds one more feature i want to show you is the ospf fast hello feature this is a way that we can achieve faster convergence time by setting our hello packet intervals in the sub second range this is done on a per interface basis and the command it may be a little confusing it's not super intuitive so let's go under interface gig zero slash zero and let's say ipospf and the option we want to use is dead hyphen interval maybe not what you'd expect to see when we're setting a fast hello packet but if we look at contextual help here you'll see we can set that to a value in seconds as we normally would or we can use the keyword minimal to set that to one second and that's what we want to do now if we look at contextual help after this you'll see that we have an additional keyword hello hyphen multiplier so if we look at contextual help for that particular item you'll see that we can use this multiplier value to indicate how many hello packets we want to send per second and that's going to give us our fast hello sub second range so here if i say five that means we're going to send five hello packets every second now if i hit enter we're eventually going to see our ospf adjacency go down because the dead interval must be consistent on the segment whether that is with fast hello packets or any other normal value that we might use it's also worth noting that the hello multiplier value does not have to be set the same for the entire segment so let's break out of here and we can verify by saying show ip ospf interface gig zero slash zero and you can see here under our timer intervals configured section by the way we just saw our adjacency go down because we need to configure the dead timer on the other side as well but we see our timer intervals configured output here telling us that our hello timer is at 200 milliseconds or in other words five hello packets per second and our dead timer is set to one second exactly what we'd expect to see so that's a look at lsa throttling spf throttling and ospf fast hello packets i hope you found this content useful and i want to thank you sincerely for watching

Channel: Charles Judd

Views: 1,124

Keywords: cisco, ccie, cisco enarsi, ccie enterprise infrastructure, cisco enarsi 300-410, cisco encor 350-401, ccie lab, my ccie journey, ccie training, ccie blueprint, section 1.4, 1.4e ospf optimization convergence and scalability, lsa throttling, link state advertisement, shortest path first, spf throtttling, spf tuning, fast hello

Id: kp4i7D87efw

Length: 13min 41sec (821 seconds)

Published: Fri Nov 06 2020