Yes. Or just sending new stuff in the old ticket. (Apparently, you get
a different guy each time, keep trying until you find one who is
willing to act.)
That didn't help either.
First, they asked for a proof that I did not use the IP before. After
sending that proof, they told me that the
For me, it did. To be fair I did have two tickets open through two different
channels. One of the tickets came back with advice that they had reset the
score on the domain and IP address as I advised them that it was a private mail
server, in use by one person (myself) with 2-3 mailboxes in use
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 su
> 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 p
> 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 be
> 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
>> 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 s
I spoke with someone at Mimecast and we concluded the the customer of
mimecast has setup that rule (likely the whole of *.tools), since they
could not find anything on there end that didnt like bgp.tools
On Wed, Jan 17, 2024 at 10:54 PM Christopher Hawker
wrote:
>
> It'd be interesting to know
Anyone else see a lot of traffic inbound from the Internet last night
(early this morning) at ~3:00 a.m. central time? I see an IP Address,
(93.184.215.240 - EdgeCast), which I think is EdgIO (fka limelight).
Any idea what this is related to? (something tells me it's a game update)
--
-Aaron
I'm seeing an uptick from Apple's AS6185, along with the usual CDNs,
all around that time. Looks like there is a new iOS update (17.3).
On Tue, Jan 23, 2024 at 9:19 AM Aaron Gould wrote:
>
> Anyone else see a lot of traffic inbound from the Internet last night
> (early this morning) at ~3:00 a.m.
Same on our side + Fastly, Akamai, a little bit of Apple too. Not sure what
content exactly.
On Tue, Jan 23, 2024 at 10:36 AM Charles Monson
wrote:
> I'm seeing an uptick from Apple's AS6185, along with the usual CDNs,
> all around that time. Looks like there is a new iOS update (17.3).
>
> On T
I tried going to bgp.tools at the office the day after I sent that email and
was able to get to it, so must've just been some goofiness.
From: NANOG on behalf of Ben Cox via
NANOG
Sent: Tuesday, January 23, 2024 7:51 AM
To: ch...@thesysadmin.au
Cc: nanog
Subje
There was a Fortnite (game) release some time around 09:00 UTC this morning, so
that could be it
Ian
On Tue, 23 Jan 2024, at 3:19 PM, Aaron Gould wrote:
> Anyone else see a lot of traffic inbound from the Internet last night
> (early this morning) at ~3:00 a.m. central time? I see an IP A
>
> 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 chain
>
> 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 learned
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 commu
> 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 re
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 di
* 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.
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 y
* 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 one
>
> 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 noth
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 problem
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
>
> 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
st
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, i
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 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 AS
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 ta
- 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 provid
> 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 angle.
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 t
32 matches
Mail list logo
