RIP – request and response packets

I was discussing the other day with someone on IRC about a RIP issue he had.
Apparently he had RIP request packets coming in and then all routers were
responding with response packets with full routing table. It seemed like some
kind of amplification attack. That made me realize that I didn’t even know RIP
uses request and response packets. This is very overkill for the CCIE but you
want to know the protocols not just pass a test right? So I then went on to
read the RFC and realized this was the first time reading it.

So when a router boots up or has its RIP process started the following happens.
The router sends a RIP request packet to either 255.255.255.255 or 224.0.0.9
depending on which version is running (who runs v1?). The packet looks like
this.

We see that the command is request and it is basically a packet with no
address information and the metric set to 16 (infinity).

Now the routers hearing this request will respond with a response packet.
It looks like this.

So the other router responds with all RIP routes that it has in its routing
table. The updates that RIP sends every 30 seconds are basically unsolicited
response packets. So why do we have request packets in the first case? It’s
a way of speeding up the convergence process so when a router boots up it
gets the routes immediately instead of waiting for in worst case 30 seconds
before hearing a RIP update.

So that should give you some more insight into RIP. I might do a followup post
on flash updates and suppression of null updates as well.