RIP Justification

Thu Sep 30 14:22:04 UTC 2010

On Thu, Sep 30, 2010 at 3:38 AM, Mark Smith
<nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
> On Thu, 30 Sep 2010 01:15:45 -0500
> William McCall <william.mccall at gmail.com> wrote:
>
>> 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.
>>
>
> 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.
>
Agreed, but rarely is this option presented. For this reason, the
operator must still protect the network from other's misconfiguration,
etc.

>> > [...] 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.
>
No no... True that it happens that "experts" are often not quite
"experts", I am not a fan, but it is a reality of the business. Once
upon a time, not long ago, I had a manager explain to me that our team
must set up a business partner scenario with either:

A) Static routes and IP SLA or
B) RIP

I told him BGP made more sense and he just said "It's too complicated,
don't do it." Not like he had to support it (the senior engineers, who
all knew BGP, had to support it regardless).

Long story short, we did static routes and IP SLA because the BP would
only do BGP or static routing.

Anyway, as I indicated in the statement you quoted, I don't support
bad design decisions and, as an extension, gross incompetence, but it
is rife in most technical and professional fields. And still, even if
that incompetent administrator attempted to implement RIP versus BGP
for this scenario, they'd probably still screw it up.

(As another recent example of professional incompetence outside of
networks, consider a set of medical professionals attempting to give
more morphine to a surgery patient when the patient had a heartbeat of
around 40 BPM and telling said patient that they must be having a
panic attack. Twice.)
>> 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.

Again, I don't disagree. In the proposals I have designed, it is
usually some sort of termination router for the tunnel or attachment
circuit and then a security device behind that somewhere where it
makes sense. Management is sort of responsible though for making that
happen and often enough they'd rather not, usually to save the
relatively few dollars here and there and get a slightly larger bonus
at the end of the year.

Or the other approach is where the "security" team (firewall jockey
and/or fear mongering CSO) has dictated that they handle termination
of all of these circuits, etc and they HAVE to handle the BP routing
(so even the hack known as eBGP multihop is not an option). The
reason? "Security."

> Regards,
> Mark.
>

Often times, technical decisions are made into "business" decisions
when they shouldn't be. Also, incompetence is common, if not promoted
in a lot of these "business" decisions. If you haven't had to deal
with this inside of your firm, then I really really want to ask you
about a job with your firm. I'll relocate just about anywhere and I
shower daily or more often as necessary. (This should not be construed
as to say my current firm is run by incompetent folks, quite to the
contrary is true).

-- 
William McCall