[c-nsp] BGP path preference

[Bob Tinkelman]

I'd suggest using route-maps to *lower* the local-pref on
routes that contain ASNs from two or your upstreams.
- Bob


> I have a situation with one of our upstreams that I'm trying to fix.  We
> peer with Level3 (3356), specifically we peer with 19094 which is the
> old Telcove (Adelphia) infrastructure that L3 bought and is slowing
> migrating to 3356.  I'm having trouble pushing traffic to that circuit.
>   The preferred route is generally the shorter Cox (22773) path.  I'm
> matching about 100 L3 prefixes to raise the weight and local pref, just
> like I am for our Cox circuit and our AT&T circuit but I'm still seeing
> plenty of Cox paths chosen over the L3 path.  This is primarily because
> a typical prefix advertised over L3 arrives at my border with "19094
> 3356 " and other ASNs whereas Cox may still have the same number of
> backend ASNs but only 22773 once it enters the Cox AS.

> Does anyone have any suggestions on how to work around this?  L3 will
> eventually fix it when they eliminate 19094 but who knows when that will
> be.  I thought about trying to use a regex to match "19094 3356" to
> raise local pref even higher.  I also see plenty of routes that from
> 3356 directly to 22773 (L3 peering w/ Cox wo/ Telcove in the middle).  I
> could try to match routes that originate on 3356 and 19094 and raise the
> local pref of those prefixes.  Do I need to raise it on one AND lower it
> on the other border router or would doing it on one suffice and be
> manageable?  Would this regex matching be a good best (better?) practice
> for all circuits over matching an ACL or prefix-list of prefixes?  If so
> would one match on origin or simply if the ASN was in the path?

> I have L3 and AT&T on one border and Cox on another.  There's an iBGP
> mesh between both borders and both cores.

> Thanks for any suggestions,
>   Justin