RIP Justification

Thu Sep 30 06:15:45 UTC 2010

On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin
<chris at travelingtech.net> wrote:
> Using BGP to exchange routes between these types of untrusted networks is
> like using a sledgehammer to crack a nut.  BGP was designed for unique AS's
> to peer in large scale networks such as the internet.  A far cry from
> business partners exchanging dynamic routes for fault tolerance.

But on the flipside, arguing that we're providing this business parter
service with no sort of broadcast mechanism, does the complexity
actually increase between a proper implementation of BGP versus
properly implementing RIP for the same scenario?

Consider this example:
2 business partners terminating on the same device, we are advertising
1 prefix to both and receiving 1 prefix from each. Each has redundant
connections to another router.

Goals:
1) Prevent BP A from advertising routes owned by BP B and vice-versa
2) Advertise only the single prefix to the BPs
3) No broadcast medium, so we'll need neighbor statements
4) Prefix advertised to peers originates from IGP

Mentally configuring this (in cisco terms), it seems about the same in
terms of config complexity. Filtering the prefixes from each of the
neighbors is required and the ACL to do this looks kind of nasty in
RIP. Also, you'll need to redistribute from the IGP and add either an
egress distribute list or a route map on the redistribution into RIP.
Finally, redistribute back into the IGP for the received prefixes.

BGP gives a slightly nicer-looking policy with a route map for each of
the neighbors and policy building features that make scaling the
solution slightly easier since route-maps can be reused and attached
to the neighbor through whatever mechanism you want. And no
funky-looking ACLs to describe how to accept prefixes and no need to
redistribute from the IGP. Also, if choosing to run iBGP between
redundant nodes, its quite a bit more simplified to set metrics to
determine primary and redundant paths since this can be done on the
same ingress policy.

On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield <rekoil at semihuman.com> wrote:
> (or, ghod forbid, multiple OSPF processes redistributing between each other...)
>
I think I have an anxiety disorder from this sort of "design"..

On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith
<nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
> How do you prevent those business partners spoofing specific
> route announcements within the RIP update, intentionally or otherwise,
> such as a default route, causing either outages or attracting traffic
> towards their networks that shouldn't be?

Ingress filtering for prefixes can be performed with RIP. It just
looks really funky compared to route maps for neighbors in BGP.

> [...] I don't worry to much about the specific
> scenarios the tool was designed for - if the chosen tool provides the
> most appropriate and relevant benefits for an acceptable cost,
> the original design scenario doesn't matter.

True that BGP is generally better in most external routing instances.
But there are other cost factors involved with doing BGP - fear and
knowledge. A lot of less experienced folk out there are outright
afraid of the concepts behind BGP and/or do not have the requisite
skills to maintain it. That shouldn't justify bad design decisions,
but it often does. Plus, it could be postulated that proper
implementation of RIP in the same scenario would be hindered by the
lack of knowledge still.

Also, it should be pointed out that there are security products and
others that don't support BGP. In those instances, it might make some
sense to choose RIP. Other limiting factors can include resource and
feature availablity on the terminating device(s) (as addressed by
others).

-- 
William McCall