On Thu, Sep 30, 2010 at 3:38 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
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.
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