* mikeboli...@gmail.com (Mike Bolitho) [Wed 13 Nov 2019, 12:05 CET]:
This has gone well beyond out of scope of the NANOG list. Discussing who
watches what kind of content has nothing to do with networking. Can you
guys take the conversation elsewhere?
On the contrary. This discussion informs
This has gone well beyond out of scope of the NANOG list. Discussing who
watches what kind of content has nothing to do with networking. Can you
guys take the conversation elsewhere?
- Mike Bolitho
On Tue, Nov 12, 2019 at 4:34 PM Matthew Petach
wrote:
>
> My point was that Disney has a lock
Justin’s original question was “….. Is it well known where the newly released
Disney+ streaming service content is sourced?...”
With Eric’s finding of “I saw various content being served from Akamai, Amazon,
Fastly and Limelight so far. I'm in Montreal.”
Is this an absolute answer as to
ZTE M6000-S V3.00.20(3.40.1)
We are moving away from this platform so I can not be bothered with
requesting a fix. In the past they have made fixes for us, so I
believe they would also fix this issue if we asked them to do so.
Also I would like to state that I have not personally verified that
I have been recommending to many friends to check in daily at
http://irrexplorer.nlnog.net/ to make sure everything is healthy with their
prefixes ...
Today a colleague reported a problem with an AS58299 ad appearing in "their
prefixes".
I went look and was showing up on our ASNs too.
It took me
I think it would be more on topic if everyone weren't just guessing what
users will do based on hypothetical behavior patterns and hypothetical
content shifts.
I WOULD be interested to see some data showing e.g. a drop in traffic to
one service and a boost in traffic to another service when a
Not ideal, sure, but if it’s only for the SYN (as you seem to indicate),
splitting the flow shouldn’t have material performance degradation?
> On Nov 13, 2019, at 11:51, Toke Høiland-Jørgensen wrote:
>
>
>
>> On 13 November 2019 17:20:18 CET, Matt Corallo wrote:
>> This sounds like a bug
It is certainly odd, but it's definitely a "thing."
https://archive.nanog.org/meetings/nanog37/presentations/matt.levine.pdf
On Wed, Nov 13, 2019 at 10:24 AM Matt Corallo wrote:
>
> This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> is... out of spec to say the
+1 for the IX in Marseille!
Cross-connect charges are always the same with IX: you need to buy the
pre-cabling (see below) and afterwards you pay CC with MRC:
Costs for pre-cabling from your rack to the MMR (NRC):
6 SMD pairs: 2.475,00 Eur
12 SMD pairs: 4.125,00 Eur
24 SMD pairs: 5.960,00 Eur
On Wed, 13 Nov 2019, Baldur Norddahl wrote:
In any case, is it not recommended that users of anycast proxy packets
that arrive at the wrong place? To avoid this kind of issue.
In typical anycast deployments there is no feasible way to figure out
where the "right place" is.
It would be very
Can anyone share a contact at Netflix who can help work through this?
--
Mark Thompson
(408) 202-1278
Not to condone what cloudflare is doing, but...
An ECN connection will have different bits on various packets for the
duration of the connection -- pure ACKs (ACKs not piggybacking on data)
will have the ECN bits as 00b, while all other packets will have either
01b, 10b (when no congestion was
It does when the split flows land in different anycast origin POPs.
Making a few assumptions from the traceroutes, the ECMP paths are sending
some packets to Hamburg and some to Denmark. Each POP may be getting
parts of what should be a single TCP stream, and I doubt they have
anything to
That email (cl...@disneystreaming.com) bounced back as undeliverable.
-Aaron
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Michael Crapse
Sent: Tuesday, November 12, 2019 7:27 PM
Cc: NANOG list
Subject: Re: Disney+ Geolocation issues
There has been a continued flurry of
as one of the authors of that talk, it definitely is "a thing", has been
for years and years and years, and indeed, mostly works.
t
On Wed, Nov 13, 2019 at 12:18 PM Hunter Fuller wrote:
> It is certainly odd, but it's definitely a "thing."
>
>
I am testing disabling our use of ECMP as it is not strictly necessary and
we are moving to a new platform anyway. Waiting for feedback from the
customer to hear if this fixes the issue.
In any case, is it not recommended that users of anycast proxy packets that
arrive at the wrong place? To
On 13 November 2019 17:20:18 CET, Matt Corallo wrote:
>This sounds like a bug on Cloudflare’s end (cause trying to do anycast
>TCP is... out of spec to say the least), not a bug in ECN/ECMP.
Even without anycast, an ECMP shouldn't hash on the ECN bits. Doing so will
split the flow over
This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
is... out of spec to say the least), not a bug in ECN/ECMP.
> On Nov 13, 2019, at 11:07, Toke Høiland-Jørgensen via NANOG
> wrote:
>
>
>>
>> Hello
>>
>> I have a customer that believes my network has a ECN problem.
On 11/13/19 9:49 AM, Matthew Huff wrote:
> It’s not about optimization, it’s about the contract with the content
> providers. The agreement is to restrict content by geographical regions
> mainly for marketing purposes. They block VPN access to keep people from
> bypassing those restrictions.
For all those in the current and future thread. We were successful in
reaching to Disney by emailing them with our subnet
netad...@disneystreaming.com
On Wed, 13 Nov 2019 at 08:26, Robert Blayzor wrote:
> On 11/13/19 9:49 AM, Matthew Huff wrote:
> > It’s not about optimization, it’s about the
Using a TPIA provider here at home in Nova Scotia same issue.
-jim
On Tue., Nov. 12, 2019, 6:29 p.m. Michael Crapse,
wrote:
> Myself and a few other ISPs are having our eyeballs complain about
> disney+ saying that they're on a VPN. Does anyone have any idea, or who to
> contact regarding this
On 11/12/19 5:28 PM, Michael Crapse wrote:
> Myself and a few other ISPs are having our eyeballs complain about
> disney+ saying that they're on a VPN. Does anyone have any idea, or who
> to contact regarding this issue?
> This is most likely improper geolocation databases. Anyone have an idea
>
We're seeing the same thing. Actually we saw it during pre-signup.
Reached out to Disney+ weeks ago as well, with no response. Now it's
launched, our support lines are flooded with people unable to give Disney
all their moneys.We finally got through to Disney+ support after 2.5hrs
on hold to
On Tue, Nov 12, 2019 at 9:18 PM Michael Crapse wrote:
> IPv6 is a lot more granular when it comes to geolocation data. It is also
> very very unlikely that the block has been used before, and you never know
> what the previous owner did or what geolocation/VPN blacklists it was added
> to. Let
It’s not about optimization, it’s about the contract with the content
providers. The agreement is to restrict content by geographical regions mainly
for marketing purposes. They block VPN access to keep people from bypassing
those restrictions. It’s true of all the streaming providers.
> On
Hey Everyone,
I'm working with 3 ISPs currently who are having Geo Location issues with
clients being told they are out of the US. When their IPs are checked via a
free Geo IP tool everything is showing up correctly. Anyone have any
insight on who Disney+ is using for their GeoLocation services
I concur. This is silly off-topic. You don’t have to go home, but you can’t
stay here, according to NANOG guidelines.
-mel
> On Nov 13, 2019, at 4:57 AM, Bryan Holloway wrote:
>
>
>
>> On 11/13/19 1:06 PM, Niels Bakker wrote:
>> * mikeboli...@gmail.com (Mike Bolitho) [Wed 13 Nov 2019,
On 11/13/19 1:06 PM, Niels Bakker wrote:
* mikeboli...@gmail.com (Mike Bolitho) [Wed 13 Nov 2019, 12:05 CET]:
This has gone well beyond out of scope of the NANOG list. Discussing who
watches what kind of content has nothing to do with networking. Can you
guys take the conversation elsewhere?
CAVAET: I don't have a dog in this hunt.
On 11/13/19 6:46 AM, Mel Beckman wrote:
This is silly off-topic. You don’t have to go home, but you can’t
stay here, according to NANOG guidelines.
https://www.nanog.org/resources/usage-guidelines/ >
https://www.nanog.org/bylaws/
"The NANOG mailing
> Hello
>
> I have a customer that believes my network has a ECN problem. We do
> not, we just move packets. But how do I prove it?
>
> Is there a tool that checks for ECN trouble? Ideally something I could
> run on the NLNOG Ring network.
>
> I believe it likely that it is the destination that
Any suggestions on a good telecom hotel for a cloud provider in Marseille?
Interxion has a campus there with 2 buildings, a huge number of carriers and
serves as the hand off point for a large number of undersea cables. Does anyone
know anything about the facility in terms of space and power
Agreed. This is a problem, and it has happened before. This is not
the first time.
I asked Job Snijders (a maintainer of IRRExplorer) about it, and
here's what he had to say.
I don't think he should set an arbitrary threshold for excluding large
prefixes from IRRExplorer. I think the prefix
On Wed, Nov 13, 2019 at 11:36 AM Saku Ytti wrote:
> On Wed, 13 Nov 2019 at 18:27, Matt Corallo wrote:
> > This sounds like a bug on Cloudflare’s end (cause trying to do anycast
> TCP is... out of spec to say the least), not a bug in ECN/ECMP.
>
> Not true. Hash result should indicate discreet
Apple has had requirements in place for a while that developers and the
like had to start only supporting secure connections (App Transport
Security - basically apps are no longer allowed to make http connections).
Likely they may have thrown the switch on some backend stuff to finally
The route has already been removed!
Thanks!
Em qua, 13 de nov de 2019 às 14:00, Douglas Fischer <
fischerdoug...@gmail.com> escreveu:
> I have been recommending to many friends to check in daily at
> http://irrexplorer.nlnog.net/ to make sure everything is healthy with
> their prefixes ...
>
>
Hello,
On Wed, Nov 13, 2019 at 8:35 PM Saku Ytti wrote:
>
> On Wed, 13 Nov 2019 at 18:27, Matt Corallo wrote:
>
> > This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> > is... out of spec to say the least), not a bug in ECN/ECMP.
>
> Not true. Hash result should
I can confirm this works well. It’s a bit tricker w/ IPv6 but with IPv4 it
works and you can serve a lot of software updates out of the cache.
Mac mini w/ large SSD is a common application that people do
# AssetCacheManagerUtil status
..
CacheDetails = {
"Apple TV Software" =
Hey there,
Puerto Rico IX , famously known as PRIX , is now operational.
You can visit www.puertoricoix.net to see sites you can connect to PRIX,
members and join Ix mailing list.
There are no fees to join the IX. We hope to keep this, this way until
there is enough interest to form a non
Does anyone know if there is an apple cache?
Today we noticed that apple store applications and updates are not caching
anymore by HTTPs cache servers, and when we checked through DPI, we found that
it's been changed into HTTPS! Does anyone know what is going on?
Ahmed
Like it or not (and I really don’t), the majority of modern CDNs are using TCP
over Anycast.
It’s ugly and it’s prone to problems like this. It’s nice to see a customer
with know-how actually publicizing and digging into the problem.
Until now, I believe an unknown number of customers have
All mpls-interfaces are listed and policy is just traffic-eng ospf.
Nick
From: James Cornman
Sent: Wednesday, November 13, 2019 2:43 PM
To: Fawcett, Nick
Cc: nanog@nanog.org
Subject: Re: Brocade CER MPLS
Ensure that 'mpls-interface xxx' is on for all of the interfaces, and also
ensure that
Hi Ahmed,
We have been using the Apple specific content caching feature for a
while now.
It's something you enable on a mac (we use a mac mini) which then get
discovered on your local network via a DNS TXT record or bonjour.
https://support.apple.com/en-au/guide/mac-help/mchl3b6c3720/mac
Hope
On Wed, 13 Nov 2019 at 18:27, Matt Corallo wrote:
> This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> is... out of spec to say the least), not a bug in ECN/ECMP.
Not true. Hash result should indicate discreet flow, more importantly
discreet flow should not result
I have one CER (let's call him Charlie) that is not able to build an LSP tunnel
to another CER. Shows "Currently found no route. Will schedule for retry".
Both CER's can ping and traceroute each other. When I had the LSP to the
destination router (Snoopy) it adds the LSP and shows UP in
What version of Netiron are you running on each and do they both have the
adv license key enabled? do show license it should show:
[image: image.png]
Erich Kaiser
The Fusion Network
er...@gotfusion.net
Office: 815-570-3101
On Wed, Nov 13, 2019 at 2:54 PM Fawcett, Nick via NANOG
wrote:
>
On Thu, Nov 14, 2019 at 12:25 AM Matt Corallo wrote:
>
> This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> is... out of spec to say the least), not a bug in ECN/ECMP.
Err. I really don't think that there is any sort of spec that
covers that :-P
Using Anycast for
No.
We do not have any local caches yet.
On Wed, Nov 13, 2019 at 16:29 Darin Steffl wrote:
> My guess is Aeronet already has a Netflix OCA but Netflix may still be
> interested adding some gear on the IX for other ISP's that don't qualify
> for their own appliance.
>
> Also, cloudflare would
My guess is Aeronet already has a Netflix OCA but Netflix may still be
interested adding some gear on the IX for other ISP's that don't qualify
for their own appliance.
Also, cloudflare would likely want to add a POP here as well. They're
trying to be within 10ms of every ISP in the world or
RFC 7094 (https://tools.ietf.org/html/rfc7094) describes the pitfalls &
risks of using TCP with an anycast address. It recognizes that there are
valid use cases for it, though.
Specifically, section 3.1 says this:
>>>
Most stateful transport protocols (e.g., TCP), without modification,
do
On 11/13/19 3:24 PM, Fawcett, Nick via NANOG wrote:
I have one CER (let’s call him Charlie) that is not able to build an LSP
tunnel to another CER. Shows “Currently found no route. Will schedule
for retry”. Both CER’s can ping and traceroute each other. When I had
the LSP to the destination
* Saku Ytti
> Not true. Hash result should indicate discreet flow, more importantly
> discreet flow should not result into two unique hash numbers. Using
> whole TOS byte breaks this promise and thus breaks ECMP.
>
> Platforms allow you to configure which bytes are part of hash
> calculation,
51 matches
Mail list logo
