02-04-2014 02:00 AM - edited 03-07-2019 05:59 PM
Hi ..After losing the current successor ,The fs selected as a successor suddenly old successor become acive is this
old successor will became a successor ? if it happen How ?
Solved! Go to Solution.
02-04-2014 11:56 PM
Hi Anand,
The change is immediate as soon as the update is received by EIGRP. I made a quick lab to demonstrate for you. This is the topology:
R1 is announcing 11.11.11.0/24 to the other routes via EIGRP. I have put a delay on R2 f0/0 to make that path slightly worse than the one via R3. I am also using NTP to synchronize the clocks for more accurate time stamps.
This is the current routing table on R4.
R4#sh ip route 11.11.11.0
Routing entry for 11.11.11.0/24
Known via "eigrp 1", distance 90, metric 435200, type internal
Redistributing via eigrp 1
Last update from 34.34.34.3 on FastEthernet0/1, 00:08:08 ago
Routing Descriptor Blocks:
* 34.34.34.3, from 34.34.34.3, 00:08:08 ago, via FastEthernet0/1
Route metric is 435200, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
If we look in the topology table we should have a path via R2 as well.
R4#sh ip eigrp topology 11.11.11.0/24
IP-EIGRP (AS 1): Topology entry for 11.11.11.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 435200
Routing Descriptor Blocks:
34.34.34.3 (FastEthernet0/1), from 34.34.34.3, Send flag is 0x0
Composite metric is (435200/409600), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 7000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
24.24.24.2 (FastEthernet0/0), from 24.24.24.2, Send flag is 0x0
Composite metric is (435456/409856), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 7010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Which we have. The secondary route meets the feasibility condition, essentially meaning that R2 is closer to the destination network than R4 is, making it loop free.
Now I will shutdown the interface on R3 facing R1, I will debug IP routing on R4 to see when the route gets installed.
R3(config)#int f0/0
R3(config-if)#sh
R3(config-if)#
Feb 5 08:47:25.981: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 13.13.13.1 (FastEthernet0/0) is down: interface down
R3(config-if)#
Feb 5 08:47:26.018: RT: delete route to 11.11.11.0 via 34.34.34.3, eigrp metric [90/435200]
Feb 5 08:47:26.022: RT: no routes to 11.11.11.0
Feb 5 08:47:26.022: RT: NET-RED 11.11.11.0/24
Feb 5 08:47:26.022: RT: delete subnet route to 11.11.11.0/24
Feb 5 08:47:26.026: RT: NET-RED 11.11.11.0/24
Feb 5 08:47:26.026: RT: delete network route to 11.0.0.0
Feb 5 08:47:26.026: RT: NET-RED 11.0.0.0/8
Feb 5 08:47:26.030: RT: add 11.11.11.0/24 via 24.24.24.2, eigrp metric [90/435456]
Feb 5 08:47:26.030: RT: NET-RED 11.11.11.0/24
You can see that the update was very fast. Only 51 ms to install the FS, one of the advantages of EIGRP. Now let's bring the successor back again.
R3(config-if)#no shut
R3(config-if)#
Feb 5 08:50:29.251: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 13.13.13.1 (FastEthernet0/0) is up: new adjacency
Feb 5 08:50:31.353: RT: del 11.11.11.0/24 via 24.24.24.2, eigrp metric [90/435456]
Feb 5 08:50:31.357: RT: add 11.11.11.0/24 via 34.34.34.3, eigrp metric [90/435200]
Feb 5 08:50:31.357: RT: NET-RED 11.11.11.0/24
It took a bit longer to update this time but it was still quite fast. So the key here is that updates will trigger change to RIB immediately.
In theory this could be a problem if there is an interface flapping in the path betwen source and destination. There are techniques to mitigate this such as IP dampening.
Daniel Dib
CCIE #37149
Please rate helpful posts.
02-04-2014 03:10 AM
Not sure what you are asking here.
EIGRP selects best routes as successors. Loop free alternate routes are installed as feasible successors. EIGRP only advertises its best route to its neighbors.
If the successor goes away then the feasible successor can be installed. If the successor then comes back it will have better metric so it will be installed again. If there are no successors or feasible successors then EIGRP will query to see if someone has an alternate path.
Daniel Dib
CCIE #37149
Please rate helpful posts.
02-04-2014 03:31 AM
Hi Dani,
Sorry for the confusion.
As you mentioned if the successor goes away then the feasible successor can be installed. If the successor then comes back it will have better metric so it will be installed again….agree
My question is
When the successor then comes back is it takes time or how the process will happen?
Thanks for your time
Thanks for your time
02-04-2014 11:56 PM
Hi Anand,
The change is immediate as soon as the update is received by EIGRP. I made a quick lab to demonstrate for you. This is the topology:
R1 is announcing 11.11.11.0/24 to the other routes via EIGRP. I have put a delay on R2 f0/0 to make that path slightly worse than the one via R3. I am also using NTP to synchronize the clocks for more accurate time stamps.
This is the current routing table on R4.
R4#sh ip route 11.11.11.0
Routing entry for 11.11.11.0/24
Known via "eigrp 1", distance 90, metric 435200, type internal
Redistributing via eigrp 1
Last update from 34.34.34.3 on FastEthernet0/1, 00:08:08 ago
Routing Descriptor Blocks:
* 34.34.34.3, from 34.34.34.3, 00:08:08 ago, via FastEthernet0/1
Route metric is 435200, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
If we look in the topology table we should have a path via R2 as well.
R4#sh ip eigrp topology 11.11.11.0/24
IP-EIGRP (AS 1): Topology entry for 11.11.11.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 435200
Routing Descriptor Blocks:
34.34.34.3 (FastEthernet0/1), from 34.34.34.3, Send flag is 0x0
Composite metric is (435200/409600), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 7000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
24.24.24.2 (FastEthernet0/0), from 24.24.24.2, Send flag is 0x0
Composite metric is (435456/409856), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 7010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Which we have. The secondary route meets the feasibility condition, essentially meaning that R2 is closer to the destination network than R4 is, making it loop free.
Now I will shutdown the interface on R3 facing R1, I will debug IP routing on R4 to see when the route gets installed.
R3(config)#int f0/0
R3(config-if)#sh
R3(config-if)#
Feb 5 08:47:25.981: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 13.13.13.1 (FastEthernet0/0) is down: interface down
R3(config-if)#
Feb 5 08:47:26.018: RT: delete route to 11.11.11.0 via 34.34.34.3, eigrp metric [90/435200]
Feb 5 08:47:26.022: RT: no routes to 11.11.11.0
Feb 5 08:47:26.022: RT: NET-RED 11.11.11.0/24
Feb 5 08:47:26.022: RT: delete subnet route to 11.11.11.0/24
Feb 5 08:47:26.026: RT: NET-RED 11.11.11.0/24
Feb 5 08:47:26.026: RT: delete network route to 11.0.0.0
Feb 5 08:47:26.026: RT: NET-RED 11.0.0.0/8
Feb 5 08:47:26.030: RT: add 11.11.11.0/24 via 24.24.24.2, eigrp metric [90/435456]
Feb 5 08:47:26.030: RT: NET-RED 11.11.11.0/24
You can see that the update was very fast. Only 51 ms to install the FS, one of the advantages of EIGRP. Now let's bring the successor back again.
R3(config-if)#no shut
R3(config-if)#
Feb 5 08:50:29.251: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 13.13.13.1 (FastEthernet0/0) is up: new adjacency
Feb 5 08:50:31.353: RT: del 11.11.11.0/24 via 24.24.24.2, eigrp metric [90/435456]
Feb 5 08:50:31.357: RT: add 11.11.11.0/24 via 34.34.34.3, eigrp metric [90/435200]
Feb 5 08:50:31.357: RT: NET-RED 11.11.11.0/24
It took a bit longer to update this time but it was still quite fast. So the key here is that updates will trigger change to RIB immediately.
In theory this could be a problem if there is an interface flapping in the path betwen source and destination. There are techniques to mitigate this such as IP dampening.
Daniel Dib
CCIE #37149
Please rate helpful posts.
02-05-2014 01:56 AM
Thanks Dani
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide