On 10/2/21 08:14, Bill Woodcock wrote:
We did not use an NTA, but we did flush our cache immediately once
Slack had fixed their problem. I think that’s the right balance of
carrot and stick.
Tend to agree with this approach.
But I can see how an issue like this could be potentially relig
We did not use an NTA, but we did flush our cache immediately once Slack had
fixed their problem. I think that’s the right balance of carrot and stick.
-Bill
> On Oct 2, 2021, at 7:30 AM, Mark Tinka wrote:
>
> So, that wasn't fun, yesterday:
>
>
> https://lists.d
So, that wasn't fun, yesterday:
https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021340.html
We were also hit, given we run DNSSEC on our resolvers.
Interesting some large open resolver operators use Negative TA's for
this sort of thing. Not sure how this helps with the DNSSE
On 10/1/21 19:28, Randy Bush wrote:
in fact, this seems to be the modern conservative style for some years.
i sometimes wonder if it is worth the config pain.
If having routers dedicated to peering, transit or edge functions is
worth the extra pain, in lieu of doing it all on one box?
Ma
On 10/1/21 20:17, Adam Thompson wrote:
Do people in other parts of the world have access (both physical and
logical) to enough bilateral peering (and budgets...) that it makes
sense to deploy a router per peer?
Certainly not a router per peer, but a peering router per city, where it
may co
On 10/1/21 18:31, Tom Hill wrote:
Many (most?) route servers provide little control over who your routes
are advertised toward. This can be fun where DDoS is concerned.
I've used some that did have deny-list controls for ASNs, fail to
consistently apply those rules. Again, that was a 'fun' s
On 10/1/21 18:05, Laura Smith wrote:
Speaking as one of those smaller ISPs willing to do whatever it takes, perhaps
you could answer me this riddle.
- PoP in one of your "half-decent data centres" ... tick.
- Connnection to one of your "exchange point" ... tick.
- $certain_large_cdn pre
Thanks for your insight Matt, much appreciated.
On Fri, Oct 1, 2021 at 11:27 AM Joshua Pool via NANOG
wrote:
> [...]
> One could also note that it's 2021 and Cogent and Hurricane Electric are
> still not peered.
>
Bugger.
You're right.
I forgot to add "stupid human ego issues" to my list of reasons
why direct peering requests get ignored or
I wasn't aware of that, but I think that's perfect! And completely
reasonable on Netflix (or any content provider's part).
I'm sure Verizon's wordsmiths would argue that the "crowding" happened
upstream of the Verizon network, but if stated another way (like "the
paths into Verizon's networ
On Fri, Oct 1, 2021 at 9:08 AM Laura Smith via NANOG
wrote:
>
> > The bad news now, is, there are plenty of many, small, local
> > and regional ISP's who are willing to do whatever it takes to
> > work with the content providers. All that's required is some
> > network, a half-decent data centre
Hey Adam,
Peer is homonym, in this context peer refers to a BGP session with
whom you exchange your customer routes with, and it implies absence of
customers and transit in the same router. Whereas you interpreted peer
in its wider meaning of any BGP session.
On Fri, 1 Oct 2021 at 21:21, Adam Tho
I think instances where the end ISP is peered directly with Netflix and
demands more money is not valid at all. That should be normal cost of
doing business to increase capacity as the consumer demand grows.
The topic of interest is instances where the ISP is not directly peered
with Netflix and u
On 10/1/21 07:19, Blake Hudson wrote:
It's about time Netflix played
chicken with one of these ISPs and stopped offering service (or offered
limited service) to the ISPs that try to extort them and other content
providers: Sorry, your service provider does not believe in net
neutrality and h
IMHO, no, it's not worth it... at least, not unless you have a larger budget
than mine, a larger department than mine, and possibly more skilled operators
than I am.
I don't even grok how this is supposed to work - the only place I "peer" in the
classical sense is my local IX; all my other "pee
This is an automated weekly mailing describing the state of the Internet
Global IPv4 Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
Daily listings are sent to
On 10/1/2021 11:23 AM, Sean Donelan wrote:
In the old days, postal services used to charge the recipient of a
letter to deliver the letter. Then stamps were invented, and postal
services charged the sender of the letter, and the recipent got free
delivery.
Now there is free-shipping, an
> A partial table with no default is perfectly fine for a peering router.
>
> As long as your peering router knows how to get to your prefixes and
> those of your customers, as well as the prefixes of the networks you
> peer with, you're good to go.
in fact, this seems to be the modern conservati
On 01/10/2021 17:05, Laura Smith via NANOG wrote:
> - $certain_large_cdn publishes routes on route server ? Nope.
Many (most?) route servers provide little control over who your routes
are advertised toward. This can be fun where DDoS is concerned.
I've used some that did have deny-list controls
Having done peering for many $big_boys_club and $small_isps, it always
comes down to politics, $$ and time. The balance may change but end of day
its those variables and its a painful game some days. From all sides :(
-jim
On Fri, Oct 1, 2021 at 1:07 PM Laura Smith via NANOG
wrote:
>
> > The
In the old days, postal services used to charge the recipient of a letter
to deliver the letter. Then stamps were invented, and postal services
charged the sender of the letter, and the recipent got free delivery.
Now there is free-shipping, and pre-paid return envelopes for DVDs.
Of cours
> The bad news now, is, there are plenty of many, small, local
> and regional ISP's who are willing to do whatever it takes to
> work with the content providers. All that's required is some
> network, a half-decent data centre and an exchange point. Gone
> are the days where customers clamored to
Giovane,
While Murkund’s point about some devices ignoring this option (I’m not sure why
any cellphones would accept it, for example, Android or otherwise, since they
get time from the cellular network), it’s pretty much an industry standard that
desktop and WiFi *VoIP* phones all use it. It’s
Hi Giovane, a time server is a required DHCP option for DOCSIS devices.
This uses the older TIME protocol (UDP port 37, RFC 868). However, it's
common for DOCSIS devices like MTAs, STBs, etc to also request and use
NTP server addresses received via DHCP (they may apply this using SNTP
rather th
> On 1 Oct 2021, at 16:46, Mark Tinka wrote:
>
>
>
>> On 10/1/21 16:19, Blake Hudson wrote:
>>
>>
>> I'll never understand over how ISPs see content providers as the enemy (or a
>> rival). The content is why ISPs have customers. Don't get upset when your
>> customer uses the service tha
Hi Giovane
On Fri, Oct 01, 2021 at 04:12:15PM +0200, Giovane C. M. Moura via NANOG wrote:
> hello folks,
>
> So DHCP can also be used to set NTP servers on clients, for both
> IPv4[rfc2132] and IPv6[rfc5908].
>
> I'm looking for statistics on setting NTP servers on clients using DHCP,
> in the w
On 10/1/21 16:19, Blake Hudson wrote:
I'll never understand over how ISPs see content providers as the enemy
(or a rival). The content is why ISPs have customers. Don't get upset
when your customer uses the service that you sold them (in a way that
is precisely in accordance with the expe
hello folks,
So DHCP can also be used to set NTP servers on clients, for both
IPv4[rfc2132] and IPv6[rfc5908].
I'm looking for statistics on setting NTP servers on clients using DHCP,
in the wild. Does anyone know if there is any available somewhere?
I'm also looking for reports from operators a
On 16/02/2021 22:51, Compton, Rich A wrote:
> There was the outage in 2014 when we got to 512K routes.
> http://www.bgpmon.net/what-caused-todays-internet-hiccup/
There was a similar issue in 1998/9 or so when we got to 64K routes,
which broke the routing table index (which defaulted to a uint1
On 10/1/2021 8:48 AM, Sean Donelan wrote:
South Korean Internet service provider SK Broadband has sued Netflix
to pay for costs from increased network traffic and maintenance work
because of a surge of viewers to the U.S. firm's content, an SK
spokesperson said on Friday.
[...]
Last year, N
Yet another peering dispute ending in litigation?
From: NANOG on behalf of Sean
Donelan
Date: Friday, 1 October 2021 at 7:21 PM
To: nanog@nanog.org
Subject: S.Korea broadband firm sues Netflix after traffic surge
South Korean Internet service provider SK Broadband has sued Netflix to
pay for c
South Korean Internet service provider SK Broadband has sued Netflix to
pay for costs from increased network traffic and maintenance work because
of a surge of viewers to the U.S. firm's content, an SK spokesperson said
on Friday.
[...]
Last year, Netflix had brought its own lawsuit on whether
Yeah, but loose mode is inherently useless on any router carrying full tables.
(Ok, it can spot bogons, but that's a side effect and I have other ways to
catch those.)
Point being that MANRS implementation in the "simple" case is (or, at least,
CAN be) almost trivially easy, but in the "complex
For strict-mode... Completely agree.
As has been previously said, this is a tool that all players involved need to
understand. This is no different than everyone correctly using BGP in their
application for their outcomes.
> On Sep 29, 2021, at 12:07 PM, Adam Thompson wrote:
>
> We just ran i
So, I have it on good authority that from release 21.7.R1, Nokia not
only introduces LDPv6 to their IXR platform, but also provides native
support for l2vpnv6 and l3vpnv6 signaling.
AFAIK, Cisco and Juniper only support mpls2ip forwarding for LDPv6, and
all other VPN services can only be signa
35 matches
Mail list logo
