- NANOG - lists.nanog.org

FCC Seeks Comment on Effects of June 15 T-Mobile Outage
by Sean Donelan 23 Jun '20

23 Jun '20

FCC Public Safety and Homeland Security Bureau Seeks Comment on Effects of June 15, 2020 T-Mobile Outage on Public Safety Entities, Government Entities, and Consumers https://www.fcc.gov/document/fcc-seeks-comment-effects-june-15-t-mobile-out… >From T-Mobile's statement: https://www.t-mobile.com/news/update-for-customers-on-network-issues "The trigger event is known to be a leased fiber circuit failure from a third party provider in the Southeast. This is something that happens on every mobile network, so we’ve worked with our vendors to build redundancy and resiliency to make sure that these types of circuit failures don’t affect customers. This redundancy failed us and resulted in an overload situation that was then compounded by other factors. This overload resulted in an IP traffic storm that spread from the Southeast to create significant capacity issues across the IMS (IP multimedia Subsystem) core network that supports VoLTE calls." Other notable national telecommunication failures AT&T - January 15 1990, AT&T Long Distance Network Collapse MCI Worldcom - August 1999, Multi-day frame-relay network failure Centurylink - December 27, 2018, 37-hour nationwide outage

1 0

Fiber in the power space
by Fletcher Kittredge 23 Jun '20

23 Jun '20

We are looking for an engineering firm with significant experience in FTTX in the power space. Extra points if you have worked with Co-ops. -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net

1 0

Is there any data on packet duplication?
by Hal Murray 23 Jun '20

23 Jun '20

How often do packets magically get duplicated within the network so that the target receives 2 copies? That seems like something somebody at NANOG might have studied and given a talk on. Any suggestions for other places to look? Context is NTP. If a client gets an answer, should it keep the socket around for a short time so that any late responses or duplicates from the network don't turn into ICMP port unreachable back at the server. Nothing critical, just general clutter reduction. I have packet captures from a NTP server. I'm trying to sort things out. There are a surprising (to me) number of duplicates that arrive back-to-back, sometimes the timestamp is the same microsecond. They could come from buggy clients, but that seems like an unlikely sort of bug. -- These are my opinions. I hate spam.

7 17

60 ms cross-continent
by William Herrin 23 Jun '20

23 Jun '20

Howdy, Why is latency between the east and west coasts so bad? Speed of light accounts for about 15ms each direction for a 30ms round trip. Where does the other 30ms come from and why haven't we gotten rid of it? c = 186,282 miles/second 2742 miles from Seattle to Washington DC mainly driving I-90 2742/186282 ~= 0.015 seconds Thanks, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/

23 30

Re: Is there any data on packet duplication?
by Hal Murray 23 Jun '20

23 Jun '20

bill(a)herrin.us said: > NTP you say? How does iburst work during initial sync up? How does it work, or how should it work? 1/2 :) NTP has been around for a long time. It looks very simple, so anybody thinks they can toss off an implementation without much thought. It will probably work, mostly. The response from an NTP server includes a timestamp that the client put into the request. The client can use that to reject delayed responses to a previous request. When I first started looking for duplicates, I found lots of them. They were NTP version 1 requests. NTP is up to version 4. Version 1 came out in 1988, RFC 1059. Since the requests are identical, there is no way for the client to separate expected responses from delayed responses from a previous request. Does anybody happen to know what equipment or software or OS/distro is sending version 1 requests? -- These are my opinions. I hate spam.

1 0

infrastructure focused interviews and questions
by Mehmet Akcin 22 Jun '20

22 Jun '20

hi there, I've started a few weeks ago hosting a youtube/twitch/twitter live video show (simultaneous stream) hosting key people who are involved in the exec/operations/engineering of internet infrastructure companies either as consumer or service providers. my idea is to create a platform where questions/concerns can be asked directly to executives/key decision-makers and hopefully get answers. Very similar to Reddit AMA but with focus on telecom/datacenter/infrastructure/DNS/etc. For example, I will have execs from zayo, Windstream, aqua comms, packet fabric this week as my guests where you will be able to ask questions directly. There will be also a 1-1 discussion with APNIC's Chief Scientist Geoff Houston about internet growth during lockdowns, and more. you can watch the shows live, ask questions and be part of the conversation from all these platforms. example: https://www.youtube.com/watch?v=ff4x9IwBHEI starting in 15 minutes with Windstream. fblive https://www.facebook.com/infrapediainc/videos/270701217367462/ twitter https://twitter.com/mhm7kcn if you have recommendation on speakers you want to see, ask questions, you can contact me offlist. I thought I would share this here, I am sorry if this is off-topic. Invite people to participate, ask questions, and more. mehmet

1 0

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table
by Jon Lewis 21 Jun '20

21 Jun '20

