Love it or hate it – RIP

Routing Information Protocol (RIP), love it or hate it – it’s still used and sometimes still even deployed but why?

First of all; let’s look at what RIP is, summarized in a few bullet points:-

–  Distance vector
–  Metric-based protocol
–  Slow convergence

The list of RIP attributes are not limited to the above, but it’s what I think of when I think of the protocol. Now, what does that mean for our networks and why would I want to use it over other protocols?

Distance Vector

Being distance vector, RIP is only concerned about its neighbors which are connected to a subnet segment it has a presence in.  Furthermore, you must also have a particular interface participating in RIP – this is usually controlled via the network statement.  This means, there is little overhead of RIP compared to OSPF, which needs to know the entire topology.

This means, for light touch deployments like Dynamic Multipoint Virtual Private Network (DMVPN), RIP can be a good alternative to OSPF.  It allows you to be a lot more flexible as there’s no requirement to maintain a link state database with a full view of the topology.

Of course – other protocols such as EIGRP and BGP may be better suited, but sometimes due to either technical or business constraints, you don’t have the ability to deploy such protocols.

DMVPN is a hub and spoke technology which means that the hub must send routes out of the same interface that it learns it from. This issue is that split horizon rules apply as RIP is a distance vector protocol which state routes advertised out of the same interface they learned – simply put, it’s a loop provision mechanism.

This, therefore, means on the hub of the DMVPN,  split horizon must be turned off, on your tunnel interface.


Like a lot of routing protocols; RIP is metric based.  This means for every route within that is learned via RIP a metric is assigned to the route.  What’s special about RIP, is that it uses a hop based metric and that the maximum hop is 15 hops – if a metric for a route is 15 or more, it will not be installed within your routing table.

If RIP learns a route, which becomes invalid it performs an action called route poisoning. Route poisoning is not specific to RIP; it is used in other dynamic protocols such as EIGRP.

Route poisoning simply advertises a route with the maximum metric onwards to devices participating in RIP.  This is done by sending a packet with a matric of 16; deeming it unreachable and therefore it will not be installed in the routing information base (RIB).

Convergence times

Moving onwards to convergence times; RIP relies on timer-based convergence meaning that a hello and max-age timer is used – when the max age timer is met, the neighbors are considered dead.

However, this can be a somewhat controversial topic. There are additional technologies which can be used alongside RIP, which speed up failure detection upon a link – such technologies are not a direct feature of RIP, however.

Features such as bidirectional forwarding detection (BFD) can be configured to detect dead peers.  A deep dive in BFD is out of the scope of this article, however, more information can be found here.

The alternative to using such technologies is changing the timers manually, on a per-interface basis.  It should be stressed that this is not recommended best practice as increased hellos sent to peers, increases load on a routers processor as control plane packets must be processed via the CPU.

To conclude; although RIP isn’t the fastest or the best protocol on the market today, it shouldn’t be considered obsolete as there are use cases which RIP can be preferred.  Sometimes simplicity is valued over complexity which can bring down operating expenditure to a business.


2 thoughts on “Love it or hate it – RIP

  1. I hate to admit it but there is really use cases to use RIP. I actively run it in a live production network today, simply because it is the only routing protocol that is a viable use-case for this specific niche. Without going into details, I surmise that it is very commonly used in the specific use-case that we deploy it in.

    It’s a dead and dying protocol, but it might remain in that state for quite some time ;).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s