Re: RIP Justification

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

On Thu, 30 Sep 2010 01:15:45 -0500
William McCall <william.mccall () gmail com> wrote:

> On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin
> <chris () 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 () 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 () 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.

The best place to configure the prefix filtering would be on admission
to the routing domain, rather than on exit. To achieve any sort of
accurate route filtering in a RIP environment you'd have to  maintain
ingress route filters on all of the business partner routers. That'd be
much harder to maintain accurately due to the number of business
partner routers than a single per-business customer inbound route filter
on a couple of BGP Route Reflectors/Servers.

Those business customers may not trust you to operate their routers, so
your routing accuracy is dependent on how well administered those
business partner routers are maintained, which is likely to be very
inconsistently. If you were operating the business peering exchange as a
paid third party, and were providing SLAs for the service, then you
wouldn't be in control of something that is essential to maintaining
the quality and availability of the service. 

> > [...] 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.

Then they're not the right people to be operating this network because
they're not competent to.

It sounds a bit like you're justifying people saying "I want to be paid
to be an expert in this field, but I don't want to actually be an
expert." I find this cop-out extremely irritating. You either know what
you're doing or you don't, and if you don't, you shouldn't be selling
yourself as somebody who does.


> 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).

Then you buy a cheap BGP speaking device e.g. a Cisco 800 to put in
front of it.

Regards,
Mark.