June 2020 - Test - lists.nanog.org

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

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

20 Jun '20

On 19/Jun/20 17:26, Gert Doering wrote: > There's a special place in hell for people re-using the "Catalyst" brand > name and then putting yearly renewable licenses on it. Or IOS XE. > > I'm not actually sure *which* BU is doing "Catalyst" these days, but > we're so annoyed about Cisco these days that I haven't really looked at > all these new and shiny products from all these new and shiny BUs with > all these new and shiny operating systems in quite a while. We bought the C6880-X for our core switch back in 2014. It's still humming, running plain old IOS. The upgrade path is Arista for this. I'm not sure what switching is doing over at Cisco, these days. Mark.

1 0

NANOG List Maintenance Complete
by geeks＠nanog.org 20 Jun '20

20 Jun '20

The maintenance was successful, and all mailing lists have been updated to use VERP. The archives for each list have been extended with all prior posts. Please see: https://mailman.nanog.org/pipermail/nanog/ The list is back in operation and all queued messages will be processing over the next few minutes. Please contact tech(a)nanog.org if you experience any delivery problems or have issues. Thank you, NANOG Tech Committee

2 1

NANOG List Maintenance Start
by geeks＠nanog.org 20 Jun '20

20 Jun '20

Maintenance is starting in accordance with the prior maintenance notice. The lists will be unavailable until the maintenance is concluded before or about 0600 UTC. Thank you, NANOG Tech Committee

1 0

RE: [EXT] Xfinity (both ends) - can't ping from users home to office
by Spencer Coplin 20 Jun '20

20 Jun '20

Kevin, you are amazing! This absolutely fixed our issue. Thank you so much! Thank you, Spencer From: Kevin Kurpiel <kevin(a)kurpiel.org> Sent: Friday, June 19, 2020 5:04 PM To: Spencer Coplin <scoplin(a)f1techgroup.com> Cc: North American Network Operators' Group <nanog(a)nanog.org> Subject: Re: [EXT] Xfinity (both ends) - can't ping from users home to office CAUTION: This email originated from an external source. Verify the sender before taking any actions. On Jun 19, 2020, at 10:18 AM, Spencer Coplin <scoplin(a)f1techgroup.com<mailto:scoplin@f1techgroup.com>> wrote: Thank you, he has the xfinity provided router/modem, so no cpe router to make a change on. I don't think we can change it's mac address. Good thought on pursuing it through the business side and I'll proceed with that. Thank you, Spencer Spencer Coplin We’re facing the same issue at my current job. We have many users at home who are unable to access sites in our datacenter. We found that if the user disables the "XFi Advanced Security feature" on their Comcast provided router, they can reach our sites again. We’ve been trying to work with Comcast to see if there is any way to work around this and find out why it suddenly decided to block our content, but don’t have a good solution yet. Might be worth having your user try to disable that feature to see if it helps. Kevin

1 0

Microsoft AS8075 contact?
by Bryan Holloway 19 Jun '20

19 Jun '20

Hello ... If anyone from Microsoft peering is lurking, I could use an assist. We have a reachability issue in Chicago. E-mail to their PeeringDB NOC contact have gone unanswered. Thank you!

1 1

Google captcha issue
by Christopher Tyler 19 Jun '20

19 Jun '20

We run a smaller ISP of about 7.5k customers and the other day we got an email (excerpt below) from one of Google's automated tools. We are seeing automated scraping of Google Web Search from a large number of your IPs. Automated scraping violates our /robots.txt file and also our Terms of Service. We request that you terminate this traffic immediately. Failure to do so may cause your network to be blocked by our abuse systems. To allow you to identify the traffic, we are providing a list of your IPs they used today (Source field), as well as the most common destination (Google) IP and port and a timestamp of a recent request (in UTC) to aid in your identification. Note that this list may not be exhaustive, and we request that you terminate all such traffic, not just traffic from IPs in this list. All of the destination ports are either 80 or 443, so they at least appear to be legit web traffic on the surface. They are obviously spoofed IP address as there are network addresses in the list and the IP belongs to a router that doesn't appear to be compromised in any way. The initial letter included 700+ IP addresses from our network. It's now affecting our customers as they are now getting Captcha's for every couple of Google searches that they perform. Does anyone know of a good way to track the perpetrator(s) down and/or know of a way to mitigate this? -- Christopher Tyler Senior Network Engineer MTCRE/MTCNA/MTCTCE/MTCWE Total Highspeed Internet Solutions 1091 W. Kathryn Street Nixa, MO 65714 (417) 851-1107 x. 9002 www.totalhighspeed.com

4 4