BGP vs. static routing (Re: Why Vadim likes statics)

Sean Doran smd at
Tue Apr 25 04:51:47 UTC 1995

In message <199504241414.AA14108 at>, bmanning at ISI.EDU 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

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

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

However, in the first example (one edge box), I see
an equivalent to Providers X and Y typing, say:

ip route 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.


More information about the NANOG mailing list