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