- NANOG - lists.nanog.org

HULU
by Shon Elliott 10 Feb '22

10 Feb '22

Anyone from HULU on the list that can contact me regarding a network issue? Kind Regards, Shon Elliott Level 3 IP/Routing/Security Network Engineer unWired Broadband, LLC. selliott(a)getunwired.com<mailto:selliott@getunwired.com> [uw-logo] www.getunwired.com<http://www.getunwired.com/> The Valleys #1 Rural High-Speed Fixed Wireless Internet Service Provider

1 0

NANOG 84 Networking Events - N84 Kicks-Off Monday!
by Nanog News 09 Feb '22

09 Feb '22

*NANOG 84 Networking Opportunities * Networking is essential to the health of your career! Take advantage of the opportunity to meet + greet with industry leaders + professionals at next week's networking events at NANOG 84. *Day 1: Newcomers Breakfast Orientation* Monday, Feb. 14 | 9:00am - 9:45am CST Location: Waterloo Ballroom 5-6, Level 5 New to NANOG? Don’t miss our Newcomers Breakfast Orientation happening Monday, Feb 14 at 9:00am at our upcoming meeting, NANOG 84. Have an opportunity to network with fellow newcomers! *REGISTER NOW <https://nanog.org/events/nanog-84/>* *Day 1: NANOG Networking Luncheon * Monday, Feb. 14 | 12:00pm - 1:30pm CST Location: MoonTower Hall, Level 2 Some of the tables at lunch will have "Table Topics" for you to use to chat with others & network around the same topic. - Network Management - Automation - BGP Security - Routing - Traffic Management and Policy - Job Hunting - Peering - Newcomers Networking Follow-up - War Stories - The Time I Thought I'd Get Fired Sponsors: Kentik <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> , Sparkle <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> ,Telescent <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> *SEE AGENDA * <https://www.nanog.org/events/nanog-84/nanog-84-agenda/> *Day 2: Women in Tech * Tuesday, Feb. 15 | 12:00pm - 1:15pm CST Location: Waterloo Ballroom 5-6, Level 5 "What makes NANOG an incredible community, also makes it intimidating - 'courageous women' helping you not feel small" - Jezzibell Gilmore Co-founder of Packetfabric This is a no-pressure space to empower your fellow (wo)man! Join us for an opportunity to meet, network + potentially find your next mentee or mentor in the Women in Tech community. *Sponsor:* AWS <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> *SEE AGENDA <https://www.nanog.org/events/nanog-84/nanog-84-agenda/>* *Peering Forum Applications Still Available * NANOG 84 Peering Coordination Forum tables are still available. The forum provides time for attendees to meet + network with others in the peering community present at NANOG. Sign up for your table today! *SIGN UP * <https://www.nanog.org/events/nanog-84/peering-forum/>

1 0

PeeringDB Hackathon - looking for feature requests
by Steve McManus 09 Feb '22

09 Feb '22

PeeringDB is looking at participating at an upcoming NANOG Hackathon. One of the ideas for a theme is to improve the API. Specifically by adding API calls for common use cases that people need to handle outside of the API. Typically, by dumping the entire database to SQL For example - given two IXes, which networks are present at both? We'd like to make a list of such useful queries such that people don't have to dump the database just to run them. A stretch goal would be to expose into the website instead of requiring API calls. This issue has some more detail, including a few existing ideas: https://github.com/peeringdb/peeringdb/issues/1020 Comments there or in email to me would be super helpful. As always, if there are other feature requests for PeeringDB, feel free to create an issue in github ( https://github.com/peeringdb/peeringdb/issues/new/choose ) or in email, even if they're not strictly Hackathon ideas. They are always appreciated! Thanks! -Steve PeeringDB Product Committee chair

4 4

Re: Authoritative Resources for Public DNS Pinging
by J. Hellenthal 09 Feb '22

09 Feb '22

Not to mention. It is viable traffic to monitor, if I know that I get X number of icmp traffic through a point in tranfer consistently and that starts to drop off considerably that it may be a failing connection due to some circumstance I should start checking that equipment. And if im that connection in the middle... that is money ! On Wed, Feb 09, 2022 at 03:02:19PM +0000, J. Hellenthal wrote: > > Just think of all the smokeping probes that are out there plus services > like UptimeRobot and similiar. > > you can't just put something up as a provider of a service and say ... > ya know im not going to plan for this... traffic for them of any kind is > money... not only to them but to their IX's as well. > > ya just don't willy nilly cut that shit down and not expect a huge > blowup to happen. > > On Wed, Feb 09, 2022 at 03:53:15PM +0100, Łukasz Bromirski wrote: > > > > Yup. And Google folks accounted for the world pinging them all day long. > > > > I wouldn't call using DNS resolvers as best "am I connected to internet over this interface" tool though. A day, year or 5 years from now the same team may decide to drop/filter and then thousands of hardcoded "handmade automation solutions" will break. And I believe that's closer to what Masataka was trying to convey. > > > > — > > Łukasz Bromirski > > > > > On 9 Feb 2022, at 14:23, Mark Tinka <mark(a)tinka.africa> wrote: > > > > > >> On 2/9/22 15:00, Masataka Ohta wrote: > > >> > > >> > > >> Wrong. It is not bad, at least not so bad, pinging properly > > >> anycast DNS servers. > > >> > > >> The point of anycast is resistance to DDoS. > > >> > > >> But, relying on hard coded 8.8.8.8 is not a good idea because > > >> DNS service of the address may be terminated. > > >> > > >> Instead, properly anycast root name servers are authoritative > > >> resources provided for public DNS queries which can be used for > > >> pinging, though pinging so with ICMP should be less painful > > >> for the servers. > > > > > > That's like saying you won't have an egg for dinner because it's typically had for breakfast. > > > > > > Users don't care what infrastructure has been designated for. If they can find another use for it other than designed, which serves their interests, they will use it. > > > > > > We need to allow, and account, for that. > > > > > > Mark. > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

