The basic disconnect here is that you seem to think that BGP is to be
used to dictate policy to other networks on how to reach your network.
That is not and has never been the case.
When I learned BGP back in the 1990s, it was explicitly said that you
control your outbound traffic with your BGP
On Wed, Jan 24, 2024 at 09:22:06AM -0800, William Herrin wrote:
> On Wed, Jan 24, 2024 at 8:39???AM James Jun wrote:
> > On Wed, Jan 24, 2024 at 08:16:56AM -0800, William Herrin wrote:
> > > Sophistry. I buy IP transit from 3 providers, one of which has a 3 AS
> > > path to 3356.
> >
> > Again
On Wed, Jan 24, 2024 at 8:39 AM James Jun wrote:
> On Wed, Jan 24, 2024 at 08:16:56AM -0800, William Herrin wrote:
> > Sophistry. I buy IP transit from 3 providers, one of which has a 3 AS
> > path to 3356.
>
> Again you omit context.
What you're calling context, I call deceptive.
For one
On Wed, Jan 24, 2024 at 08:16:56AM -0800, William Herrin wrote:
> On Wed, Jan 24, 2024 at 8:11???AM James Jun wrote:
> > You (AS11875) have an operational need for good connectivity
> > into 3356 but, you made a poor purchasing decision by buying
> > IP transit for 11875 from a provider who has
On Wed, Jan 24, 2024 at 8:11 AM James Jun wrote:
> You (AS11875) have an operational need for good connectivity
> into 3356 but, you made a poor purchasing decision by buying
> IP transit for 11875 from a provider who has 10-AS path into
> 3356 instead of <=3 AS path. You've done a _bad_ job here
On Wed, Jan 24, 2024 at 07:25:42AM -0800, William Herrin wrote:
[ snip ]
> or I chose my words poorly. What I did say, and stand behind, was that
> applying local prefs moves BGP's route selection off the _defaults_,
> and if Centurylink was routing to me based instead on the defaults
> they'd
On Wed, Jan 24, 2024 at 5:23 AM Chris Adams wrote:
> Once upon a time, William Herrin said:
> > On Tue, Jan 23, 2024 at 4:00 PM Chris Adams wrote:
> > > Once upon a time, William Herrin said:
> > > > Nevertheless, in the protocol's design, the one expressed in the
> > > > RFC's, AS path length
>
> When you twist a policy knob to move BGP off its defaults, you take
> responsibility for making a better routing choice. And for correcting
> that choice if it should prove faulty. What I've seen here in this
> thread is a bunch of folks abdicating that responsibility. That's not
>
On Wed, Jan 24, 2024 at 7:02 AM Jon Lewis wrote:
> In one of his messages, William complained that the big bad networks are
> breaking the BGP rules by ignoring as-path length.
To be clear, I don't really care whether you're "breaking the rules."
Moreover, if my words suggested that I thought
On Wed, 24 Jan 2024, Jay R. Ashworth wrote:
- Original Message -
From: "Jon Lewis"
On Mon, 22 Jan 2024, William Herrin wrote:
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.
Not
Once upon a time, William Herrin said:
> On Tue, Jan 23, 2024 at 4:00 PM Chris Adams wrote:
> > Once upon a time, William Herrin said:
> > > Nevertheless, in the protocol's design, the one expressed in the
> > > RFC's, AS path length = distance.
> >
> > The RFC doesn't make any equivalence
On Tue, Jan 23, 2024 at 10:12:33PM -0800, William Herrin wrote:
> Respectfully Chris, you are mistaken.
>
> https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2.2
>
> "a) Remove from consideration all routes that are not tied for having
> the smallest number of AS numbers present in their
Bill,
> https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2.2
>
> "a) Remove from consideration all routes that are not tied for having
> the smallest number of AS numbers present in their AS_PATH
> attributes."
>
> So literally, the first thing BGP does when picking the best next hop
>
All,
> But that ship seems to have sailed.
The problem is well known and it consists of two orthogonal aspects:
#1 - Ability to signal the preference of which return path to choose by
arbitrary remote ASN
#2 - Actually applying this preference by remote ASN.
For #1 I have proposed some time
On Wed, Jan 24, 2024 at 12:55 AM Owen DeLong wrote:
> BGP is more of a PDVP (Policy Distance Vector Protocol).
Hi Owen,
That's a distinction without a difference. All but the most
rudimentary implementation of a distance-vector protocol supports
policy definition and enforcement. BGP has more
BGP is more of a PDVP (Policy Distance Vector Protocol). Policy will always
override Distance in BGP and is pretty much the key difference between an EGP
and an IGP.
Once you recognize that, the rest makes much more sense.
Owen
> On Jan 23, 2024, at 14:29, William Herrin wrote:
>
> On
On Tue, Jan 23, 2024 at 4:00 PM Chris Adams wrote:
> Once upon a time, William Herrin said:
> > Nevertheless, in the protocol's design, the one expressed in the
> > RFC's, AS path length = distance.
>
> The RFC doesn't make any equivalence between AS path length and
> distance. You are the one
> On Jan 22, 2024, at 6:53 PM, Jeff Behrns via NANOG wrote:
>
>>> William Herrin wrote:
> Until they tamper with it using localpref, BGP's default behavior with
> prepends does exactly the right thing, at least in my situation.
>
> I feel your pain Bill, but from a slightly different
- Original Message -
> From: "Jon Lewis"
> On Mon, 22 Jan 2024, William Herrin wrote:
>> 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.
>
> Not at all. Think like a service
William Herrin wrote:
> Nevertheless, in the protocol's design, the one expressed in the RFC's, AS
> path length = distance.
Since we're opening RFCs now, and somehow it is being opined that LOCAL_PREF is
a profit-driven conspiracy and a coordinated scheme concocted by commercial
networks to
On Tue, Jan 23, 2024 at 03:37:25PM -0800, William Herrin wrote:
> Nevertheless, in the protocol's design, the one expressed in the
> RFC's, AS path length = distance.
Bill,
The protocol was also developed at a time when everyone
utilized the same transit provider, and all other
Once upon a time, William Herrin said:
> Nevertheless, in the protocol's design, the one expressed in the
> RFC's, AS path length = distance.
The RFC doesn't make any equivalence between AS path length and
distance. You are the one trying to make that equivalence, but that's
not how BGP is used
On Tue, Jan 23, 2024 at 3:27 PM Tom Beecher wrote:
>> Unless overridden, BGP takes -distance- into account where distance =
>> AS path length.
>
> An AS_PATH length of 10 could be a physical distance of 1 mile.
>
> An AS_PATH length of 1 could be a physical distance of 1000 miles.
Nevertheless,
>
> Unless overridden, BGP takes -distance- into account where distance =
> AS path length.
>
An AS_PATH length of 10 could be a physical distance of 1 mile.
An AS_PATH length of 1 could be a physical distance of 1000 miles.
BGP TE communities exist to provide signalling in the event that the
On Tue, Jan 23, 2024 at 12:34 PM Niels Bakker wrote:
> BGP, while a distance vector protocol, famously does not take
> latency into account when making routing decisions.
Unless overridden, BGP takes -distance- into account where distance =
AS path length.
Centurylink has overridden that with a
On Tue, Jan 23, 2024 at 12:38 PM Tom Beecher wrote:
> 1. Experiment with 53356's TE communities to prevent them from announcing to
> upstreams that give you poor performance to 3356.
Respectfully, I rejected that approach because it doesn't address the
other few hundred instances of this
>
> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to yourselves.
>
That has absolutely
* b...@herrin.us (William Herrin) [Tue 23 Jan 2024, 21:02 CET]:
On Tue, Jan 23, 2024 at 11:45 AM Owen DeLong via NANOG wrote:
The catch to all of that, however, is that he’s not directly
peered with 3356 and many AS operators strip communities.
And even if I didn't, the problem isn't just
Once upon a time, William Herrin said:
> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to
* nanog@nanog.org (Owen DeLong via NANOG) [Tue 23 Jan 2024, 20:47 CET]:
The catch to all of that, however, is that he’s not directly peered
with 3356 and many AS operators strip communities.
Are there recent statistics on that last assertion?
-- Niels.
On Tue, Jan 23, 2024 at 11:45 AM Owen DeLong via NANOG wrote:
> The catch to all of that, however, is that he’s not directly peered with 3356
> and many AS operators strip communities.
And even if I didn't, the problem isn't just one ISP localprefing to
prefer distant routes. Centurylink most
> On Jan 23, 2024, at 10:47, Jay Borkenhagen wrote:
>
> William Herrin writes:
>>
>> The best path to me from Centurylink is: 3356 1299 20473 11875
>>
>> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
>> 11875 11875 11875
>>
>> Do you want to tell me again how that's a
William Herrin writes:
>
> The best path to me from Centurylink is: 3356 1299 20473 11875
>
> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
> 11875 11875 11875
>
> Do you want to tell me again how that's a reasonable path selection,
> or how I'm supposed to pass
>
> Apparently there is a conflict between what you want and what 47787 wants.
> As you both seem to be paying customers, you should probably ask 3356 to
> resolve that instead of us random internet folks.
>
Calling 3356 and saying "I know your global routing policy is to prefer a
customer
>
> I feel your pain Bill, but from a slightly different angle. For years the
> large CDNs have been disregarding prepends. When a source AS disregards
> BGP best path selection rules, it sets off a chain reaction of silliness
> not attributable to the transit AS's. At the terminus of that
>> Packets don't have customers, ISPs do. And in this case you're not a
>> customer of the ISP making the routing decision
>
> Incorrect. I am a customer of 3356. A residential customer, not a BGP
> customer. I'm paying them to route my packets too, and they're routing
> them poorly.
Oh, you
> On Jan 22, 2024, at 21:34, Forrest Christian (List Account)
> wrote:
>
> I really really wish there were a couple of well-known and globally respected
> communities which you could set to say either "this is a route of last
> resort" or "this is my preferred route".
You're not the first
> On Jan 23, 2024, at 00:43, William Herrin wrote:
>
> On Mon, Jan 22, 2024 at 3:34 PM Alex Le Heux wrote:
>> This is perfectly reasonable routing _if you're 3356_
>>
>> In this profit-driven world, expecting 3356 to do something that's
>> unprofitable for them just because it happens to
> At which point Centurylink chooses 40676 7489 11875 11875 11875 11875
> 11875 11875 11875.
>
>> This certainly seems like a reasonable path selection, in the context that
>> 47787 is likely a 3356 customer.
>
> That's -why- 3356 chooses the paths. 40676 and 47787 are customers,
> 1299 is a
On Jan 22, 2024, at 14:35, William Herrin wrote:
>
> The best path to me from Centurylink is: 3356 1299 20473 11875
>
> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
> 11875 11875 11875
>
> Do you want to tell me again how that's a reasonable path selection,
> or how I'm
> > William Herrin wrote:
Until they tamper with it using localpref, BGP's default behavior with prepends
does exactly the right thing, at least in my situation.
I feel your pain Bill, but from a slightly different angle. For years the
large CDNs have been disregarding prepends. When a
On Mon, Jan 22, 2024 at 6:43 PM William Herrin wrote:
> On Mon, Jan 22, 2024 at 5:59 PM James Jun wrote:
> > CL is choosing 3356 47787[x3] 53356 11875[x3] over better path via 1299:
> >This is not a Lumen/CenturyLink/Level 3 problem.
> > What you need to be doing is
>
> Hi James,
>
> My solution
On Mon, Jan 22, 2024 at 5:59 PM James Jun wrote:
> CL is choosing 3356 47787[x3] 53356 11875[x3] over better path via 1299:
>This is not a Lumen/CenturyLink/Level 3 problem.
> What you need to be doing is
Hi James,
My solution has been to add two more-specific routes to -your- routing
table so
You can use the ultimate BOFH BGP tool, which is to include the
network you don't want those announcements to go in the AS Path.
Let's say your ASN is 65000, and the target you want to not route
through that path is 65001.
For the path you want that network to route to, announce this AS Path:
On Mon, Jan 22, 2024 at 02:03:48PM -0800, William Herrin wrote:
>
> It offends my pride to handle it this way, but -you- shoulder the cost.
>
You're misdiagnosing the issue at hand.
CL is choosing 3356 47787[x3] 53356 11875[x3] over better path via 1299:
What you need to be doing is reaching
>
> As I already explained, neither the primary nor any of the backup
> providers directly peer with Centurylink, thus have no communities for
> controlling announcements to Centurylink.
No, but they do have an option to not announce to 47787.
https://docs.freerangecloud.com/en/bgp/communities
On Mon, Jan 22, 2024 at 4:16 PM Alex Le Heux wrote:
> > On Jan 23, 2024, at 00:43, William Herrin wrote:
> > Every packet has two customers: the one sending it and the one
> > receiving it. 3356 is providing a service to its customers. ALL of its
> > customers. Not just 47787. Sending the packet
>
> I’d bet that 47787 is a paying century link customer. As such, despite the
> ugliness of the path, CL probably local prefs everything advertised by them
> higher than any non-paying link. I’m willing to bet 1299 is peered and not
> paying CL.
>
It's almost as if you've done this before. :)
On Mon, Jan 22, 2024 at 3:34 PM Alex Le Heux wrote:
> This is perfectly reasonable routing _if you're 3356_
>
> In this profit-driven world, expecting 3356 to do something that's
> unprofitable for them just because it happens to be convenient for you is,
> well, unreasonable.
Hi Alex,
Every
I’d bet that 47787 is a paying century link customer. As such, despite the
ugliness of the path, CL probably local prefs everything advertised by them
higher than any non-paying link. I’m willing to bet 1299 is peered and not
paying CL.
Sending bits for revenue is almost always preferable to
And now you are faced with an object lesson as to why TE routes are so
prevalent.
Less specifics are your only functional alternative here. In most cases, you
shouldn’t need more than 2 per prefix.
Owen
> On Jan 22, 2024, at 12:16, William Herrin wrote:
>
> On Mon, Jan 22, 2024 at 5:23
On Mon, Jan 22, 2024 at 1:55 PM Nick Hilliard wrote:
> You have your own ASN, you have control over your own routing policy.
> Centurylink probably aren't going to be interested in engaging with you
> if you're not a customer. It's a pickle.
It's not a pickle for me. I'll announce three prefixes
William Herrin wrote on 22/01/2024 21:26:
At which point Centurylink chooses 40676 7489 11875 11875 11875
11875 11875 11875 11875.
[...]
You're telling me with a straight face that you think
that's*reasonable* routing?
yep, looks pretty reasonable, if you're Centurylink and 40676 is a
On Mon, Jan 22, 2024 at 1:11 PM Andrew Hoyos wrote:
> On Jan 22, 2024, at 14:35, William Herrin wrote:
>> The best path to me from Centurylink is: 3356 1299 20473 11875
>
>> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
>> 11875 11875 11875
>
>> Do you want to tell me again
On Mon, Jan 22, 2024 at 10:19 AM James Jun wrote:
> So, as a customer, you actually SHOULD be demanding your ISPs
> to positively identify and categorize their routes using local-pref
> and communities.
Hi James,
The best path to me from Centurylink is: 3356 1299 20473 11875
The path
I really really wish there were a couple of well-known and globally
respected communities which you could set to say either "this is a route of
last resort" or "this is my preferred route".
I feel like it would avoid many of us doing exactly what you're about to do
which is pollute the routing
On Mon, Jan 22, 2024 at 5:23 AM Jon Lewis wrote:
> You may be limited to seeing if your backup providers have community
> controls that would let you tell them "don't share with Centurylink"
As I already explained, neither the primary nor any of the backup
providers directly peer with
To expand on what others have said here, I find it helpful to think of BGP as a
policy enforcement protocol, rather than as a distance vector routing protocol.
To that end, there’s a generally expected hierarchy of routes, and then a lot
of individuality between networks. Having done
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
> wrote:
> > Standard practice is to localpref your customers up, which makes prepends
> > irrelevant. Why would anyone expect different behavior?
>
> It gives me, your paying
On Mon, 22 Jan 2024, William Herrin wrote:
On Mon, Jan 22, 2024 at 5:24 AM Patrick W. Gilmore 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
* b...@herrin.us (William Herrin) [Mon 22 Jan 2024, 15:05 CET]:
On Mon, Jan 22, 2024 at 5:24 AM Patrick W. Gilmore 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
On Mon, Jan 22, 2024 at 5:24 AM Patrick W. Gilmore 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
> The Internet is lying to itself, and that’s not a situation that can persist
> forever.
I am not sure I agree.
First, prepends are a suggestion. Perhaps a request. It has never (or at least
not for the 3 decades I’ve been doing this) been a guarantee. In the situation
below, perhaps the 5K
On Mon, 22 Jan 2024, William Herrin wrote:
Howdy,
Does anyone have suggestions for dealing with networks who ignore my
BGP route prepends?
I have a primary ingress with no prepends and then several distant
backups with multiple prepends of my own AS number. My intention, of
course, is that
Prepend contraction is becoming more common. You can’t really stop providers
from doing it, and it reduces BGP table size, which I’ve heard as a secondary
rationale. I’d love to see the statistics on that though.
BGP Communities seem to be the only alternative, and that limits your
engineering
Howdy,
Does anyone have suggestions for dealing with networks who ignore my
BGP route prepends?
I have a primary ingress with no prepends and then several distant
backups with multiple prepends of my own AS number. My intention, of
course, is that folks take the short path to me whenever it's
66 matches
Mail list logo
