- NANOG - lists.nanog.org

Comcast routing contact
by Tim Burke 15 Jun '21

15 Jun '21

Can someone at AS7922 that handles routing please contact me off list? Seeing bizarre/asymmetric routing in Houston via Cogent, outbound path goes up to Dallas to reach Cogent transit, then back down to Houston, while (proper) inbound path departs Cogent transit in Houston to hit Comcast. Can’t seem to get someone clueful to investigate through normal support channels. traceroute to 165.254.62.196 (165.254.62.196), 64 hops max, 52 byte packets 3 50-225-135-89-static.hfc.comcastbusiness.net (50.225.135.89) 1.038 ms 0.787 ms 0.816 ms 4 162.151.134.13 (162.151.134.13) 5.531 ms 1.862 ms 1.820 ms 5 be-33662-cr02.dallas.tx.ibone.comcast.net (68.86.92.61) 9.498 ms 8.177 ms 8.632 ms 6 be-3312-pe12.1950stemmons.tx.ibone.comcast.net (96.110.34.106) 8.966 ms 8.618 ms 8.671 ms 7 * * * 8 be2763.ccr31.dfw01.atlas.cogentco.com (154.54.28.73) 8.934 ms be2764.ccr32.dfw01.atlas.cogentco.com (154.54.47.213) 9.816 ms 7.806 ms 9 be2443.ccr42.iah01.atlas.cogentco.com (154.54.44.229) 11.962 ms 29.051 ms 10.605 ms 10 be2991.rcr51.iah04.atlas.cogentco.com (154.54.7.86) 12.173 ms be3777.rcr52.iah04.atlas.cogentco.com (154.54.7.78) 11.716 ms 11.069 ms 11 te0-0-1-3.nr11.b069355-0.iah04.atlas.cogentco.com (154.24.14.186) 12.402 ms 11.591 ms te0-0-1-0.nr11.b069355-0.iah04.atlas.cogentco.com (154.24.14.190) 12.384 ms 12 38.122.156.130 (38.122.156.130) 11.028 ms 10.711 ms 10.744 ms 13 * * * 14 165.254.62.196 (165.254.62.196) 13.146 ms 11.642 ms 11.616 ms traceroute to 50.225.135.90 (50.225.135.90), 30 hops max, 60 byte packets 1 165.254.62.194 (165.254.62.194) 0.236 ms 0.185 ms 0.153 ms 2 ve3.r20.sprntx01.mid.net (64.40.23.64) 0.357 ms 0.362 ms 0.406 ms 3 te0-0-2-1.nr11.b069355-0.iah04.atlas.cogentco.com (38.122.156.129) 1.164 ms 1.277 ms 1.394 ms 4 te0-2-1-12.rcr51.iah04.atlas.cogentco.com (154.24.14.185) 1.271 ms 1.321 ms 1.290 ms 5 be3778.ccr42.iah01.atlas.cogentco.com (154.54.85.65) 7.351 ms be2992.ccr42.iah01.atlas.cogentco.com (154.54.27.109) 2.160 ms 7.310 ms 6 be3494.rcr22.iah02.atlas.cogentco.com (154.54.40.54) 2.261 ms 2.382 ms be3485.rcr21.iah02.atlas.cogentco.com (154.54.28.86) 2.656 ms 7 be3632.rcr51.b023723-0.iah02.atlas.cogentco.com (154.24.45.58) 3.331 ms be3631.rcr51.b023723-0.iah02.atlas.cogentco.com (154.24.30.38) 3.233 ms be3632.rcr51.b023723-0.iah02.atlas.cogentco.com (154.24.45.58) 3.051 ms 8 be-200-pe01.westwaypark.tx.ibone.comcast.net (173.167.59.41) 3.003 ms 3.353 ms 3.294 ms 9 be-3201-cs02.houston.tx.ibone.comcast.net (96.110.39.37) 5.128 ms be-3401-cs04.houston.tx.ibone.comcast.net (96.110.39.61) 5.453 ms 5.392 ms 10 96.110.40.118 (96.110.40.118) 7.344 ms 96.110.40.122 (96.110.40.122) 5.598 ms 96.110.40.118 (96.110.40.118) 7.289 ms 11 96.108.82.66 (96.108.82.66) 10.383 ms 10.696 ms 13.230 ms 12 ae-0-sur03.luthe.tx.houston.comcast.net (68.85.245.117) 10.509 ms 10.590 ms 10.466 ms 13 50-225-135-90-static.hfc.comcastbusiness.net (50.225.135.90) 11.010 ms 10.885 ms 11.004 ms V/r Tim

1 0

aggregation tool that allows a bit of fuzz to aggregating ?
by babydr DBA James W. Laferriere 15 Jun '21

15 Jun '21

Hello All , google foo isn't pulling up anything but drivel about ip aggregation in cisco and describing the word 'fuzz' . I am looking for a tool such as 'aggregate' , this one is written in c . Which has been a very good tool to me . I use this tool to aggregate ip addresses snagged out of various logs to insert into iptables filtering . Again the afore mentioned tool has work well . But now I am seeing a new trick fro some entities that are transmitting from every other ipv4 address such as (*) below . And the trust (& crusty) ol'tool just doesn't allow for a bitt of fuzz in its aggregation filter . Hoping someone knows of such a tool and or may have patched the aggregate tool to accopmlish such a task . (*) ... 63.81.88.116/32 63.81.88.118/32 63.81.88.120/32 63.81.88.122/32 63.81.88.124/32 63.81.88.126/32 ... Tia , JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml(a)system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+

4 3

