Hi Rene,
You said R3 doesn’t learn about the route 3.3.3.0/24 from R2, when using route horizon (when the link 3.3.3.0/24 is down). But at this time R3 wouldn’t have this route information as it is deleted from the table (you have explained this too). So, technically, R3 should accept this route. Please correct if I am wrong.
Hi Rene,
Can you explain difference between distance vector protocol and link state protocol in brief.
Ajay,
Here is the fundamental difference between them:
Link-State: A link state enabled router has complete knowledge about the administrator’s defined network in which it resides. It knows about all of its locally connected networks, it knows about all other link-state enabled routers, and it knows about all networks connected to those other link-state enabled routers. Based on this knowledge, it generates its own unique view of the network, placing itself at the center, and independently decides the best paths used to get to any destination. All link state routers in the same portion (or area) of the network must have identical information in their databases.
Distance-Vector: This is often referred to as “routing by rumor.” This means, that while the router knows about networks to which it is directly attached, it knows nothing about any other network other than what its neighbors are telling it. Each router could have different information within its database.
@Shree Kumar When a network is down, it doesn’t get deleted from the routing table immediately. It will start a holddown timer:
our 3.3.3.0 /24 network is down they will also start a holddown timer. This holddown timer will run for 180 seconds and it does the following:If we receive information about the 3.3.3.0 /24 network from another router with the same or worse metric than we currently have, we ignore this information.
If we receive information about the 3.3.3.0 /24 network from another router with a better metric, we stop the holddown timer and update our routing table with this new information.
If we don’t receive anything and the holddown timer elapses we remove this network from the routing table.
Hi,
The below picture is the traffic capture from int fa1/0 , Why the metric shows 1
Thanks
Hi Sims,
When you advertise a network in RIP, the router will set the default metric to 1.
Rene
Hi Rene,
I have two queries
Hi Ananth,
1- We agreed that Split Horizon is a technique incorporated by distance vector routing protocols for avoiding routing loops by preventing the routing path to be sent/advertised back to the node from which the advertising router has received it.
In our example, Router Clubs will not accept any route update about its connected network from the neighbor router when using split horizon. When 3.3.3.3/24 is down, Router Clubs will send a route poison to other routers by assigning the metric of this particular network to 16. There should be a Poison Reverse to inform router Clubs that the Route Poison has reached the routers, and here happens the overruling on the split horizon , otherwise the Poison reverse will never reach Router Club if the split horizon is not overruled.
2- Rene has already given an explanation about the timer in this post, and I am copying it and paste it here:
Let’s say we have two routers:
R1-R2
R1 is advertising 1.1.1.0 /24 to R2.
Suddenly, R1 stops advertising RIP updates to R2.
At this moment, the invalid timer (180 seconds) and flush timer (240 seconds) start counting.
After 180 seconds, the route is considered invalid and the holddown timer will start (180 seconds). The route will remain in the routing table but is “possibly down”.
60 seconds later, the flush timer will expire and the route will be deleted from the routing table…that’s it. In total it takes 240 seconds for a route to be removed. The thing that confused me is that the holddown timer only runs for 60 seconds in this scenario, once the flush timer is expired it’s game over…
Apparatently, the holddown timer is also supposed to start when you receive a triggered update from a neighbor that advertises a route that is unreachable. The confusing part is that it doesn’t work this way on newer IOS versions. Once you receive a triggered update with a network that is unreachable, it’s removed from your routing table immediately. In some of the discussions I read online they say that on IOS 12.0, RIP does enter the holddown state when you receive a triggered update with an unreachable network.
Hi Rene ,
When current metric is low , and its received rip update with higher metric for a disconnected route , why router 2 will update its routing table ? can you please clarify .
“I can reach 3.3.3.0 /24 by going to R3 and my hop count used to be 1. I’m receiving a routing table from R3 now and it now says that the hop count is 2…I need to update myself to include this change”.
Reagrds,
Sameer
Hi ,
one doubt is when i want capture rip request packets in wireshark , i am only seeing rip response i have tried by doing shutdown and no shutdown . is it expected ?
Regards,
Sameer.
Hello Sameer
This is a very good question. What is happening here is that R2 has obtained its original hop count of 1 to network 3.3.3.3 from R3. So since R3 has told R2 that the distance to 3.3.3.3 is 1, it puts it in its routing table.
After the procedure that is described, R3 sends a new hop count to R2 of 2. Now you say since this hop count is higher than that which is already in the routing table of R2, why does R2 replace it? Well, it will replace it because it is an updated piece of information.
So, the previous entry of metric 1 that was learned from R3 is replaced with the updated entry of metric 2 from the same source, namely R3.
I hope this has been helpful!
Laz
Hello Sameer
It is possible to capture requests as well. Requests are few and far between so you need to search a bit for them. Make sure that wireshark is set up to listen for them. Some more info about capturing RIP packets on wireshark can be found at this link.
An example of RIP captured on wireshark can be seen below.
I hope this has been helpful!
Laz
Hi Laz ,
Still i have a basic doubt on this , is rip response (periodic at every 30 secs) are soliciated by the request packets , or is it like when we initially enable RIP it will send request packets and then every 30 sec routers will send unsolicited response packets or else these are all unsolicited periodic responses (if so , there is no need of rip request messages) .
If it is unsolicited we cant capture it because it not generated in my case i am thinking that its may be timing issue while capturing the request packet .
Can please elaborate it .
Regards,
Sameer
Hello Sameer
RIP requests are only sent under special circumstances, when a router requires that it be provided with immediate routing information. The most common example of this is when a router is first powered on. After initializing, the router will typically send an RIP Request on its attached networks to ask for the latest information about routes from any neighboring routers. The only other situation in which RIP requests are sent is when they are to be used for diagnostic purposes.
So yes, it is rare to find requests.
Responses on the other hand are sent either as a direct result of a request, or unsolicited every 30 seconds as you mentioned. So you are correct when you say that in order to capture requests, it is an issue of timing, being able to capture the packet at the time of RIP initialization.
You can attempt to keep your sniffer on during the enabling of RIP on your routers, thus instigating a RIP request.
I hope this has been helpful!
Laz
Hi…
I have a doubt route poisoning and poison reverse.? Can u explain it once
Hi Rathinasabapthy,
Anything, in particular, you don’t understand about it? I explained it with quite some detail in this lesson.
Rene
Hello
Could you please explain how a routing loop would occur if we did not use Route Poisoning and only used Split Horizon?
Thank you
Hi Markos,
Let’s say we have this topology:
R2 learns 1.1.1.1/32 through R1.
Suddenly, R1 fails. R2, R3, and R4 still have the route in their routing table with the correct metric (since we don’t use route poisoning).
R2 sends an update to R3 and R4 and a few seconds later, it deletes the route from its routing table since it hasn’t received any updates anymore from R1.
A second later, it receives an update from R4 that contains network 1.1.1.1 /32 and installs this in its routing table. You now have a (temporarily) routing loop. Split horizon doesn’t protect against this since the update went from R2 > R3 > R4 and back to R2 (or from R2 > R4 > R3 > R2 is also possible).
Rene