After reading over RTP this morning I decided to run up a very simple EIGRP setup in GNS3 to help visualise what is happening.


As the image above shows the setup is very straight forward.

The link from R4 to R3 was set to 100mbps and R4 to R2 was set to 10mbps. This was simply to adjust the metric and move traffic over to one link and make picking the right link for tracking RTP easier.


What I wanted to do was a simple test to demonstrate the RTP messages sent. I started a ping from R4 to 172.16.0.1 which is on FA1/0 of R1.

Wireshark was capturing on R2 FA0/0. As expected there was no ICMP traffic, it was all going through R3. I then ran the shutdown command on R3 FA 0/0.


The wireshark output shows R4 responding to the link being cut by sending a Query to multicast 224.0.0.10 and R2 responding with a Reply as a unicast to 172.16.4.1.  For those that are interested I will provide the packet details below. I won’t dig through those, because simply I don’t understand enough detail to do that reliably.



When the link is restored through the no shutdown command R4 will send an update advising of the route and adjust it’s route table to the better metric.


The ICMP packets have stopped being routed through R2 as it is now the inferiour link and R3 has been chosen as the successor once again. The update packet has come through as multicast advising up the link availability.

Once again I will provide the full details of the update packet, which is quite detailed.


This little demonstration has been able to show how EIGRP uses RTP to respond to link outages as well as how it handles the link being restored.