Dynamically Changing Exit Policy (iBGP)

Tue Oct 30 04:55:24 UTC 2007

On Mon, 29 Oct 2007, Benjamin Howell wrote:

> On Mon, Oct 29, 2007 at 04:53:50PM -0400, Deepak Jain wrote:
>> You can "nail" down your announcements to external peers by tying their
>> network blocks to a route-of-last resort on one of your loopbacks. This
>> will prevent flapping externally.
>
> Point taken, but it's actually difficult to nail down all of our
> routes. We have some lone /24's that are not subnetted and thus cannot
> be used with an 'ip route ... null0' statement. When WAN connectivity
> drops, the routes flap if we don't have a stable iBGP session. Thus I'd
> like to steer well clear of severing the iBGP session.

Not subnetting them doesn't mean you can't
ip route a.b.c.d 255.255.255.0 null0 250
while still routing the /24s internally (with lower metric) or having them
connected on some interface.

> Only a single internal /30 route will be removed when an interface goes
> down. I can't come up with a route-map implementation that would
> add/remove the weights to the routes already received from our eBGP
> neighbors. If I'm missing something, please let me know.
...

>>> I'd like to dynamically change from best-exit to a "hot potato" exit
>>> policy when an internal DS3 fails. We fail over to a much lower
>>> bandwidth link and would like to avoid sending anything but internal
>>> traffic over that link. If it's not already clear, this change needs to
>>> happen automatically.

Are you talking about a single internal DS3, or the more general case of 
"if any of our internal DS3s are down, we need to route differently"?

If it's a simple case of two DS3 connected routers which are iBGP peers 
and also have directly connected eBGP peers, could you use route-maps to 
set ip next-hop on iBGP exchanged external routes (setting the ip next-hop 
to be the IP of the other end of the internal DS3, with a second IP of an 
eBGP neighbor interface)?  I haven't tried it, but it seems like it might 
do what you want.

>>> (1)  Set a weight on all routes received from the eBGP peer at each
>>>     location so that it prefers the direct eBGP peer.
>>> (2)  Sever the iBGP session by tying the iBGP session to an interface
>>>     IP address rather than a loopback IP. When the DS3 goes down, so
>>>     will the knowledge of the remote exit point.

Another possiblility (I've never tried) would be to configure multiple 
iBGP sessions...one using loopback IPs, the other using the DS3 interface 
IPs, exchanging internal routes over both sessions, while exchanging 
external routes over only the second.  If the DS3 goes down, the session 
exchanging external routes dies.  I'm not sure you can do this, but I 
think by having different peer/endpoint IPs (loopbacks for one session, 
serial interface IPs for the other), it may work.

It may be appropriate to move this thread to the *-nsp list appropriate 
for your brand of routers.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________