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

[Richard J. Sears]

Bruce - 

You are very close on this issue. Basically its a business model issue. 

Provider_1 is cheap bandwidth, provider_2 is more expensive bandwidth
and the customer want cheap unless cheap is broken. So yes, I am trying
to fix a broken business model with engineering as someone already
suggested.

Initially I was going to use PBR support for Multiple Tracking Objects
and use a set next hop statement in my route maps to manage this process.
I would use prepending to manage inbound traffic as much as would have
been possible.

The problem is very simple - The SUP720 is not supported on the code rev
required to do this (12.2(25)S) - at least not that I could see. Maybe
someone could log into CIsco and see if its just my CCO login that
prevents me from seeing that, but when I hit the SUP720,  12.2 stops at
12.2.18 and I show nothing for the SUP720 on 12.3 or 12.4

And thanks to all for the ideas !!



On Wed, 07 Sep 2005 01:20:01 -070
Bruce Pinsky <bep at whack.org> wrote:

> -----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-----


******************************************
Richard J. Sears
Vice President         
American Internet Services                          
----------------------------------------------------
rsears at adnc.com
http://www.adnc.com
----------------------------------------------------
858.576.4272 - Phone
858.427.2401 - Fax
INOC-DBA - 6130
----------------------------------------------------

I fly because it releases my mind 
from the tyranny of petty things . . 


"Work like you don't need the money, love like you've
never been hurt and dance like you do when nobody's
watching."