nanog mailing list archives

Re: Networks ignoring prepends?


From: James Jun <james.jun () towardex com>
Date: Mon, 22 Jan 2024 13:18:43 -0500

On Mon, Jan 22, 2024 at 06:02:53AM -0800, William Herrin wrote:
On Mon, Jan 22, 2024 at 5:24???AM Patrick W. Gilmore <patrick () ianai net> wrote:
Standard practice is to localpref your customers up, which makes prepends irrelevant. Why would anyone expect 
different behavior?

It gives me, your paying customer, less control over my routing
through your network than if I wasn't your paying customer. That
seems... backwards.


Nope, that is not at all backwards.

Have you actually wondered what would happen, if every major ISP stopped classifying routes with localpref, and treated 
every route received by them (including customers and external peers) on same local-pref, so your AS prepending can 
work easily?

Some 21 years ago, there was this little known story during early stages of the IPv6 development, called 6bone.  Aside 
from the lack of native IPv6 (where everything had to be tunneled), the #1 issue that guaranteed IPv6 sucked many times 
worse than IPv4 back in the day was the lack of BGP clue by most of IPv6 DFZ participants at that time, where nobody 
classified any of their routes accordingly with localpref and communities.

Not classifying your routes with local-pref leads to complete operational chaos, including world-tour hair-pin 
sightseeing becoming very common with IPv6 during 6bone days (which resulted in rise of as30071/occaid to dominate the 
IPv6 DFZ for several years for many to transition out of 6bone).  Not classifying routes with local-pref means you do 
not care whether a particular peer is a settlement-free peer or a customer-- this lack of relationship classifiction 
leads to operational harm:  A customer may be paying you $/bits expecting you to deliver your on-net traffic onto them 
over their paid peering (or transit) link they bought from you, except, only to find you preferring an IX peer (e.g. 
Hurricane Electric, etc. over IX) as best-path, even without any AS Path prepending involved. 

Further, not classifying routes with local-pref and ident communities means you are entirely at the mercy of 
prefix-lists applied on your export policy.  A very common occurrence is often a rookie ISP appeared to be giving 
"transit" to a major Tier-1 backbone on a route that was supposed to be customer-originated route, but this network 
selected AS-Path via its uptream provider as best-path, instead of direct connection into the said customer.  This 
happens a lot on a route that is "downstream of a downstream" customer, who is also multi-homed with the said rookie 
ISP's upstream Tier-1 provider, thereby resulting in equidisant AS-Paths to what is supposed to be a 
customer-originated route.  Scale this up to many routes and you have complete chaos and breakdown of your BGP routing 
table.



So, as a customer, you actually SHOULD be demanding your ISPs to positively identify and categorize their routes using 
local-pref and communities.  In fact, I will never purchase IP transit with BGP from a provider who doesn't categorize 
routes with local-pref.  As a customer, if you want more control over your network's incoming traffic, you need to 
instead ask your upstream providers about their BGP routing policy and how well they support BGP communities to let you 
steer traffic, and use those communities to make absolute traffic decisions.



Always remember this #1 rule of BGP decision process:  AS Path is a **tie-breaker** to local-pref classification.  When 
you prepend AS Path, your goal is to try to steer traffic from routes that are in the same category (i.e. customer or 
peer) as you.  When your goal is absolute steering (i.e. absolute as in, do not advertise to a particular peer, or make 
your connection standby backup where no traffic ever comes until there is complete outage on the other path, etc), you 
absolutely SHOULD be using BGP communities provided by your upstream IP provider.  If your IP transit provider does not 
provide extensive BGP communities to meet your requirements, cancel their service and give your business to someone 
else.

A rookie BGP mistake that is commonly made made by those without real-world experience, is the assumption that AS Path 
prepending should deliver absolute traffic steering -- it does not, and should NOT, by design.  The BGP Best-Path 
Selection Algorithm is taught very well in the CCIE curriculum, but last I looked, they don't teach you on the _why_, 
only on on the how.  So it's common to see enterprise CCIE's working for VARs often falling into the false assumption 
of AS Path.  See 
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#toc-hId-1778347102

Hope this clarifies.

James


Current thread: