CCIE Topic: 1.3f EIGRP Optimization, Convergence and Scalability

hey everyone charles judd here in this video we're going to take a look at the 1.3 f topic of eigrp optimization convergence and scalability we're starting to combine many of the topics that we've previously looked at in this eigrp section but some of the things i want to explore here are how we can ensure fast convergence for path failures i will look at reducing our query message propagation boundaries by using stub routing and summarization and using fr the fast reroute mechanism in eigrp slightly more complex topology here that we're working with we have nine routers all participating in named eigrp on router one if we say show iprout we'll see that we have awareness of every network segment here on this router if we say show ipeigrp topology we see that all of our eigrp information is also available we see that we have redundant paths to the 89 to 89 to 89.0 24 network and we see the same thing for the 10.5.0.0.24 network so first let's look at some ways that we can ensure fast convergence with eigrp the main ways we do this is through summarization and through stub routers both of these help reduce the query boundaries of our eigrp network so that we don't have to wait as long for query replies before we're able to converge if we go all the way over to r9 on the other side of our network and let's say show iprout you'll notice that we have separate routes for the 10.1.0 10.2.0.0 10.3 10.4 10.5 all of these are separate routes learned by eigrp and they're all available over the 79.79.79.1 interface or gig 0-0 in other words locally on this router that connects out to r7 we see all of these routes in our routing table because route summarization is not enabled for eigrp now depending on your version of ios auto summary might be enabled or disabled by default with eigrp so to show how route summarization can limit the scope of our query messages let's go to r1 and let's turn on debugging only for our query and reply messages let's say debug eigrp packets if we look at contextual help we have different options there we can say reply and query and you'll see that packet debugging is on only for those two eigrp packet types i'm going to copy this command i'm just going to paste this into all of our routers i'm going to turn that on on our entire network so we can see what's going on r5 r6 r7 r8 and r9 so now we have the ability to see what's happening anywhere we go on this network so let's go over to r4 let's say that the link between r4 and r5 goes down let's say they lose connectivity to the 10.5.0.0.24 network we know that r4 will send a query to r2 while r5 sends a query to r3 r2 and r3 will in turn send their own queries and these will continue to propagate throughout the network until we're able to find an alternate path if no one knows an alternate path these queries will reach the other edge of our network and the replies will be sent back to the appropriate neighbor indicating that we don't have an alternate path so let's mimic this situation and look at that in our debug output so here on r4 let's go under interface gig zero slash one and let's say shut let's jump over to r5 and do the same thing so now we have both of those interfaces shut down and we're already seeing some messages in our debug output if we go over to r2 and we scroll up to the beginning of this output you'll see that we received a query message on gig 0 1 which is of course coming from r4 we see a query sent out on gig zero slash zero towards r1 so we're seeing these queries propagating throughout the network if we go all the way over to the far side of our network if we go to r9 for example you'll see that we also have the same thing happening here we've received queries all the way on the other edge of our network so losing this network has triggered queries throughout our entire topology which is undesirable this network is rather small but in a large network this is going to slow down our convergence time let's look at the first way we can limit this query scope which is through summarization if i go back to r4 i'm just going to bring that interface back up same thing on r5 we'll see our adjacency reform here if i say do show iprout we should see that back in our routing table and yes we do see that network back in our routing table so that looks good so looking at our topology we can see that we can easily summarize the networks connected to r1 that are going out to r2 and r3 and that would help limit our query scope so let's do that and let's take a look let's go over to r1 and one way we can do summarization in eigrp is using the auto summarization feature to do that let's go under router eigrp my named instance is called lab we want to say address hyphen family ipv4 autonomous system one and we want to go under topology based configuration mode and here we can simply say auto hyphen summary to enable that we're going to see all of our adjacencies resync that's completely expected i'm going to just clear off the console on most of these routers so that we can see things more clearly because we do have a lot of debug messages coming into those r7 r8 and r9 okay all that's good now here on r9 let's say show iprout and we're going to see something a bit different instead of having all of those individual 10.0.0.0 networks we see a single summary route being advertised now 10.0.0.0.8. so let's see what happens now if we again shut down the interfaces on r4 and r5 i'm going to clear off a little bit of room here so we can see any potential debugging messages come in so we're still under our interface configuration mode just going to say shut on r4 and shut on r5 so if we go to r3 we are seeing our queries reach r3 they're propagating all the way over to r1 of course and if we travel across to the other side of our network we're gonna see on r6 we've received a query we've sent a reply the same thing on r7 but notice on r8 we don't have anything in our debug output if we look at r9 we're going to see the same story we are not receiving query messages on routers 8 and 9. this is because of our network summarization network summarization will stop queries that are more than one hop away from the device where the summarization is enabled for any network that matches the summarized range so in our case our queries can reach r6 and r7 but they can't go any further to reach r8 and r9 if we go back to r1 and we'll just say no auto hyphen summary and i want to show you how to perform manual summarization we do that on a per interface basis under address family configuration mode so we'll let this finish looks like everything is resynced now so let's go back a level under address family configuration mode and we can say af hyphen interface and let's start with gig 0 2 and we can say summary hyphen address followed by the summary address that we want to use we can use 10.0.0.0.8. as our summary address so we'll put that in you can see again we resync let's go under address family interface gig zero slash three now and we'll arrow up and run the exact same summary address command we get our resync messages let's go over to r6 and clear off a little bit of space and we'll say show iprout notice that we are going to see our summary address of course the 10.0.0.0.8 if we go to r2 remember we didn't configure the summary address on any interfaces facing in this direction if we say show iprout we're still going to see all of our individual networks listed there as we do in our routing table here let's go back to r1 now and let's take a look at something else we can do with a summary route which is a leak map a leak map will allow you to advertise a specific prefix within a range of your summary advertisement as well as the summary route itself so this is helpful in cases where you would still want the advantages of summary routing but maybe you still want to allow a specific route to be seen so that it's preferred over others for traffic engineering so here on r1 let's first create an access control list to identify the network we want to allow through so i'll say ip access hyphen list standard i'll call this allow i'm going to allow the 10.5.0.0 network so i'll say permit 10.5.0.0 put in our mask value and that's it for the acl now let's create a route map pointing to the acl so we'll say routes hyphen map i'll call this leak permit 10 i want to match on the ip address identified by the acl named allow now we can alter our summary address that's configured on our address family interface to allow this through so if we go to r9 on the other side of our network and i say show iprout we'll see that we only know about our summary address for all of our 10.0.0.0.8 networks let's go back to r1 and let's go under router eigrp lab we'll say address hyphen family ipv4 autonomous system one topology base actually i don't need to go under topology based i need to go under my address family interface and i'm gonna say gig zero slash two and now i can re-enter my summary address command so let's say summary hyphen address 10.0.0.0.8. if you look at contextual help we can add on the leak hyphen map keyword and we'll follow that with the name of our route map that we created which is of course leak you'll see that we had a neighbor change happen let's go under interface gig zero slash three as well and we'll run the same command we'll alter our summary address command if we go back over to r9 and again say show iprout notice this time that we're going to still see our summary address we see that here 10.0.0.0 a but we also see the network that we allowed through with our leak map the 10.5.0.0.24 network so we see our summary address along with the more specific route that we allowed to leak through another option for limiting the scope of our query messages is to configure an eigrp stub so let's say that we want to configure r6 and r7 as stub routers only advertising connected networks let's go to r6 let's go under router eigrp lab address family ipv4 autonomous system one we want to say eigrp stub and if we look at contextual help you'll see the familiar eigrp options here now if we just hit enter with no keyword by default that's going to advertise both connected and summary routes in my case i'm going to configure that for connected so let's go to r7 let's do the exact same thing we do see some debug messages here where we still have that turned on router eigrp lab address family ipv4 autonomous system 1 eigrp stub connected so now that's in place we see our adjacencies resetting because our peering info has changed and once that completes here on r7 let's say show ip route and this router still has awareness of all of the network segments that it did before we see of course our summary address we see the address allowed through by our leak map and we see all of our other networks as well however if we go back to r9 and let's again say show iprout you notice that we have a much smaller subset of those routes in our routing table all of our 10.0.0.0.8 networks are missing as well as the network allowed through with the route map we only have awareness of our own directly connected networks and those networks directly connected to both r6 and r7 so this is another way we can limit our query scope just as we looked at with manual summarization and route maps we can also leak routes through our stub routers if we want to do that so i'll show you how to do that if we go to r7 the principle is exactly the same in other words we would create an acl to identify the network we would associate that with a route map and then we would advertise it as a leak map the difference is we indicate the leak map during our stub configuration so we would be under router eigrp lab go under our address family autonomous system one we would say eigrp stub connected and if you look at contextual help we have the leak hyphen map keyword that we can add and we of course would follow that with the name of the route map that we created to allow that route through very simple one other feature to check out is something called fast reroute fast reroute or fr allows traffic to be rerouted around a failed link we already know that eigrp has the ability to switch over to a feasible successor route and to install that into the routing table in a case where the successor route fails but that convergence does take time because the feasible successor route is not in the iep routing table fast reroute can allow us to switch over to a backup route in less than 50 milliseconds this is possible because fast reroute will install the successor route into the ip routing table and it will keep the feasible successor route in the forwarding table notice that we have a different topology here and that's because i'm using csr 1000v routers which support this feature on router 1 if i say show ip yeah grp topology we'll see both of our routes over to the 34.34.34.0 network we see a route going over r2 at 12.12.12.2 and r3 at 13.13.13.2 i've changed the metrics here so that we have only one successor route which of course is going over r2 and the route over r3 will be the feasible successor if i say show ip route we'll see that we only have the route going over r2 in our ip routing table which is what we would expect if i say show iprout 343434.1 we'll see specific information about this route again letting us know that this is available over our gig one interface as we see listed here so let's configure fast reroute here on r1 and see the effect of that if we go under router eigrp lab we'll just say address hyphen family ipv4 autonomous system one we want to go under topology base and we want to use the keyword fast hyphen reroute if we look at contextual help you'll see the different options that we have listed here the one we want is per hyphen prefix and if we look at contextual help again you'll see that we can use a route map to select our prefixes or we can simply say all which is what i'm going to do in our case to do that for all of our prefixes notice that we saw a bfd syslog message bi-directional forwarding detection this is the mechanism that allows for such fast convergence times remember we explored this feature in a previous section so now if we say show iprout 343434.1 you'll notice that at the bottom we see a repair path which is the route going out of gig 2 over router 3 at 13.13.13.2 if we say show ipsef 34.34.34.1 this gives us a look at our forwarding table entry specifically for this network and again we see our next hop address listed as that of router two but we also have that repair path going over router three if we go under interface gig one and if we say shut do show iprout 34.34.34.1 you'll see that we've already failed over to the backup route notice that before i could even finish running my show command we got that bfd message letting us know that the bfd session was destroyed and of course now we see our routing entry is 13.13.13.2 going over router 3 and we don't see a backup path because of course we don't have redundant paths any longer we only have a single path to that network we have immediately failed over to the 13.13.13.2 route almost instantaneously so that's a look at eigrp optimization convergence and scalability i hope you found this content useful and i want to thank you sincerely for watching

Channel: Charles Judd

Views: 942

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, routing concepts, cisco routing, eigrp, 1.3 eigrp, section 1.3, named eigrp, 1.3d eigrp load balancing, eigrp optimization, eigrp scalability, eigrp convergence, 1.3f optimization convergence and scalability, fast reroute, IP FRR, eigrp stub router, auto summarization, auto summary, manual summarization

Id: m_t7sn18sRc

Length: 18min 47sec (1127 seconds)

Published: Fri Oct 09 2020