I am sure that there would be very few people running RIP in their
networks, but since the IETF RIP mailing list is dead, and also
because its more of an operational question, the Nanog list felt most
appropriate to me for the following post.
Why would you, as an operator, recieve RIPv2 Request messages? The
only reason that comes to my mind is when a remote RIPv2 router has
just come up. That time its going to multicast this message on all its
interfaces configured to run RIP. This is the *only* reason that comes
to my mind.
However, there is text in the RFC 2453 that states that RIP can use
this message to request specific networks also. It also states that
such a request can only be made by a diagonistic software and cannot
be used for routing. My doubt is, how can a diagnostic software, use
the services of RIP for doing that?
I assume (please correct me if i am wrong) that the RIP requests are
only then, used for requesting the entire routing tables, and nothing
else. The 'diagnostics' story sounds too far fetched to me!
I am sure that there would be very few people running RIP in their
networks, but since the IETF RIP mailing list is dead, and also
because its more of an operational question, the Nanog list felt most
appropriate to me for the following post.
i guess i'm among the very few then.
Why would you, as an operator, recieve RIPv2 Request messages? The
only reason that comes to my mind is when a remote RIPv2 router has
just come up. That time its going to multicast this message on all its
interfaces configured to run RIP. This is the *only* reason that comes
to my mind.
thats the normal way
However, there is text in the RFC 2453 that states that RIP can use
this message to request specific networks also. It also states that
such a request can only be made by a diagonistic software and cannot
be used for routing. My doubt is, how can a diagnostic software, use
the services of RIP for doing that?
kind of depends on the implementation of RIP you are using.
I assume (please correct me if i am wrong) that the RIP requests are
only then, used for requesting the entire routing tables, and nothing
else. The 'diagnostics' story sounds too far fetched to me!
ripv2 allows for requesting specific prefixes. not too
far fetched.
We were running RIP till some time back and very recently migrated to OSPF. The former was just too slow and stupid!
I remember we once had started recieving a lot of RIP request messages for some strange prefixes. I dont know what caused that, but we did see those messages. But then, i remember it wasnt normal at all. We shouldnt have been recieving them. Some one fixed the problem at the other end, and the matter just ended there.
Actually you'd be surprised.. its quite common as its very simple and used on a
lot of low end routers in favor of more cpu/memory intensive ospf/isis. I know
of a number of customers we have using RIP v1 and v2
It's also the only protocol (currently in use) which doesn't require an adjacency to be formed, allowing interesting tricks and one-way communications.
However, there is text in the RFC 2453 that states that RIP can use
this message to request specific networks also. It also states that
such a request can only be made by a diagonistic software and cannot
be used for routing. My doubt is, how can a diagnostic software, use
the services of RIP for doing that?
This allows a remote node to obtain the routing table information from
a remote router in a simple manner.
I assume (please correct me if i am wrong) that the RIP requests are
only then, used for requesting the entire routing tables, and nothing
else. The 'diagnostics' story sounds too far fetched to me!
Sorry, no. The thinking at the time was that this was a good way to debug
routing problems. Of course, this was in the pre-traceroute days.
We use RIP extensively on the edges of our network to build a Layer3
routed overlay between 3550/3750 switches and our 6500-based core. At
$2k/list for the EMI license PER SWITCH ($4k for 3750s), it just wasn't
feasible for us to use EMI just for OSPF when all we were really
announcing was a loopback and a /30 connected network.
We route filter and tune the RIP times down quite a bit. Meets our needs
on the edges.
We use RIP extensively on the edges of our network to build a Layer3
routed overlay between 3550/3750 switches and our 6500-based core. At
$2k/list for the EMI license PER SWITCH ($4k for 3750s), it just wasn't
feasible for us to use EMI just for OSPF when all we were really
announcing was a loopback and a /30 connected network.
We route filter and tune the RIP times down quite a bit. Meets our needs
on the edges.
I assume you mean RIPv2, ie. classless. With that caveat, I can certainly
see why RIP would be used.