|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical BGP vs. static routing (Re: Why Vadim likes statics)
In message <[email protected]>, [email protected] writes: | This sounds a lot like the slippery slope of static routing being the most | stable, so we should encourage its use Internet wide. I -know- Karl D. | (and others that depend on dynamic routing for alternate provider fallback) | will kick at this. Why? What we have been arguing for has been limiting the scope of dynamic routing only to places where participating in global dynamic routing makes sense. In the case of multihomed networks, the appropriate technique is, in most simple cases I am aware of: Provider X Provider Y | | +------------------------+ | border router | +------------------------+ | Dynamic routing domain The border router does aggregation outbound and points the aggregates at Null 0 with a high metric. This is for cases in which there is no other router participating within the customer iBGP mesh, and where there are N (N>=1) upstream providers, and where dynamic routing must take place within the ISP's routing domain for various reasons (portable dialup links, links that are time-sensitive, etc.) I would argue that if N is 1, then BGP shouldn't be used to talk to Provider X, and the customer router can therefore have much less memory, however there are still NSPs which require BGP for resellers as a matter of policy. Another fairly common current practice is this one, which is popular where there are N (N>1) providers where : Provider X Provider Y | | +------------+ +------------+ | BGP router | | BGP router | +------------+\ /+------------+ \ / +----------+ | iBGP box | +----------+ | Dyanmic routing domain The iBGP box should do aggregation and have static routes pointing to Null0 for all nets it announces to the two edge routers. The utility of BGP is thus preserved -- the iBGP box can route based on policy towards the rest of the world, and the rest of the world can route towards things behind the iBGP box, and things should work when Provider X or Provider Y goes away. A more complex case is one like this: Provider X Provider Y Peers A, B, Z | | | +--------+ +--------+ +---------+ | | | | | | +--------+ +--------+ +---------+ \ | / (a bunch of iBGP-talking routers) at this point people are building something akin to what NSPs do. Step 1 is to make very sure that there is the same reachability from any of the three boxes above to all of the iBGP boxes. That is, build redundantly, or get caught being a bad aggregator/flapper or a victim of non-fate-sharing networking. Step 2 is to do the _same_ aggregation and high-metric routing to Null 0 on all the border boxes (the three shown above) so that a consistent picture of this small-i internet is presented to the outsides world. Step 3 is self-protective; where possible, route things to Null 0 on all one's edge boxes to avoid unnecessary route-flap propagating internally. There are lots of other steps which should or could be taken as one grows, including relaxing Step 1 in favour of aggregation to shortish (18-bit) prefixes on internal routers such that the border routers don't necessarily have to perform aggregation and pointing at Null 0. I'd detail several more steps but my fingers tell me they want to go on to the next message. At any rate, in none of these examples is BGP being eliminated or the ability to multihome one's network compromised. However, in the first example (one edge box), I see an equivalent to Providers X and Y typing, say: ip route 209.1.0.0 255.255.0.0 Serial 0 remove-when-down set-as 7001 where the last part tells your Cisco to pretend it heard the route from AS 7001 (doesn't exist yet), and remove-when-down says when the interface is down, stop announcing the route (this is the current default). No BGP necessary, and less work for the customer to do. Sean.
|