cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
908
Views
5
Helpful
4
Replies

eigrp 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 ?

Anand Vp
Level 1
Level 1

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 ?

1 Accepted Solution

Accepted Solutions

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:

EIGRP route lab.PNG

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.

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

View solution in original post

4 Replies 4

daniel.dib
Level 7
Level 7

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.

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

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

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:

EIGRP route lab.PNG

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.

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

Thanks Dani

Review Cisco Networking for a $25 gift card