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 18.104.22.168 /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”.
This is a very good question. What is happening here is that R2 has obtained its original hop count of 1 to network 22.214.171.124 from R3. So since R3 has told R2 that the distance to 126.96.36.199 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.
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.
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 .
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.
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 188.8.131.52 /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).
This is an excellent question. First of all, if we’re talking about the LAN side, then BGP is not a good choice. BGP is designed for large routing tables like those found on the Internet, and is generally much slower in converging. Within a LAN, if a link or a router fails, you want the routing protocol to re-converge within several seconds. Although BGP’s timers can be adjusted down to 3 seconds for the update and 15 seconds for the hold timer. However, this means that in the event of a failure, re-convergence will take at least 15 seconds. For most enterprise networks, this is unacceptable. There are ways to get around that, but there are other features of BGP (and lack thereof) that don’t make it a good choice for a LAN.
RIP, OSPF and EIGRP are internal routing protocols designed to be used within an enterprise LAN. But these too have various differences between them. In general, networking professionals agree that RIP should never be used in production networks unless absolutely necessary. I’ve come across some vendors of some specialized networking equipment only support RIP for example. But if you can avoid it, don’t use it. This is because it is slow to converge, not very scalable, and has comparatively few parameters to tweak and optimise routing. Today it is generally used for teaching purposes for students to understand the concepts before going on to other protocols.
Now it comes down to OSPF and EIGRP. This is really a matter of preference among networking professionals. Both protocols are scalable, tweakable and can provide for the demands of any modern network. Sure, each has its own strong points and weak points, but I think the most vital is that OSPF is open architecture and is supported by many vendors, while EIGRP is proprietary to Cisco, although some other vendors are licensed to support it. This alone may be enough for someone to choose one way or the other.
For a more detailed look at the differences and advantages of each protocol, take a look at Rene’s comprehensive lessons on both of these.
When routers use RIPv1, they do indeed use broadcast addresses to send out RIP updates. It is also true that routers do not forward broadcast packets that they receive. This means that if a RIP router sends a RIP update out of all its configured ports, only routers that are directly connected to it will receive these updates. A router may not forward broadcasts, but it will receive them and process them if they are sent from a directly connected router.
So RIP updates are sent only to directly connected neighbouring routers, which is the required behaviour to have RIP function correctly.
If RIPv1 is configured, R1 will send its updates out of all participating interfaces using a broadcast. This means that a broadcast packet will be sent out of Fa0/0 and Fa1/0. This packet will reach all of the hosts on the 184.108.40.206/24 network as well as all hosts on the 192.168.12.0/24 network. All hosts on the first network will discard the packet because they are not RIP devices. R2 will receive the broadcast and will process it. In this whole procedure, only R2 will receive and process the RIP message. R3 will see nothing. As you very correctly pointed out, routers do not forward broadcast packets, so R2 will not forward RIP messages recieved from R1, but it will process them, meaning, it will take their information and use it to update its own routing table.
Similarly, any RIP messages from R3 will reach R2 but will not reach R1. If R2 sends a broadcast RIP message, both R1 and R3 will receive the packet and will process it, because they are directly connected. They will not however forward these messages to the 220.127.116.11/24 or the 18.104.22.168/24 networks, as broadcasts are not forwarded to other networks.
I have questions:
1 . what is the concept of counting to infinity?
what is invalid timer, holddown timer and flush timer? as discussed before rene said that invalid timer is 180 seconds, holddown timer is 180 seconds and flush timer is 240 seconds so in total 600 seconds, it is confusing for me.
What are the exact parts that eigrp uses from distance vector and link state?
When 22.214.171.124/24 is down that is directly connected to R3, R3 sends route poison to R2 to tell him 126.96.36.199 is now unreachable for R3 and R3 sets the metric to 16 because it is unreachable for R3. Do all routers set the metric to 16 or only R2 and R1?
Rene said in discussion: when you advertise a network in RIP, the router will set the default metric to 1 so if we configure and advertise loopback interface it’s default metric is 0.
And the last question that is although not related to this discussion is: Difference between Bandwidth, Throughput and Speed.
Thanks in advance.
Counting to Infinity occurs when a router loses a directly connected network, and tries to reach it via a neighboring router. This neighboring router in turn says it knows where to find it, via the connection to the first router. The routers continually exchange routing updates, each time, increasing the hop count. Once this hop count reaches 16, which is “infinity” as far as RIP is concerned, the route is considered unreachable.
These timers do not count consecutively, but concurrently. That is, they are incremented at the same time. So as the holdown timer is counting up to 180, the flush timer is also counting at the same time. So you can’t just add up the times and calculate the result. For more info about timers, take a look at this:
EIGRP is a distance vector routing protocol. The reason for this is that EIGRP measures the distance to the destination using a particular metric, rather than constructing a network topology of the whole network like a link state protocol does.
R3 will set the metric to 16. This informs R2 that R3 no longer has a path to the specific destination, so it just removes it from the routing table. R2 will also send a route poison as well, telling R1 to remove the route from its routing table. If another router has an alternate route to this destination, then that route still remains. The only routes that the route poison will remove are those learned from the interfaces on which the poison is received.
The metric of 1 is used to advertise the directly connected networks. This includes loopback interfaces as well, so their metric will also be 1.
Bandwidth strictly speaking is the amount of data that can be sent in a particular period of time by a particular technology. Speed is the rated bandwidth of a particular interface. Throughput is the amount of usable bandwidth that a particular circuit provides.
For example, the bandwidth provided by a fiber optic link supplied by an ISP may be 30Mb/s, but this is plugged into a GigabitEthernet interface which has a speed of 1Gb/s. The throughput is what is made available to applications without the overhead of packet headers. This may be 27 or 28 Mb/s but may be variable over time.