The following lab write-up will cover some of the basics of EIGRP and its configuration. A caution to casual readers - this is a long post! You've been warned.
This is a pretty simple lab topology, containing a remote site router (Branch1) with redundant connectivity to two WAN edge routers (DR1 and DR2). Refer to the picture of network topology. DR1 and DR2 share a LAN segment with a host PC 192.168.10.25.
This lab will focus on the ability for Branch1 to reach 192.168.10.0/24 with the Host PC. Let's start with our base configurations for reach router:
Branch1:
| ! interface Loopback0 ip address 172.16.0.1 255.255.255.0 ! interface Loopback1 ip address 172.16.9.129 255.255.255.192 ! interface Serial1/0 ip address 10.255.0.3 255.255.255.254 serial restart-delay 0 ! interface Ethernet2/0 ip address 10.255.0.1 255.255.255.254 duplex full ! router eigrp 10 network 10.255.0.0 0.0.0.1 network 10.255.0.2 0.0.0.1 network 172.16.0.0 0.0.0.255 network 172.16.9.128 0.0.0.63 no auto-summary eigrp router-id 172.16.0.1 |
DR1:
| ! interface Loopback0 ip address 10.255.255.1 255.255.255.255 ! interface Ethernet1/0 ip address 10.255.0.0 255.255.255.254 duplex full ! interface GigabitEthernet2/0 ip address 192.168.10.3 255.255.255.0 negotiation auto ! router eigrp 10 network 10.255.0.0 0.0.0.1 network 10.255.255.1 0.0.0.0 network 192.168.10.0 no auto-summary eigrp router-id 10.255.255.1 |
DR2:
| ! interface Loopback0 ip address 10.255.255.2 255.255.255.255 ! interface Serial1/0 ip address 10.255.0.2 255.255.255.254 serial restart-delay 0 ! interface GigabitEthernet2/0 ip address 192.168.10.2 255.255.255.0 delay 3000 negotiation auto ! router eigrp 10 network 10.255.0.2 0.0.0.1 network 10.255.255.2 0.0.0.0 network 192.168.10.0 no auto-summary eigrp router-id 10.255.255.2 |
Note that it's a pretty basic EIGRP configuration, with exception to the fact that I have added a delay to DR2's LAN interface. This was simply to make my basic lab environment have more variety in the EIGRP reported distances.
Branch1's EIGRP routing, at the start of lab:
| Branch1#show ip route eigrp D 192.168.10.0/24 [90/281856] via 10.255.0.0, 00:18:41, Ethernet2/0 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks D 10.255.255.2/32 [90/409856] via 10.255.0.0, 00:21:53, Ethernet2/0 D 10.255.255.1/32 [90/409600] via 10.255.0.0, 00:18:41, Ethernet2/0 |
Briefly looking at the routes, it is obvious that E2/0 is preferred. Let's check EIGRP topology:
| Branch1#show ip eigrp topology IP-EIGRP Topology Table for AS(10)/ID(172.16.0.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 10.255.255.2/32, 1 successors, FD is 409856 via 10.255.0.0 (409856/130816), Ethernet2/0 via 10.255.0.2 (2297856/128256), Serial1/0 P 10.255.255.1/32, 1 successors, FD is 409600 via 10.255.0.0 (409600/128256), Ethernet2/0 P 172.16.9.128/26, 1 successors, FD is 128256 via Connected, Loopback1 P 192.168.10.0/24, 1 successors, FD is 281856 via 10.255.0.0 (281856/2816), Ethernet2/0 P 172.16.0.0/24, 1 successors, FD is 128256 via Connected, Loopback0 P 10.255.0.0/31, 1 successors, FD is 281600 via Connected, Ethernet2/0 P 10.255.0.2/31, 1 successors, FD is 2169856 via Connected, Serial1/0 |
The route that we care most about - 192.168.10.0/24 - notice there is not a feasible successor. Recall that EIGRP calls the best route a successor route, and if there is no feasible successor, the router must go "active" in order to find a next best route in the event that it's current successor route disappears. This equates to extra convergence time!
So the first question, is there another route for this subnet?
| Branch1#show ip eigrp topology all-links | section 192.168.10.0 P 192.168.10.0/24, 1 successors, FD is 281856, serno 8 via 10.255.0.0 (281856/2816), Ethernet2/0 via 10.255.0.2 (2937856/770560), Serial1/0, serno 13 |
And the answer is yes. So why isn't it a feasible successor route? The answer to that lies in the feasibility condition. Simply stated, if the Reported Distance (RD) of an alternate route is less than the Feasible Distance of the current successor route, then it becomes a feasible successor route. The purpose of meeting this condition is that it guarantees that the alternate path will be loop-free.
Note that the current successor routes feasible distance (FD) is 281856, and the alternate route's RD is 770560. Since the alternate route's RD is more than twice the successor route's FD, it is NOT a feasible successor. In order to improve convergence time, though, we can fix this by modifying metrics to make it meet the condition.
Let's create an offset-list to artificially raise the metric on the current successor route, in order to make the feasibility condition be satisfied! Note that other methods can be used to modify metrics (such as modifying delay, as done in the base lab config in DR2), but the offset-list is easier math. :)
| Branch1(config)#ip access-list standard ACL-eigrp-offset Branch1(config-std-nacl)#10 permit 192.168.10.0 Branch1(config-std-nacl)#exit Branch1(config)#router eigrp 10 Branch1(config-router)#offset-list ACL-eigrp-offset in 488705 e2/0 Branch1(config-router)#end |
Ok, if my basic math works out, we should now see a feasible successor:
| Branch1#show ip eigrp topology | section 192.168.10.0 P 192.168.10.0/24, 1 successors, FD is 281856 via 10.255.0.0 (770561/2816), Ethernet2/0 |
Well, wait, there's still just the one successor! Notice the FD is still shown as 281856, even though in the "via 10.255.0.0" line it shows the appropriate 770561 value we expect. Don't worry, clearing the eigrp neighborship will fix that issue:
| Branch1#clear ip eigrp neighbors e2/0 Branch1#show ip eigrp topology | section 192.168.10.0 P 192.168.10.0/24, 1 successors, FD is 770561 via 10.255.0.0 (770561/2816), Ethernet2/0 via 10.255.0.2 (2937856/770560), Serial1/0, serno 13 Branch1# |
Hey, much better! We now have a feasible successor. This means that if Eth2/0 were to fail, convergence to Ser1/0 would be very quick.
So, with two routes in the topology table, does this also mean we'll have two routes in the routing table? No, EIGRP takes the lowest metric route (successor route) and considers that alone to put into the routing table. The beauty of EIGRP, though, is that it can easily load-share across non-equal links. This requires two things: maximum-paths greater than 1, and a variance multiplier. By default, the version of IOS in my lab sets the maximum-paths to 4.
The way the variance multiplier works, is that if a feasible successor's calculated FD is less than the value of (successor route * variance), then it is considered an equal cost route and is also considered equally for insertion into the routing table. Note that this only works for feasible successors -- so if we did not keep our offset list, it wouldn't matter how high we made our variance.
Our successor route's FD is 770561, whereas our feasible successor route's FD is 2937856. We need to quadruple our successor route's FD to bump it over our feasible successor's FD. If we set variance to 4, we should see both routes enter the routing table:
| Branch1(config)#router eigrp 10 Branch1(config-router)#variance 4 Branch1(config-router)#end Branch1#show ip route eigrp D 192.168.10.0/24 [90/2937856] via 10.255.0.2, 00:00:21, Serial1/0 [90/770561] via 10.255.0.0, 00:00:21, Ethernet2/0 |
We can also confirm that both routes will be used by checking CEF:
| Branch1#show ip cef exact-route 172.16.9.131 192.168.10.25 172.16.9.131 -> 192.168.10.25 => IP adj out of Ethernet2/0, addr 10.255.0.0 Branch1#show ip cef exact-route 172.16.9.131 192.168.10.1 172.16.9.131 -> 192.168.10.1 => IP adj out of Serial1/0 |
To review thus far, we have been working on our Branch router in order to not only avoid going into "Active" mode in the event of our primary link failure, but we have also configured both links to be active for added bandwidth.
Let's touch on a couple more EIGRP topics before calling it quits. The branch router has no business ever being a transit node for routing between "headquarters" -- so let's make sure that's not possible. This can be done by configuring the branch router as an EIGRP stub. The stub router won't advertise remotely-learned subnets, which keeps it from being used as transit. Another benefit is that it reduces the workload on the DR's in the event they go "active" on a prefix, as they will no longer send Query's to a stub.
We can make this configuration change faily easily, by adding "eigrp stub connected" to Branch1's EIGRP config. This means that it will only advertise connected networks with a matching network statement. Simple stuff. Note the output on DR1 after making the change on Branch1:
| DR1#show ip eigrp neighbors detail IP-EIGRP neighbors for process 10 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 10.255.0.1 Et1/0 10 00:03:08 53 318 0 47 Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 3 Stub Peer Advertising ( CONNECTED ) Routes Suppressing queries |
Finally, we can work to reduce the routing table size by manually summarizing routes. Let's reconfigure the stub router to advertise both connected and summary routes, and then add in some summarizations. Note that reconfiguring stub configuration will drop all neighbors, and adding a summary-address to an interface will drop all neighbors on that interface.
| Branch1(config)#router eigrp 10 Branch1(config-router)#eigrp stub connected summary Branch1(config)#int s1/0 Branch1(config-if)#ip summary-address eigrp 10 172.16.0.0 255.255.0.0 Branch1(config)#int e2/0 Branch1(config-if)#ip summary-address eigrp 10 172.16.0.0 255.255.0.0 Branch1(config-if)#end Branch1# |
We can validate our change worked by looking at the routing table at one of the DR's:
| DR1#show ip route eigrp D 172.16.0.0/16 [90/409600] via 10.255.0.1, 00:03:48, Ethernet1/0 |
Let's summarize towards the branch site too. We can keep it simple by sending a default route. We'll set the summary-address on both DR's, then look at the EIGRP topology on the Branch router:
| ! DR1 -- DR1#config t Enter configuration commands, one per line. End with CNTL/Z. DR1(config)#int e1/0 DR1(config-if)#ip summary-address eigrp 10 0.0.0.0 0.0.0.0 DR1(config-if)#end DR1# ! DR2 -- DR2#config t Enter configuration commands, one per line. End with CNTL/Z. DR2(config)#int s1/0 DR2(config-if)#ip summary-address eigrp 10 0.0.0.0 0.0.0.0 DR2(config-if)#end DR2# ! Branch1 -- Branch1#show ip eigrp topology IP-EIGRP Topology Table for AS(10)/ID(172.16.0.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 0.0.0.0/0, 1 successors, FD is 281856 via 10.255.0.0 (281856/2816), Ethernet2/0 via 10.255.0.2 (2297856/128256), Serial1/0 |
Note that we have a feasible successor, but our variance of 4 no longer works. If we bump it to 9 (9*281856 > 2297856) then we should see both routes in the routing table:
| Branch1#show ip route eigrp 172.16.0.0/16 is variably subnetted, 3 subnets, 3 masks D 172.16.0.0/16 is a summary, 00:00:09, Null0 D* 0.0.0.0/0 [90/2297856] via 10.255.0.2, 00:00:09, Serial1/0 [90/281856] via 10.255.0.0, 00:00:09, Ethernet2/0 Branch1# |
Throughout this lab, we've played with influencing routes, unequal-cost load balancing, stub configuration, and route summarization. If you have questions, comments, or corrections, please feel free to comment. Thanks!
No comments:
Post a Comment