RIP Justification

Thu Sep 30 03:19:41 UTC 2010

I know of one large-ish provider that does it exactly like that - RIPv2 between POP edge routers and provider-managed CPE. In addition to the simplicity, it lets them filter routes at redistribution without having to fiddle with inter-area OSPF (or, ghod forbid, multiple OSPF processes redistributing between each other...)

Where folks run into trouble is vendors that decide that RIP is so under-utilized they don't need to fully support or QA it anymore. Implementations tend to be a bit more..."quirky" than OSPF or BGP running on the same box. And occasionally you run into the odd vendor that doesn't care about things like being able to adjust hello/dead intervals...

-C

On Sep 29, 2010, at 2:50 PM, Jonathon Exley wrote:

> RIP is useful as an edge protocol where there is a single access - less system overhead than OSPF.
> The service provider and the customer can redistribute the routes into whatever routing protocol they use in their own networks.
> 
> Jonathon 
> 
> -----Original Message-----
> From: Jesse Loggins [mailto:jlogginsccie at gmail.com] 
> Sent: Thursday, 30 September 2010 9:21 a.m.
> To: nanog at nanog.org
> Subject: RIP Justification
> 
> A group of engineers and I were having a design discussion about routing protocols including RIP and static routing and the justifications of use for each protocol. One very interesting discussion was surrounding RIP and its use versus a protocol like OSPF. It seems that many Network Engineers consider RIP an old antiquated protocol that should be thrown in back of a closet "never to be seen or heard from again". Some even preferred using a more complex protocol like OSPF instead of RIP. I am of the opinion that every protocol has its place, which seems to be contrary to some engineers way of thinking. This leads to my question. What are your views of when and where the RIP protocol is useful? Please excuse me if this is the incorrect forum for such questions.
> 
> --
> Jesse Loggins
> CCIE#14661 (R&S, Service Provider)
> This email and attachments: are confidential; may be protected by
> privilege and copyright; if received in error may not be used,copied,
> or kept; are not guaranteed to be virus-free; may not express the
> views of Kordia(R); do not designate an information system; and do not
> give rise to any liability for Kordia(R).
> 
> 