1 0

LLDP Source MAC
by Crist Clark 08 Feb '22

08 Feb '22

Came across some endpoint behavior that caused some confusion with a MAC authentication bypass (MAB) setup, and I was wondering if this is some kind of well known behavior. The endpoints (Pure storage arrays) are using the expected MAC addresses, both fixed and a “virtual” shared MAC for 99.9% of the traffic. The one exception is that the LLDP multicasts have a random-looking source MAC. The source MAC has the non-unique bit flipped on. Is this a well known type of behavior? Quick Google turned up some others noticing this in very different devices. May be more wide spread, but how often would people notice?

1 0

Spoofer Report for NANOG for Jan 2022
by CAIDA Spoofer Project 08 Feb '22

08 Feb '22

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Jan 2022: ASN Name Fixed-By 21976 NJEDGE-NET 2022-01-03 62904 EONIX-COMMUNICATIONS-ASBLOCK-6 2022-01-18 32489 AMANAHA-NEW 2022-01-28 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jan 2022: ASN Name First-Spoofed Last-Spoofed 577 BACOM 2016-03-09 2022-01-29 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2022-01-27 20412 CLARITY-TELECOM 2016-09-30 2022-01-31 6181 FUSE-NET 2016-10-10 2022-01-29 32440 LONI 2016-11-03 2022-01-31 22898 ATLINK 2016-12-16 2022-01-30 54119 BOINGO-MDU 2017-04-14 2022-01-17 63296 AWBROADBAND 2017-09-01 2022-01-25 33452 RW 2018-09-19 2022-01-27 8047 GCI 2019-04-11 2022-01-15 398836 NP-NETWORKS 2021-03-12 2022-01-28 56207 Converge 2021-03-26 2022-01-20 399318 2021-08-29 2022-01-28 62904 EONIX-COMMUNICATIONS-ASBLOCK-6 2021-09-07 2022-01-12 63457 EMPIRE-CONNECT 2021-09-08 2022-01-27 212934 AS_POTVIN 2021-10-03 2022-01-31 22773 ASN-CXA-ALL-CCI-22773-RDC 2021-10-24 2022-01-29 46449 ASTREA-NORTHWI-WESTUPMI 2021-11-07 2022-01-20 394437 PSLIGHTWAVE 2021-12-02 2022-01-29 62887 WHITESKY-COMMUNICATIONS 2021-12-03 2022-01-24 54201 WEWORK-MANAGEMENT-LLC 2021-12-16 2022-01-31 46997 NATOLAB 2021-12-22 2022-01-02 7896 NU 2022-01-12 2022-01-18 396919 BLADE-GLOBAL 2022-01-16 2022-01-30 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

GTT contact
by Brian Turnbow 08 Feb '22

08 Feb '22

Hello everyone, Is there someone from GTT on list that can contact me in pvt? For over a week we have been seeing loss and latency between Frankfurt and Milan as reported in outages by Lukas https://puck.nether.net/pipermail/outages/2022-February/014230.html After a week of TT updates and escalation reporting over and over that we see loss and latency between Frankfurt and Milan every afternoon/evening Sending mtrs, traces, showing them graphs that show the issue twords us as well as other Italians ISPs.... Today their noc sends me pings done this morning saying all is ok and is asking me for the duplex and mtu setting on our transit port. Terribly frustrating. Thanks Brian

1 0

Cloudflare human?
by Adam Thompson 07 Feb '22

07 Feb '22

If anyone from Cloudflare lurks here, could you please reach out to me directly? My messages to peering@ about one specific long-standing issue (and only this issue) are going unanswered with no explanation why. Thanks, -Adam Adam Thompson Consultant, Infrastructure Services [MERLIN] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson(a)merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/>

1 0

Slack.com DNSSEC on Feb 12th 15:00 UTC
by Rafael Elvira 07 Feb '22

07 Feb '22

Hello everyone, I'm reaching out from the traffic team over at Slack <https://slack.com/>. As many of you might be aware, we had a series of unfortunate attempts to enable DNSSEC on slack.com <https://slack.engineering/what-happened-during-slacks-dnssec-rollout/> last year. We are planning to publish the slack.com DS record at the '.com' zone on Feb 12th at 7AM PST (15:00 UTC). Our authoritative zone and delegated zones are already signed and have their link of the chain of trust all set. If you see any issues with slack.com in your networks after or on Feb 12th we'd be very grateful if you can contact us. Thank you! Rafael Elvira, Slack.

12 11

Amazon peering revisited
by Kelly Littlepage 05 Feb '22

05 Feb '22

Hi all, a nanog thread started on November 23, 2018 discussed the challenges of getting Amazon peering sessions turned up. Has anyone had luck since/does anyone have a contact they could refer me to — off-list or otherwise? The process of getting PNI in place with other CSPs was straightforward, but I haven't heard back from AWS after a month and several follow-ups. Our customers would really benefit from us getting this sorted. Thanks, Kelly -- Kelly Littlepage OneChronos Global kelly(a)onechronos.com https://www.onechronos.com -- This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. If you are not the intended recipient or otherwise believe that you have received this message in error, please notify the sender immediately and delete the original. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If this message was misdirected, OCX Group Inc. does not waive any confidentiality or privilege.

8 8