[c-nsp] BGP Routing Failover for multiple classes of customers

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gert Doering wrote:
> Hi,
> 
> On Tue, Sep 06, 2005 at 10:19:17PM -0700, Richard J. Sears wrote:
> 
>>Customer 1 we would like to only get to provider_1 (this works)
> 
> 
> Unless you do VRF things, this will only "work" for certain definitions
> of "work".
> 
> The main problem is the BGP decision process - you cannot have two
> best path routes in your system, so the router will pick one, and then
> evaluate whether to send this route to its peers (= your customers).
> 
> If for a given prefix, like "4.0.0.0/8", your router selects provider_2
> as "best path", your customer 1 will *not* receive "4.0.0.0/8 via 
> provider_1", but "no route to 4.0.0.0/8 at all".
> 
> So customer 1 isn't getting a full BGP table "via provider_1", but
> just those prefixes that happen to have a best path via provider_1, 
> which almost all the time will be a very much incomplete BGP table.
> 

As I read his email, he seems to be suggesting that he is a transit
provider for his customers and that some customers packets should be
forwarded differently than other customer packets.  That makes this a
policy forwarding problem rather than simply a policy issue for route
advertisement.  That's what leads me to the VRF solution as it is the only
one that combines both elements; routing decisions and forwarding decisions.

I suppose Policy Based Routing/Forwarding could be used in his scenario,
but it's kind of inflexible.  His customers that can use either provider
can use destination based forwarding and the global table as usual.  The
customers that use only provider_1 can be forwarded to either the interface
or next hop of provider_1 based on their source address.  The customers
that should be forwarded to provider_1 primarily and provider_2 secondarily
could also be forwarded based on their source address using multiple next
hops or interfaces specified in the set portion of the route map.  However,
provider_2 would only be selected if the next hop or interface for
provider_1 is not reachable, i.e. the interface would have to be down.
That leaves many failure modes where reachability could be affected but
would not be detectable because the interface may not go down (provider_1
upstream failure, provider_1 peering session failure, ethernet trunk
failure, etc, etc).

There are probably some tricks that could be done with Enhanced Object
Tracking to get a next hop for provider_1 that would go away in some of the
above failure modes, but they would be 1) hacks; 2) violate the K.I.S.S.
principle; and 3) violate the "can I troubleshoot asleep at 3am test".  If
hacks are needed to solve the problem, it's likely as you said previously
that we're "...fixing a broken business model with engineering hacks".

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFDHqKxE1XcgMgrtyYRAht1AJ9rzuRuPT/fZJaZ0zEqHguycyiUbgCfQL/F
IUtZERb9jtDQwl25DUOODN4=
=gjsH
-----END PGP SIGNATURE-----