NANOG 82 Day 1 - Don't forget to Register in advance
by Nanog News 14 Jun '21

14 Jun '21

<https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> NANOG 82 Virtual Expo Doors are Open! *Explore the latest technology from your living room*Network and interact with reps from top tech companies from your living room, learn about the latest technologies, have fun at the scavenger hunt + win raffle prizes. *Digital doors will remain open until June 25.* Engage in this one-of-a-kind experience by visiting booths virtually, have the opportunity to connect with incredible professionals and of course, get your swag on! Visit Expo Booths <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> Day 1 of NANOG 82 has Officially Begun!Don't forget to register in advance + set up your NANOG account. Complementary Conference Registration <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> is available to anyone who needs it! View Today's Agenda <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> Prizes + Fun = Expo Scavenger Hunt *Have fun at the Expo Scavenger Hunt + WIN $$* *Sponsored by Opengear * *Scavenger Hunt rules:* Please visit each Nanog 82 Virtual Expo booth to search for answers to our daily Scavenger Hunt, TODAY (June 14) through Wednesday, June 16. Submit your answers by 11pm EST/8pm PST for a chance to win a $100 VISA gift card. 1 winner per day. Winners will be notified by email. Register for NANOG 82 <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…>

1 0

Re: Google uploading your plain text passwords
by Jason Pope 14 Jun '21

14 Jun '21

I am not the brightest bulb in the house, but when I try to go to passwords.google.com, I get the following response: Google can't check your passwords for security issues because you set up a > passphrase to encrypt your passwords in your Google Account. This keeps the > data private to you. Learn more. > <https://support.google.com/chrome/bin/answer/165139?hl=en> This occurs on my Google Chrome browser, which does sync my passwords between devices because I have the browser signed into my personal account, and my Brave browser, which is never signed in with any Google accounts. I don't remember setting a passphrase, but apparently I did. I can't remember if I did that because I did see a behaviour, such as showing me all my passwords with little to no effort, or it was offered as a security feature and I said, "Yes, please." Jason K Pope 214.566.8527 boards188(a)gmail.com Greater love has no one than this, that one lay down his life for his friends. John 15:13

1 0

ROA coverage info
by Fabiano D'Agostino 14 Jun '21

14 Jun '21

Hi all, I would like to ask you if there is some information about ROA coverage of IPv4/v6 address space in the different RIRs. Thanks in advance. Regards, Fabiano

7 8

Google uploading your plain text passwords
by William Herrin 13 Jun '21

13 Jun '21

Howdy, My gmail account prompted me today to change a compromised password. It wasn't compromised; it was an offline system where I intentionally used a generic password. But in the process... It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!! And it could prove it by displaying the plain text passwords for me on my laptop. And I can't turn the upload off! To the google folks on here: Are you INSANE!? Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/

20 38

Operational Implications of IPv6 Extension Headers (Fwd: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt)
by Fernando Gont 11 Jun '21

11 Jun '21

Hi, folks, After almost 7+ years of working on this topic, our internet-draft entitled Operational Implications of IPv6 Packets with Extension Headers¨ ( https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drop… ), has been approved for publication as an IETF RFC. I believe it iś of value for folks working in security and/or network operations. Kudos to my co-authors for enduring the process, and to Nick Hilliard who did the last push to get this one approved. :-) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops- 08.txt Date: Fri, 11 Jun 2021 09:28:16 -0700 From: internet-drafts at ietf.org Reply-To: v6ops at ietf.org To: i-d-announce at ietf.org CC: v6ops at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Operational Implications of IPv6 Packets with Extension Headers Authors : Fernando Gont Nick Hilliard Gert Doering Warren Kumari Geoff Huston Will (Shucheng) Liu Filename : draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt Pages : 20 Date : 2021-06-11 Abstract: This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drop… A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ v6ops mailing list v6ops at ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

1 0

irrd 4.1.2 deployed at NTT
by Troy Boudreau 11 Jun '21

11 Jun '21

Dear all, I am Troy from NTT's Global IP Network IRR team. Today we upgraded rr.ntt.net to IRRd 4.1.2! This marks the completion of a multi-year initiative to seamlessly integrate IRR and RPKI. While this version might not seem remarkable, this change means that NTT's IRR mirror service will now use RPKI Validated ROAs to filter out invalid IRR objects! This filtering strategy is similar to RIPE-731. Creation of RPKI ROAs will trigger deletion of conflicting IRR objects, this helps clean up stale objects. Existing RPKI ROAs help prevent future creation of unauthorized IRR objects. Anyone using the rr.ntt.net service to build their filters will benefit from this change! See https://irrd.readthedocs.io/en/stable/admins/rpki/ for more information. If you require any assistance, please send a message to the team at db-admin(a)rr.ntt.net. Kind regards, Troy

3 3

Any2 LAX
by Seth Mattinen 11 Jun '21

11 Jun '21

Did Any2 LAX barf last night between about 1am and 8am Pacific time?

6 9

Cogent and Altice Contacts for Routing Issue
by Vinny Abello 11 Jun '21

11 Jun '21

Hello, Please excuse the noise. If there are any network engineers from Cogent and Altice on the list, could you please email me directly. This is regarding a specific Altice IPv4 aggregate in the NYC area that Cogent in the NYC area is handing off to Zayo in San Jose for some reason. It subsequently seemingly has a lot of packet loss coming back to the NYC area through Zayo's network. It's affecting my remote employees. I can provide traceroutes privately as not to clutter up the list. Bad Altice Aggregate in question: 67.84.0.0/14 Good Altice aggregate routing properly: 68.196.0.0/14 Thanks in advance. -Vinny

1 1