On 5/31/2011 10:50 AM, Tim Franklin wrote:
My standard practice has always been to apply a high local preference
on customer-announced routes, medium local pref on peer-announced
routes, and low (but still higher than the system default of 100)
local pref on upstream-announced routes. The logic behind this is:
"I'd rather get paid for traffic than exchange traffic for free than
pay for traffic."
Which is good design, but still falls apart if, as per the OP, your customer is
deaggregating towards their other provider. Longest-match happends before you
even get into the BGP best-path algorithm, local-pref doesn't get a look-in.
In my particularly-humble opinion, it performs exactly as designed:
A customer who doesn't do anything special gets their traffic through
their link "to me".
A customer who intentionally does "something" gets what they've programmed.
A customer who asks can apply communities to override our default BGP
behaviors.
I'm only trying to change the default behavior of BGP, so if the
customer gets creative with their announcements, they can do what they wish.
pt
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
