question regarding multi-homing

Seth Mattinen sethm at
Wed Dec 30 11:29:11 CST 2009

Simon Chen wrote:
> Hi all,
> Happy new year...
> I have a question regarding multi-homing, mostly from stub network's
> operational point of view. My big question is: what kind of failures
> do you usually see from your providers? Link down? Link up, but
> withdraw some routes? Link up, no route change, but blackholing
> partial or all traffic? Anything else?

I am a multihomed network with no downstream customers. Speaking only
for myself over the last 5 years I have only had loss of link conditions
as the majority problem such as:

* DLCI deleted (LEC "accidentally canceled" a FRT1 once)
* Loss of signal (almost always LEC problems)
* Loss of frame (almost always long haul problems)

It's worth noting all my circuits are T1, T3, or OC-x and less likely to
have an "up/up but not passing traffic" state like an Ethernet handoff
could do.

And only once:

* Sprint vs. Cogent peering spat (I'm a Sprint customer)

The last one would have been a huge problem for default route or single
homed users - and why I always recommend full tables - but for me I
didn't care since the affected paths disappeared via Sprint but were
still there via my other upstream.

> To state this problem in detail: I use a static default route on Ra to
> forward traffic to provider A, or receive 0/0 from provider A via BGP.
> For some reason, provider A can no longer reach a /24. My network
> cannot be notified (unless, I receive a full internet routing table).
> In this case, all I know is that my traffic to /24 is blackholed
> through provider A. In this case, is there an automatic way for my
> stub network to switch over to provider B? Do I have to do the
> detection and switch over manually? I don't think VRRP can help here,
> right?

You're asking for what BGP does. You could ping every prefix you care
about and do it by hand, I guess. If this is a major concern for you I'd
say full tables are in your best interest so you can let BGP do what it
does best. (Disclaimer: there may be some trick I'm not aware of because
I always prefer to let BGP do its job.)


More information about the NANOG mailing list