On Wed, 17 Jun 2020, Richa wrote: > Job, > > >> RPKI ROA creation is a big hammer. Everyone needs to think carefully >> about each ROA they create and if it will positively or negatively >> impact their network. > > Could you please shed some more light on the above? > > How would ROA negatively impact if ROA(s) is created such that the entire prefix set is covered? Just like I said, if you create an ROA for an aggregate, forgetting that you have customers using subnets of that aggregate (or didn't create ROAs for customer subnets with the right origin ASNs), you're literally telling those using RPKI to verify routes "don't accept our customers' routes." That might not be bad for "your network", but it's probably bad for someone's. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

2 1

A spammer is harvesting email addresses from the NANOG list.
by Tim Pozar 21 Jun '20

21 Jun '20

Looks like a spammer is harvesting email addresses from the NANOG list. i I will be unscribing as I don't need this additional noise in my mailbox. Tim ----- Forwarded message from Michele Jemmi <datinggirl09(a)randoml.fun> ----- Date: Sat, 20 Jun 2020 16:06:05 -0500 From: Michele Jemmi <datinggirl09(a)randoml.fun> To: pozar(a)lns.com Subject: Re: Re: 60 ms cross-continent So, where did u leave? ----- End forwarded message ----- -------- Forwarded Message -------- Subject: Re: Re: 60 ms cross-continent Date: Sat, 20 Jun 2020 15:59:05 -0500 From: Michele Jemmi <datinggirl09(a)randoml.fun> Reply-To: Michele Jemmi <datinggirl09(a)randoml.fun> To: pozar(a)lns.com hiyaa u made my kittyyyyy sad ----- End forwarded message ----- -------- Forwarded Message -------- Subject: Re: 60 ms cross-continent Date: Sat, 20 Jun 2020 15:52:05 -0500 From: Michele Jemmi <lovelygirl09(a)rammy.pw> Reply-To: Michele Jemmi <datinggirl09(a)randoml.fun> To: pozar(a)lns.com hey Having u so close is what I need the most, =?UTF-8?Q?Tim_Po=C5=BE=C3=A1r?= I want to feel yur love completely. Do u want me to go or will u come for me? .. ----- End forwarded message ----- -- GPG Fingerprint: 4821 CFDA 06E7 49F3 BF05 3F02 11E3 390F 8338 5B04 https://pgp.mit.edu/pks/lookup?op=get&search=0x11E3390F83385B04 https://keys.openpgp.org/search?q=pozar%40lns.com

3 3

Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
by Mark Tinka 20 Jun '20

20 Jun '20

On 20/Jun/20 19:58, Gert Doering wrote: > The 6880/6840 products were promising at that time, but the pricing made > it uninteresting. So we kept our 6506Es for a time... We haven't done anything with them since we bought and deployed them in 2014. They are serving their purpose quite well, and when it's time for them to go, the Arista kicks. > ... and then went to Arista 7050SX2/SX3 for the "edge things" (small > routing table, lots of 10G/25G ports, small power draw, EVPN/VXLAN). > > Nice stuff like the JSON RPC API, which is nice to work with and > amazingly *fast* (compared to JunOS commit times...). And, most important, > a good TAC and a company interested in listening to their customers. We run the 7508E for core switching in large PoP's, and the 7280R for data centre access aggregation in all PoP's (this replaced our Juniper EX4550 and EX4600 platforms). We are very happy - but these are pure Layer 2 switching use-cases. > I'm a bit annoyed that the 7050SX* do not have MPLS-P support (because > we have MPLS PEs that basically "live behind" the 7050SX, and now need > to have vlans *through* them, to reach a MPLS P router). > > I do understand that the BRCM Trident is fairly limited wrt MPLS handling, > so Arista decided "better no MPLS than something which is not enough > for people" - unfortunately for us, because we only want "LDP and > single-label swap/pop", but I can accept the technical arguments to > some extent. You know how I feel about Broadcom chips :-). If Arista aren't that comfortable about them, you'd do well to take them at their word, hehe. > (As a side note, changing our network from EIGRP to OSPF for IPv4 did > not come for free, so I would have much preferred to stay in my self- > chosen vendor lock-in with Cisco. But Cisco has gone insane these days, > and new boxes like the NCS5500 come *without* EIGRP support. So they > really do not want us customers locked in...) Looking at things, it's probably cheaper for you to spend money on getting an open IGP than spending money dealing with the indecision Cisco sometimes goes through. Mark.

1 0

Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
by Mark Tinka 20 Jun '20

20 Jun '20

On 19/Jun/20 20:19, ljwobker(a)gmail.com wrote: > >From the vendor standpoint, the market has never been able to agree on what makes a "core" application. If I have five "big" customers, I guarantee you that: > - one of them will need really big ACLs, even though it's a "core" box to them. > - one of them will want to terminate high speed L2VPN circuits, even though it's a "core" box. > - one of them will need to do hierarchical shaping and granular QoS, even though it's a "core" box. > - one of them will want to have lots of headroom in the FIB (2-3x today's global tables) ... even though it's a "core" box. > - one of them will want to buy something that they can "migrate out to the edge" one day... > > Say it with me: "even though it's a "core" box" > > This puts me (as the vendor) in a super weird spot... I can try to create a card/PID that addresses *some subset* of this, charge a lot less for it, and hopefully sell a bunch. Or I'm left creating something that I can sell into that broader market, but then that thing has to "do all the stuff" and I'm going to charge for it appropriately. > > The physics dictate that "Really High Speed Silicon" does not exist which can solve all of those things. I can solve SOME with a given chip design, but not all. Well, if I'm honest, it's the vendors who created "tiers" back in the day, so they can sell boxes in the way they did, and still do. Ever since Ethernet became the gold standard, what a core, edge, peering, branch, e.t.c., box is has been meaningless. It was meaningless before Ethernet (I mean, to some, the Cisco 3640 was a core router, while to others it was a peering router), but it's more meaningless in the days of Ethernet. The reason the ASR9000 sells better than the CRS or NCS 6000, is the same reason the MX sells better than the PTX or T-series. It's all about Ethernet. So now, vendors who are able to build boxes that can license Ethernet ports will be the winners, because I don't have to pay the upfront capex for the entire card, and can just grow as I need. The Transport boys have been doing it for so long, why can't the IP boys do the same? The good news is, they have started. Secondly, and perhaps more importantly, if vendors can build around a single ASIC across a multitude of platforms, then there is hope. If you have to build a different ASIC for every tier of a network, you end up with the issues you raise, above. The reason the MX does so well is because in addition to being an Ethernet platform, it uses the same ASIC (since Trio, to be clear), which gives Juniper and its customers plenty of flexibility across a variety of applications. There is a lesson, here, to be learned. Mark.

1 0