North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Dynamically Changing Exit Policy (iBGP)

  • From: Benjamin Howell
  • Date: Mon Oct 29 20:37:03 2007

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.

> The weights can be added/removed automatically by using a route-map on 
> the routes that will be added/removed by the interface going down.

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.

> Normally, however, you wouldn't use iBGP for this and you'd use a 
> heavier, link-aware internal routing protocol like ISIS or OSPF.

We use OSPF internally, but it just carries internal infrastructure
addresses. I understand that OSPF is link-aware and can carry knowledge 
of link bandwidth, but I don't see how it would fit into our exit path

We accept full routes from our eBGP neighbors and it's not advisable to
inject those into OSPF. Our normal policy must be best-exit, which
leaves iBGP as the decision-maker unless I'm missing something. Is
there a better IGP-based method of choosing a network exit path that
would solve these problems? I ask because I'm curious, not because I
know the answer.

Ben Howell

> Benjamin Howell wrote:
> >Is there a generally accepted method of automatically altering exit
> >policies within an AS?
> >
> >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.
> >
> >I realize that there are two means of accomplishing this:
> >
> >(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.
> >
> >The devil's in the details however. I can't figure out how to make the
> >weight approach work on routes that were received prior to the circuit
> >failure or how to remove the weights once the circuit comes back up.
> >
> >Severing the iBGP session seems drastic to me, and I'm worried that our
> >advertised routes will be dampened by peers if the internal DS3 starts
> >flapping.
> >
> >Any input from wiser peers would be greatly appreciated.
> >
> >--
> >Ben Howell