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.) ~Seth