From mark at tinka.africa  Sat Apr  1 09:14:24 2023
From: mark at tinka.africa (Mark Tinka)
Date: Sat, 1 Apr 2023 11:14:24 +0200
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <CAD6AjGSzrSkfqgYSoBCAQSH75W-9WrBDhLQnnc+4ALJ20-cFfA@mail.gmail.com>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAD6AjGSzrSkfqgYSoBCAQSH75W-9WrBDhLQnnc+4ALJ20-cFfA@mail.gmail.com>
Message-ID: <e118ce46-cf43-a5cb-6a85-7eabae1950c3@tinka.africa>



On 3/31/23 15:51, Ca By wrote:

> We use a lot of 100g-FR
>
> For dense deployment and limited faceplate space, 100g-fr / dr are the 
> only way.
>
> LR4 is dead to me.

We run the SR4 optics for in-rack cabling, because they are about 4X 
cheaper than all the single-mode options.

We have been heavy on the LR4 optics, but are now starting to test (and 
if happy, switch to) the FR units, as they are even cheaper than the LR4 
option.

The DR options don't make much sense for us, because we prefer the SR4 
for in-rack cabling, and given how large data centres are nowadays, 500m 
might not enough to interconnect with customers.

But for un-amplified Metro-E deployments, we are looking forward to 
testing Adva's 100G-ZR, which is also a single lane optic.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230401/b5fec7b2/attachment.html>

From arizonagull at gmail.com  Mon Apr  3 00:14:05 2023
From: arizonagull at gmail.com (David Siegel)
Date: Sun, 2 Apr 2023 18:14:05 -0600
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
Message-ID: <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>

At this point, I'd be happy to see others happily deploy a single-lambda
optic of almost any variety!  Since deploying 400G in a clients network
(but 100G still being the preferred connection choice), any inquiry with
respect to LR1, FR1 or DR+ is met with "no thanks, LR4 please."

If asked, I'd recommend FR1.  They're available at a great price-point, and
2km reach is adequate for most applications.

On Fri, Mar 31, 2023 at 7:25?AM Jared Mauch <jared at puck.nether.net> wrote:

> The common tech is 100G-LR4 these days - I'm wondering how many operators
> are supporting the LR1 to allow its use on 400G and future 800G optics as
> those use breakout to support 100G ports.
>
> Would you rather do a 400G port on a router vs 100LR1?
>
> Curious what others think.
>
> Sent via RFC1925 compliant device
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230402/d908513f/attachment.html>

From nanog at ics-il.net  Mon Apr  3 05:21:29 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Apr 2023 00:21:29 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
Message-ID: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/75d67c6f/attachment.html>

From contemno at gmail.com  Mon Apr  3 05:35:43 2023
From: contemno at gmail.com (Joshua Miller)
Date: Mon, 3 Apr 2023 01:35:43 -0400
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
Message-ID: <CAE2VCt2DZFrER4VUbms+4kmFF+mNriiTBoK0PH3qLz8zWhfw+w@mail.gmail.com>

Is the BGP route getting installed into the rib?




On Mon, Apr 3, 2023, 01:24 Mike Hammett <nanog at ics-il.net> wrote:

> We have a Nexus 3064 that is setup with partial BGP tables and is routing
> based on that.
>
>
> I've done a show ip bgp for an IP of interest and it has an expected next
> hop IP. I show ip arp on that next hop IP and it has the expected interface.
>
>
>
> However, sFlows show the packets leaving on a different interface, the one
> that would carry the default route for routes not otherwise known.
>
>
> If the next hop IP is expected and the ARP of that next hop IP is
> expected, why are packets leaving out an unexpected interface?
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/7354eebd/attachment.html>

From jay at west.net  Mon Apr  3 05:44:54 2023
From: jay at west.net (Jay Hennigan)
Date: Sun, 2 Apr 2023 22:44:54 -0700
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
Message-ID: <7c3e93b2-748a-a9a3-66a5-1a3adcee1ee5@west.net>

On 4/2/23 22:21, Mike Hammett wrote:
> We have a Nexus 3064 that is setup with partial BGP tables and is 
> routing based on that.
> 
> 
> I've done a show ip bgp for an IP of interest and it has an expected 
> next hop IP. I show ip arp on that next hop IP and it has the expected 
> interface.
> 
> 
> However, sFlows show the packets leaving on a different interface, the 
> one that would carry the default route for routes not otherwise known.

What does traceroute to that IP show?


-- 
Jay Hennigan - jay at west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV


From jay at west.net  Mon Apr  3 06:02:42 2023
From: jay at west.net (Jay Hennigan)
Date: Sun, 2 Apr 2023 23:02:42 -0700
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
Message-ID: <a975f46f-3345-7dde-94cd-6f2b10fb8e28@west.net>

On 4/2/23 22:21, Mike Hammett wrote:
> We have a Nexus 3064 that is setup with partial BGP tables and is 
> routing based on that.
> 
> 
> I've done a show ip bgp for an IP of interest and it has an expected 
> next hop IP. I show ip arp on that next hop IP and it has the expected 
> interface.
> 
> 
> However, sFlows show the packets leaving on a different interface, the 
> one that would carry the default route for routes not otherwise known.
> 
> 
> If the next hop IP is expected and the ARP of that next hop IP is 
> expected, why are packets leaving out an unexpected interface?

Another route to the destination from a routing protocol with a lower 
distance?

What does "show ip route [destination]" look like?

-- 
Jay Hennigan - jay at west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV


From mhuff at ox.com  Mon Apr  3 10:38:23 2023
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 3 Apr 2023 10:38:23 +0000
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
Message-ID: <9fe9fab599304900b93393540cba97c4@ox.com>

switch-core1# sh forwarding route x.x.x.x

slot  1
=======


IPv4 routes for table default/base

------------------+-----------------------------------------+----------------------+-----------------+-----------------
Prefix            | Next-hop                                | Interface            | Labels          | Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+-----------------
x.x.x.x/24      x.x.x.250                            Ethernet1/29        


switch-core1# show routing hash x.x.x.x y.y.y.y
Load-share parameters used for software forwarding:
load-share mode: address source-destination port source-destination
Hash for VRF "default"
Hashing to path *y.y.y.y Eth1/29
For route:
y.y.y.0/24, ubest/mbest: 1/0
    *via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal




From: NANOG <nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of Mike Hammett
Sent: Monday, April 3, 2023 1:21 AM
To: NANOG <nanog at nanog.org>
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that.?


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface.?


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known.?


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface??


-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From mark at tinka.africa  Mon Apr  3 11:04:03 2023
From: mark at tinka.africa (Mark Tinka)
Date: Mon, 3 Apr 2023 13:04:03 +0200
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
Message-ID: <c3e5d888-d20d-c471-c59e-3452244a9f0d@tinka.africa>



On 4/3/23 02:14, David Siegel wrote:

> At this point, I'd be happy to see others happily deploy a 
> single-lambda optic of almost any variety!? Since deploying 400G in a 
> clients network (but 100G still being the preferred connection 
> choice), any inquiry?with respect to LR1, FR1 or DR+ is met with "no 
> thanks, LR4 please."
>
> If asked, I'd recommend FR1.? They're available at a great 
> price-point, and 2km reach is adequate for most applications.

Agreed.

Pricing between LR4, FR and DR is not too far apart.

The only optic that is substantially cheaper than all of them is the SR4.

So in my mind, FR is the most ideal, although I'd still use SR4 for 
in-rack, multi-mode cabling.

Mark.

From nanog at ve4.ca  Sun Apr  2 05:12:07 2023
From: nanog at ve4.ca (Glen A. Pearce)
Date: Sat, 1 Apr 2023 23:12:07 -0600
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a phishing
 E-mail or real...)
Message-ID: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>

Hi All:

I received an E-mail with an attachment claiming something
on my network is infected and that I should look at the
attachment to find out what.

Normally I think everything with an attachment is phishing
to get me to run malware but:

#1: The sites linked to in it seem to be legit German
 ??? government websites based on Wikipedia entries that
 ??? haven't changed in several years.
 ??? (Looked at archive.org)
#2: The attachment is a .txt file which I've normally
 ??? assumed to be safe.
#3: None of the usual dead giveaways that most phishing
 ??? E-mails have.

If it is a phishing E-mail it has got to be the cleverest
one I've ever seen, though someone would try to be cleaver
considering the target would be holders of IP blocks.

I right clicked and checked properties to make sure the
attached ip_addresses.txt file really is a text file and
not some fancy trickery with reverse direction characters
( As seen on https://www.youtube.com/watch?v=ieQUy8YTbFU )

I tried poking around to see if there was some vulnerability
in notepad (or some versions of it) that I didn't know about
and only found a vulnerability in the text editor on Macs
but nothing with Windows Notepad.

The other thing I felt was a bit off is that the originating
mail server is in Deutsche Telekom AG space and not IP Space
registered to the German government.? I'm thinking someone
could rent some IP space from Deutsche Telekom AG with a
connection to them in a data center and get the DNS delegated
to them so they could set the reverse DNS to whatever they want.
A lot of effort to try to look legit by coming out of Germany
and having a government domain in the reverse DNS to look like
a plausible legit outsourcing but again Network operators are
the target audience so the normal tricks that work on the
general public won't work with this group so I can see someone
going that far.

I'll attach the E-mail below with all headers.? Has anyone
else gotten these?? Is there some security risk opening it
in Windows Notepad that I don't know about or is it actually
safe to open this?


Return-Path: <abuse at cyber.bka.de>
Delivered-To: [REDACTED]
Received: from ezp08-pco.easydns.vpn ([10.5.10.148])
 ?? ?by ezb03-pco.easydns.vpn with LMTP
 ?? ?id oCfeBO/yEmTokhgAzaFxkQ
 ?? ?(envelope-from <abuse at cyber.bka.de>)
 ?? ?for <[REDACTED]>; Thu, 16 Mar 2023 10:43:59 +0000
Received: from smtp.easymail.ca ([127.0.0.1])
 ?? ?by ezp08-pco.easydns.vpn with LMTP
 ?? ?id WCB5BO/yEmSHdgEABcrfzg
 ?? ?(envelope-from <abuse at cyber.bka.de>); Thu, 16 Mar 2023 10:43:59 +0000
Received: from localhost (localhost [127.0.0.1])
 ?? ?by smtp.easymail.ca (Postfix) with ESMTP id 0DC85557DF
 ?? ?for <arin at ve4.ca>; Thu, 16 Mar 2023 10:43:59 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at ezp08-pco.easydns.vpn
X-Spam-Flag: NO
X-Spam-Score: 0.075
X-Spam-Level:
X-Spam-Status: No, score=0.075 required=4 tests=[BAYES_00=-1.9,
 ?? ?DEAR_SOMETHING=1.973, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
 ?? ?SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from smtp.easymail.ca ([127.0.0.1])
 ?? ?by localhost (ezp08-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 
10024)
 ?? ?with ESMTP id d0XbPteZN-Io for <arin at ve4.ca>;
 ?? ?Thu, 16 Mar 2023 10:43:55 +0000 (UTC)
Received: from mail.cyber.bka.de (mail.cyber.bka.de [80.146.190.22])
 ?? ?by smtp.easymail.ca (Postfix) with ESMTPS id 0BC0C557DC
 ?? ?for <arin at ve4.ca>; Thu, 16 Mar 2023 10:43:54 +0000 (UTC)
Date: Thu, 16 Mar 2023 10:43:53 +0000
To: arin at ve4.ca
From: BKA Wiesbaden - Abteilung Cybercrime <abuse at cyber.bka.de>
Reply-To: BKA Wiesbaden - Abteilung Cybercrime <abuse at cyber.bka.de>
Subject: Information regarding possible infection with malware
Message-ID: 
<M47LJRZpjy1zymUJDKsNtrYm3RimkafZfZTqeZpauZA at emailapi.apps.cc.bka>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 ?boundary="b1_M47LJRZpjy1zymUJDKsNtrYm3RimkafZfZTqeZpauZA"
Content-Transfer-Encoding: 8bit

Dear Sir or Madam,

As part of criminal proceedings, the German Federal Criminal Police 
Office (Bundeskriminalamt) has been
informed about public IP addresses and timestamps which indicate a 
potential infection by the malicious
software "Bumblebee" of one or more systems behind the respective public 
IP address.

Within this letter, the BKA is providing you with the data of the 
respective IP addresses which have been
assigned to you as the appropriate provider. You are asked to take 
appropriate measures to inform your
customers about the potential infection.

The following information will be provided:

1. Public IP address
2. Last known timestamp of contact by the public IP address
3. Possible system name or username on the potentially infected system

The following information may be sent to your customers in addition to 
the message of concern.

What should you do now?

1. Don???t panic!
2. Check your systems/networks for possible infections. If other 
institutions have already made you aware
of infected systems recently, follow the action guidelines which you may 
have received from them.
3. For further information on cleaning up infections, please visit the 
English website of the Federal Office
for Information Security (BSI):

https://www.bsi.bund.de/EN/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Infizierte-Systeme-bereinigen/infizierte-systeme-bereinigen_node.html

Yours sincerely,

Bundeskriminalamt Wiesbaden

-- 
Glen A. Pearce
gap at ve4.ca
Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk.
Very Eager 4 Tees
http://www.ve4.ca
ARIN Handle VET-17


From ops.lists at gmail.com  Mon Apr  3 11:35:25 2023
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Mon, 3 Apr 2023 11:35:25 +0000
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
Message-ID: <ME4P282MB0902FE8DC53614507851324FF5929@ME4P282MB0902.AUSP282.PROD.OUTLOOK.COM>

It appears legit.

BKA.DE is the German Bundeskriminalamt (Federal Police)

And the PTR records, SPF etc check out for the domain.

Might as well check the IP in question for malware if they?ve provided date / timestamps and such

--srs

From: NANOG <nanog-bounces+ops.lists=gmail.com at nanog.org> on behalf of Glen A. Pearce <nanog at ve4.ca>
Date: Monday, 3 April 2023 at 12:29 PM
To: nanog at nanog.org <nanog at nanog.org>
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a phishing E-mail or real...)
Hi All:

I received an E-mail with an attachment claiming something
on my network is infected and that I should look at the
attachment to find out what.

Normally I think everything with an attachment is phishing
to get me to run malware but:

#1: The sites linked to in it seem to be legit German
     government websites based on Wikipedia entries that
     haven't changed in several years.
     (Looked at archive.org)
#2: The attachment is a .txt file which I've normally
     assumed to be safe.
#3: None of the usual dead giveaways that most phishing
     E-mails have.

If it is a phishing E-mail it has got to be the cleverest
one I've ever seen, though someone would try to be cleaver
considering the target would be holders of IP blocks.

I right clicked and checked properties to make sure the
attached ip_addresses.txt file really is a text file and
not some fancy trickery with reverse direction characters
( As seen on https://www.youtube.com/watch?v=ieQUy8YTbFU )

I tried poking around to see if there was some vulnerability
in notepad (or some versions of it) that I didn't know about
and only found a vulnerability in the text editor on Macs
but nothing with Windows Notepad.

The other thing I felt was a bit off is that the originating
mail server is in Deutsche Telekom AG space and not IP Space
registered to the German government.  I'm thinking someone
could rent some IP space from Deutsche Telekom AG with a
connection to them in a data center and get the DNS delegated
to them so they could set the reverse DNS to whatever they want.
A lot of effort to try to look legit by coming out of Germany
and having a government domain in the reverse DNS to look like
a plausible legit outsourcing but again Network operators are
the target audience so the normal tricks that work on the
general public won't work with this group so I can see someone
going that far.

I'll attach the E-mail below with all headers.  Has anyone
else gotten these?  Is there some security risk opening it
in Windows Notepad that I don't know about or is it actually
safe to open this?


Return-Path: <abuse at cyber.bka.de>
Delivered-To: [REDACTED]
Received: from ezp08-pco.easydns.vpn ([10.5.10.148])
     by ezb03-pco.easydns.vpn with LMTP
     id oCfeBO/yEmTokhgAzaFxkQ
     (envelope-from <abuse at cyber.bka.de>)
     for <[REDACTED]>; Thu, 16 Mar 2023 10:43:59 +0000
Received: from smtp.easymail.ca ([127.0.0.1])
     by ezp08-pco.easydns.vpn with LMTP
     id WCB5BO/yEmSHdgEABcrfzg
     (envelope-from <abuse at cyber.bka.de>); Thu, 16 Mar 2023 10:43:59 +0000
Received: from localhost (localhost [127.0.0.1])
     by smtp.easymail.ca (Postfix) with ESMTP id 0DC85557DF
     for <arin at ve4.ca>; Thu, 16 Mar 2023 10:43:59 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at ezp08-pco.easydns.vpn
X-Spam-Flag: NO
X-Spam-Score: 0.075
X-Spam-Level:
X-Spam-Status: No, score=0.075 required=4 tests=[BAYES_00=-1.9,
     DEAR_SOMETHING=1.973, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
     SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from smtp.easymail.ca ([127.0.0.1])
     by localhost (ezp08-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port
10024)
     with ESMTP id d0XbPteZN-Io for <arin at ve4.ca>;
     Thu, 16 Mar 2023 10:43:55 +0000 (UTC)
Received: from mail.cyber.bka.de (mail.cyber.bka.de [80.146.190.22])
     by smtp.easymail.ca (Postfix) with ESMTPS id 0BC0C557DC
     for <arin at ve4.ca>; Thu, 16 Mar 2023 10:43:54 +0000 (UTC)
Date: Thu, 16 Mar 2023 10:43:53 +0000
To: arin at ve4.ca
From: BKA Wiesbaden - Abteilung Cybercrime <abuse at cyber.bka.de>
Reply-To: BKA Wiesbaden - Abteilung Cybercrime <abuse at cyber.bka.de>
Subject: Information regarding possible infection with malware
Message-ID:
<M47LJRZpjy1zymUJDKsNtrYm3RimkafZfZTqeZpauZA at emailapi.apps.cc.bka>
MIME-Version: 1.0
Content-Type: multipart/mixed;
  boundary="b1_M47LJRZpjy1zymUJDKsNtrYm3RimkafZfZTqeZpauZA"
Content-Transfer-Encoding: 8bit

Dear Sir or Madam,

As part of criminal proceedings, the German Federal Criminal Police
Office (Bundeskriminalamt) has been
informed about public IP addresses and timestamps which indicate a
potential infection by the malicious
software "Bumblebee" of one or more systems behind the respective public
IP address.

Within this letter, the BKA is providing you with the data of the
respective IP addresses which have been
assigned to you as the appropriate provider. You are asked to take
appropriate measures to inform your
customers about the potential infection.

The following information will be provided:

1. Public IP address
2. Last known timestamp of contact by the public IP address
3. Possible system name or username on the potentially infected system

The following information may be sent to your customers in addition to
the message of concern.

What should you do now?

1. Don???t panic!
2. Check your systems/networks for possible infections. If other
institutions have already made you aware
of infected systems recently, follow the action guidelines which you may
have received from them.
3. For further information on cleaning up infections, please visit the
English website of the Federal Office
for Information Security (BSI):

https://www.bsi.bund.de/EN/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Infizierte-Systeme-bereinigen/infizierte-systeme-bereinigen_node.html

Yours sincerely,

Bundeskriminalamt Wiesbaden

--
Glen A. Pearce
gap at ve4.ca
Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk.
Very Eager 4 Tees
http://www.ve4.ca
ARIN Handle VET-17
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/7d6868a6/attachment.html>

From nanog at ics-il.net  Mon Apr  3 12:47:07 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Apr 2023 07:47:07 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <a975f46f-3345-7dde-94cd-6f2b10fb8e28@west.net>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <a975f46f-3345-7dde-94cd-6f2b10fb8e28@west.net>
Message-ID: <101757534.300.1680526022074.JavaMail.mhammett@Thunderfuck2>

It shows the desired result. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Jay Hennigan" <jay at west.net> 
To: nanog at nanog.org 
Sent: Monday, April 3, 2023 1:02:42 AM 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

On 4/2/23 22:21, Mike Hammett wrote: 
> We have a Nexus 3064 that is setup with partial BGP tables and is 
> routing based on that. 
> 
> 
> I've done a show ip bgp for an IP of interest and it has an expected 
> next hop IP. I show ip arp on that next hop IP and it has the expected 
> interface. 
> 
> 
> However, sFlows show the packets leaving on a different interface, the 
> one that would carry the default route for routes not otherwise known. 
> 
> 
> If the next hop IP is expected and the ARP of that next hop IP is 
> expected, why are packets leaving out an unexpected interface? 

Another route to the destination from a routing protocol with a lower 
distance? 

What does "show ip route [destination]" look like? 

-- 
Jay Hennigan - jay at west.net 
Network Engineering - CCIE #7880 
503 897-8550 - WB6RDV 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/f0587e48/attachment.html>

From nanog at ics-il.net  Mon Apr  3 12:47:12 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Apr 2023 07:47:12 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <9fe9fab599304900b93393540cba97c4@ox.com>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <9fe9fab599304900b93393540cba97c4@ox.com>
Message-ID: <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>

It shows the desired result. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Matthew Huff" <mhuff at ox.com> 
To: "Mike Hammett" <nanog at ics-il.net>, "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 5:38:23 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

switch-core1# sh forwarding route x.x.x.x 

slot 1 
======= 


IPv4 routes for table default/base 

------------------+-----------------------------------------+----------------------+-----------------+----------------- 
Prefix | Next-hop | Interface | Labels | Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+----------------- 
x.x.x.x/24 x.x.x.250 Ethernet1/29 


switch-core1# show routing hash x.x.x.x y.y.y.y 
Load-share parameters used for software forwarding: 
load-share mode: address source-destination port source-destination 
Hash for VRF "default" 
Hashing to path *y.y.y.y Eth1/29 
For route: 
y.y.y.0/24, ubest/mbest: 1/0 
*via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal 




From: NANOG <nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of Mike Hammett 
Sent: Monday, April 3, 2023 1:21 AM 
To: NANOG <nanog at nanog.org> 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/f9a9183b/attachment.html>

From nanog at ics-il.net  Mon Apr  3 12:48:17 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Apr 2023 07:48:17 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
Message-ID: <41064163.306.1680526093901.JavaMail.mhammett@Thunderfuck2>

What started this investigation was a client complained of traffic coming from another upstream instead of our direct connection. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Mike Hammett" <nanog at ics-il.net> 
To: "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 12:21:29 AM 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 


We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/ce41e5bb/attachment.html>

From mhuff at ox.com  Mon Apr  3 12:50:08 2023
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 3 Apr 2023 12:50:08 +0000
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <9fe9fab599304900b93393540cba97c4@ox.com>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
Message-ID: <d3ba772ea6ea47269bb4c03c708176ec@ox.com>

SFlow misconfiguration or bug on either the nexus or the sflow monitor? On the monitor, can you verify that the snmp interfaces are mapped to the correct ones on the nexus?





From: Mike Hammett <nanog at ics-il.net>
Sent: Monday, April 3, 2023 8:47 AM
To: Matthew Huff <mhuff at ox.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging

It shows the desired result.


-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

________________________________
From: "Matthew Huff" <mhuff at ox.com<mailto:mhuff at ox.com>>
To: "Mike Hammett" <nanog at ics-il.net<mailto:nanog at ics-il.net>>, "NANOG" <nanog at nanog.org<mailto:nanog at nanog.org>>
Sent: Monday, April 3, 2023 5:38:23 AM
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging

switch-core1# sh forwarding route x.x.x.x

slot  1
=======


IPv4 routes for table default/base

------------------+-----------------------------------------+----------------------+-----------------+-----------------
Prefix            | Next-hop                                | Interface            | Labels          | Partial Install
------------------+-----------------------------------------+----------------------+-----------------+-----------------
x.x.x.x/24      x.x.x.250                            Ethernet1/29


switch-core1# show routing hash x.x.x.x y.y.y.y
Load-share parameters used for software forwarding:
load-share mode: address source-destination port source-destination
Hash for VRF "default"
Hashing to path *y.y.y.y Eth1/29
For route:
y.y.y.0/24, ubest/mbest: 1/0
    *via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal




From: NANOG <nanog-bounces+mhuff=ox.com at nanog.org<mailto:nanog-bounces+mhuff=ox.com at nanog.org>> On Behalf Of Mike Hammett
Sent: Monday, April 3, 2023 1:21 AM
To: NANOG <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that.


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface.


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known.


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface?


-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/81acfacc/attachment.html>

From nanog at ics-il.net  Mon Apr  3 12:59:53 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Apr 2023 07:59:53 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <9fe9fab599304900b93393540cba97c4@ox.com>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
 <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
Message-ID: <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>

It could be an sFlow bug, but I come at this from a reported problem and gathering data on that problem as opposed to looking at data for problems. 


The snmp if index reported by the Nexus matches the if index in ElastiFlow. 








----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Matthew Huff" <mhuff at ox.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 7:50:08 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 



SFlow misconfiguration or bug on either the nexus or the sflow monitor? On the monitor, can you verify that the snmp interfaces are mapped to the correct ones on the nexus? 







From: Mike Hammett <nanog at ics-il.net> 
Sent: Monday, April 3, 2023 8:47 AM 
To: Matthew Huff <mhuff at ox.com> 
Cc: NANOG <nanog at nanog.org> 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 


It shows the desired result. 



----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----


From: "Matthew Huff" < mhuff at ox.com > 
To: "Mike Hammett" < nanog at ics-il.net >, "NANOG" < nanog at nanog.org > 
Sent: Monday, April 3, 2023 5:38:23 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

switch-core1# sh forwarding route x.x.x.x 

slot 1 
======= 


IPv4 routes for table default/base 

------------------+-----------------------------------------+----------------------+-----------------+----------------- 
Prefix | Next-hop | Interface | Labels | Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+----------------- 
x.x.x.x/24 x.x.x.250 Ethernet1/29 


switch-core1# show routing hash x.x.x.x y.y.y.y 
Load-share parameters used for software forwarding: 
load-share mode: address source-destination port source-destination 
Hash for VRF "default" 
Hashing to path *y.y.y.y Eth1/29 
For route: 
y.y.y.0/24, ubest/mbest: 1/0 
*via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal 




From: NANOG < nanog-bounces+mhuff=ox.com at nanog.org > On Behalf Of Mike Hammett 
Sent: Monday, April 3, 2023 1:21 AM 
To: NANOG < nanog at nanog.org > 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/306d2071/attachment.html>

From mhuff at ox.com  Mon Apr  3 13:06:51 2023
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 3 Apr 2023 13:06:51 +0000
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <9fe9fab599304900b93393540cba97c4@ox.com>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
 <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
Message-ID: <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>

What about VRFs and/or policy based routing?  

switch-core1# show vrf
VRF-Name                           VRF-ID State   Reason                        
default                                 1 Up      --                            
management                              2 Up      --                            

switch-core1# show route-map 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10 
  Match clauses:
    interface: Ethernet1/33 
    route-type: internal 
  Set clauses:
    metric 40000000 10 255 1 1500 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20 
  Match clauses:
    interface: Ethernet1/34 
    route-type: internal 
  Set clauses:
    metric 40000000 30 255 1 1500 
route-map rmap_static_to_eigrp, permit, sequence 10 
  Match clauses:
    ip address prefix-lists: prefix_static_to_eigrp 
  Set clauses:
route-map rmap_static_to_eigrp_v6, permit, sequence 10 
  Match clauses:
    ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp 
  Set clauses:



From: Mike Hammett <nanog at ics-il.net> 
Sent: Monday, April 3, 2023 9:00 AM
To: Matthew Huff <mhuff at ox.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging

It could be an sFlow bug, but I come at this from a reported problem and gathering data on that problem as opposed to looking at data for problems.

The snmp if index reported by the Nexus matches the if index in ElastiFlow.




-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

________________________________________
From: "Matthew Huff" <mailto:mhuff at ox.com>
To: "Mike Hammett" <mailto:nanog at ics-il.net>
Cc: "NANOG" <mailto:nanog at nanog.org>
Sent: Monday, April 3, 2023 7:50:08 AM
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
SFlow misconfiguration or bug on either the nexus or the sflow monitor? On the monitor, can you verify that the snmp interfaces are mapped to the correct ones on the nexus?
?
?
?
?
?
From: Mike Hammett <mailto:nanog at ics-il.net> 
Sent: Monday, April 3, 2023 8:47 AM
To: Matthew Huff <mailto:mhuff at ox.com>
Cc: NANOG <mailto:nanog at nanog.org>
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
?
It shows the desired result.


-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com
?
________________________________________
From: "Matthew Huff" <mailto:mhuff at ox.com>
To: "Mike Hammett" <mailto:nanog at ics-il.net>, "NANOG" <mailto:nanog at nanog.org>
Sent: Monday, April 3, 2023 5:38:23 AM
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging

switch-core1# sh forwarding route x.x.x.x

slot ?1
=======


IPv4 routes for table default/base

------------------+-----------------------------------------+----------------------+-----------------+-----------------
Prefix ? ? ? ? ? ?| Next-hop ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Interface ? ? ? ? ? ?| Labels ? ? ? ? ?| Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+-----------------
x.x.x.x/24 ? ? ?x.x.x.250 ? ? ? ? ? ? ? ? ? ? ? ? ? ?Ethernet1/29 ? ? ? ?


switch-core1# show routing hash x.x.x.x y.y.y.y
Load-share parameters used for software forwarding:
load-share mode: address source-destination port source-destination
Hash for VRF "default"
Hashing to path *y.y.y.y Eth1/29
For route:
y.y.y.0/24, ubest/mbest: 1/0
?? ?*via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal




From: NANOG <mailto:nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of Mike Hammett
Sent: Monday, April 3, 2023 1:21 AM
To: NANOG <mailto:nanog at nanog.org>
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that.?


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface.?


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known.?


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface??


-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com
?


From mel at beckman.org  Mon Apr  3 13:21:09 2023
From: mel at beckman.org (Mel Beckman)
Date: Mon, 3 Apr 2023 13:21:09 +0000
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <ME4P282MB0902FE8DC53614507851324FF5929@ME4P282MB0902.AUSP282.PROD.OUTLOOK.COM>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
 <ME4P282MB0902FE8DC53614507851324FF5929@ME4P282MB0902.AUSP282.PROD.OUTLOOK.COM>
Message-ID: <72109B56-62B9-4853-AA42-F6A4D3BFFBB5@beckman.org>

Any security ?authority? that sends a warning email that requires opening _any_ attachment doesn?t deserve to be taken seriously. This include the MPAA et al. Also, if they don?t send it to your registered abuse email, into the trash it should go without a glance.

 -mel beckman

On Apr 3, 2023, at 4:37 AM, Suresh Ramasubramanian <ops.lists at gmail.com> wrote:

?
It appears legit.

BKA.DE is the German Bundeskriminalamt (Federal Police)

And the PTR records, SPF etc check out for the domain.

Might as well check the IP in question for malware if they?ve provided date / timestamps and such

--srs

From: NANOG <nanog-bounces+ops.lists=gmail.com at nanog.org> on behalf of Glen A. Pearce <nanog at ve4.ca>
Date: Monday, 3 April 2023 at 12:29 PM
To: nanog at nanog.org <nanog at nanog.org>
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a phishing E-mail or real...)
Hi All:

I received an E-mail with an attachment claiming something
on my network is infected and that I should look at the
attachment to find out what.

Normally I think everything with an attachment is phishing
to get me to run malware but:

#1: The sites linked to in it seem to be legit German
     government websites based on Wikipedia entries that
     haven't changed in several years.
     (Looked at archive.org)
#2: The attachment is a .txt file which I've normally
     assumed to be safe.
#3: None of the usual dead giveaways that most phishing
     E-mails have.

If it is a phishing E-mail it has got to be the cleverest
one I've ever seen, though someone would try to be cleaver
considering the target would be holders of IP blocks.

I right clicked and checked properties to make sure the
attached ip_addresses.txt file really is a text file and
not some fancy trickery with reverse direction characters
( As seen on https://www.youtube.com/watch?v=ieQUy8YTbFU )

I tried poking around to see if there was some vulnerability
in notepad (or some versions of it) that I didn't know about
and only found a vulnerability in the text editor on Macs
but nothing with Windows Notepad.

The other thing I felt was a bit off is that the originating
mail server is in Deutsche Telekom AG space and not IP Space
registered to the German government.  I'm thinking someone
could rent some IP space from Deutsche Telekom AG with a
connection to them in a data center and get the DNS delegated
to them so they could set the reverse DNS to whatever they want.
A lot of effort to try to look legit by coming out of Germany
and having a government domain in the reverse DNS to look like
a plausible legit outsourcing but again Network operators are
the target audience so the normal tricks that work on the
general public won't work with this group so I can see someone
going that far.

I'll attach the E-mail below with all headers.  Has anyone
else gotten these?  Is there some security risk opening it
in Windows Notepad that I don't know about or is it actually
safe to open this?


Return-Path: <abuse at cyber.bka.de>
Delivered-To: [REDACTED]
Received: from ezp08-pco.easydns.vpn ([10.5.10.148])
     by ezb03-pco.easydns.vpn with LMTP
     id oCfeBO/yEmTokhgAzaFxkQ
     (envelope-from <abuse at cyber.bka.de>)
     for <[REDACTED]>; Thu, 16 Mar 2023 10:43:59 +0000
Received: from smtp.easymail.ca ([127.0.0.1])
     by ezp08-pco.easydns.vpn with LMTP
     id WCB5BO/yEmSHdgEABcrfzg
     (envelope-from <abuse at cyber.bka.de>); Thu, 16 Mar 2023 10:43:59 +0000
Received: from localhost (localhost [127.0.0.1])
     by smtp.easymail.ca (Postfix) with ESMTP id 0DC85557DF
     for <arin at ve4.ca>; Thu, 16 Mar 2023 10:43:59 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at ezp08-pco.easydns.vpn
X-Spam-Flag: NO
X-Spam-Score: 0.075
X-Spam-Level:
X-Spam-Status: No, score=0.075 required=4 tests=[BAYES_00=-1.9,
     DEAR_SOMETHING=1.973, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
     SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from smtp.easymail.ca ([127.0.0.1])
     by localhost (ezp08-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port
10024)
     with ESMTP id d0XbPteZN-Io for <arin at ve4.ca>;
     Thu, 16 Mar 2023 10:43:55 +0000 (UTC)
Received: from mail.cyber.bka.de (mail.cyber.bka.de [80.146.190.22])
     by smtp.easymail.ca (Postfix) with ESMTPS id 0BC0C557DC
     for <arin at ve4.ca>; Thu, 16 Mar 2023 10:43:54 +0000 (UTC)
Date: Thu, 16 Mar 2023 10:43:53 +0000
To: arin at ve4.ca
From: BKA Wiesbaden - Abteilung Cybercrime <abuse at cyber.bka.de>
Reply-To: BKA Wiesbaden - Abteilung Cybercrime <abuse at cyber.bka.de>
Subject: Information regarding possible infection with malware
Message-ID:
<M47LJRZpjy1zymUJDKsNtrYm3RimkafZfZTqeZpauZA at emailapi.apps.cc.bka>
MIME-Version: 1.0
Content-Type: multipart/mixed;
  boundary="b1_M47LJRZpjy1zymUJDKsNtrYm3RimkafZfZTqeZpauZA"
Content-Transfer-Encoding: 8bit

Dear Sir or Madam,

As part of criminal proceedings, the German Federal Criminal Police
Office (Bundeskriminalamt) has been
informed about public IP addresses and timestamps which indicate a
potential infection by the malicious
software "Bumblebee" of one or more systems behind the respective public
IP address.

Within this letter, the BKA is providing you with the data of the
respective IP addresses which have been
assigned to you as the appropriate provider. You are asked to take
appropriate measures to inform your
customers about the potential infection.

The following information will be provided:

1. Public IP address
2. Last known timestamp of contact by the public IP address
3. Possible system name or username on the potentially infected system

The following information may be sent to your customers in addition to
the message of concern.

What should you do now?

1. Don???t panic!
2. Check your systems/networks for possible infections. If other
institutions have already made you aware
of infected systems recently, follow the action guidelines which you may
have received from them.
3. For further information on cleaning up infections, please visit the
English website of the Federal Office
for Information Security (BSI):

https://www.bsi.bund.de/EN/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Infizierte-Systeme-bereinigen/infizierte-systeme-bereinigen_node.html

Yours sincerely,

Bundeskriminalamt Wiesbaden

--
Glen A. Pearce
gap at ve4.ca
Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk.
Very Eager 4 Tees
http://www.ve4.ca
ARIN Handle VET-17
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/1a91bb76/attachment.html>

From nanog at ics-il.net  Mon Apr  3 13:26:30 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Apr 2023 08:26:30 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <9fe9fab599304900b93393540cba97c4@ox.com>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
 <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
 <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
Message-ID: <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>

Only two VRFs, default and manangement. IIRC, everything I saw before mentioned the default VRF. 

I do see a ton of route-maps. It's mostly Greek to me, so I'll have to dig through this a bit to see what's going on. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Matthew Huff" <mhuff at ox.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 8:06:51 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

What about VRFs and/or policy based routing? 

switch-core1# show vrf 
VRF-Name VRF-ID State Reason 
default 1 Up -- 
management 2 Up -- 

switch-core1# show route-map 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10 
Match clauses: 
interface: Ethernet1/33 
route-type: internal 
Set clauses: 
metric 40000000 10 255 1 1500 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20 
Match clauses: 
interface: Ethernet1/34 
route-type: internal 
Set clauses: 
metric 40000000 30 255 1 1500 
route-map rmap_static_to_eigrp, permit, sequence 10 
Match clauses: 
ip address prefix-lists: prefix_static_to_eigrp 
Set clauses: 
route-map rmap_static_to_eigrp_v6, permit, sequence 10 
Match clauses: 
ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp 
Set clauses: 



From: Mike Hammett <nanog at ics-il.net> 
Sent: Monday, April 3, 2023 9:00 AM 
To: Matthew Huff <mhuff at ox.com> 
Cc: NANOG <nanog at nanog.org> 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It could be an sFlow bug, but I come at this from a reported problem and gathering data on that problem as opposed to looking at data for problems. 

The snmp if index reported by the Nexus matches the if index in ElastiFlow. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto:mhuff at ox.com> 
To: "Mike Hammett" <mailto:nanog at ics-il.net> 
Cc: "NANOG" <mailto:nanog at nanog.org> 
Sent: Monday, April 3, 2023 7:50:08 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 
SFlow misconfiguration or bug on either the nexus or the sflow monitor? On the monitor, can you verify that the snmp interfaces are mapped to the correct ones on the nexus? 





From: Mike Hammett <mailto:nanog at ics-il.net> 
Sent: Monday, April 3, 2023 8:47 AM 
To: Matthew Huff <mailto:mhuff at ox.com> 
Cc: NANOG <mailto:nanog at nanog.org> 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It shows the desired result. 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto:mhuff at ox.com> 
To: "Mike Hammett" <mailto:nanog at ics-il.net>, "NANOG" <mailto:nanog at nanog.org> 
Sent: Monday, April 3, 2023 5:38:23 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

switch-core1# sh forwarding route x.x.x.x 

slot 1 
======= 


IPv4 routes for table default/base 

------------------+-----------------------------------------+----------------------+-----------------+----------------- 
Prefix | Next-hop | Interface | Labels | Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+----------------- 
x.x.x.x/24 x.x.x.250 Ethernet1/29 


switch-core1# show routing hash x.x.x.x y.y.y.y 
Load-share parameters used for software forwarding: 
load-share mode: address source-destination port source-destination 
Hash for VRF "default" 
Hashing to path *y.y.y.y Eth1/29 
For route: 
y.y.y.0/24, ubest/mbest: 1/0 
*via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal 




From: NANOG <mailto:nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of Mike Hammett 
Sent: Monday, April 3, 2023 1:21 AM 
To: NANOG <mailto:nanog at nanog.org> 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/5373039b/attachment.html>

From giera at belwue.de  Mon Apr  3 15:04:47 2023
From: giera at belwue.de (Stefan Giera)
Date: Mon, 3 Apr 2023 17:04:47 +0200
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
Message-ID: <ffeb72d7-29d1-f3cc-8065-03256b38ea4b@belwue.de>

Looks like scam to me, we are based in Germany and from time to time we 
are getting requests from BKA, all mails were originated from 
"*@bka.bund.de", never heard about ths "cyber.bka.de" Domain.
Also I would expect something more like a specific criminal 
investigation from the BKA instead of the usual "we found suspicious ip 
addresses" announcement like Shadowserver is offering.

Governmental services within DTAG (AS3320) ip space is pretty common in 
Germany.


HTH,
Stefan


-- 
Stefan Giera, BelW? (AS553)
BelW?-Koordination, Universit?t Stuttgart
Industriestr. 28, 70565 Stuttgart

Tel: +49 711/685-65797 | Durchwahl
Tel: +49 711/685-88030 | NOC, Netzbetrieb, Router
Tel: +49 711/685-88020 | (Schul)Hotline
Fax: +49 711/678 83 63
E-Mail: ip at belwue.de - http://www.belwue.de


From bjo at schafweide.org  Mon Apr  3 16:13:49 2023
From: bjo at schafweide.org (Bjoern Franke)
Date: Mon, 3 Apr 2023 18:13:49 +0200
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <ffeb72d7-29d1-f3cc-8065-03256b38ea4b@belwue.de>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
 <ffeb72d7-29d1-f3cc-8065-03256b38ea4b@belwue.de>
Message-ID: <8573acb9-98cf-aaf8-72dd-3c0b90c9ed01@schafweide.org>

Hi,
> Governmental services within DTAG (AS3320) ip space is pretty common in
> Germany.
> 

but FcrDNS matches. Scammers with access to the bka.de DNS?

Regards
Bjoern

From tony at wicks.co.nz  Mon Apr  3 20:54:55 2023
From: tony at wicks.co.nz (Tony Wicks)
Date: Tue, 4 Apr 2023 08:54:55 +1200
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <c3e5d888-d20d-c471-c59e-3452244a9f0d@tinka.africa>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
 <c3e5d888-d20d-c471-c59e-3452244a9f0d@tinka.africa>
Message-ID: <00cb01d9666e$8d1b90d0$a752b270$@wicks.co.nz>

I have been using the  QSFP-100G-CWDM4 2k optics for within rack/DC for a couple of years now. They are about the same price as SR optics but allow the use of simple duplex single mode patches without blasting 10K optics at each other over a 2M patch. Never had one fail or any compatibility issues. 

-----Original Message-----
From: NANOG <nanog-bounces+tony=wicks.co.nz at nanog.org> On Behalf Of Mark Tinka
Sent: Monday, April 3, 2023 11:04 PM
To: nanog at nanog.org
Subject: Re: 100G-LR1 (DR/FR)



On 4/3/23 02:14, David Siegel wrote:

> At this point, I'd be happy to see others happily deploy a 
> single-lambda optic of almost any variety!  Since deploying 400G in a 
> clients network (but 100G still being the preferred connection 
> choice), any inquiry with respect to LR1, FR1 or DR+ is met with "no 
> thanks, LR4 please."
>
> If asked, I'd recommend FR1.  They're available at a great 
> price-point, and 2km reach is adequate for most applications.

Agreed.

Pricing between LR4, FR and DR is not too far apart.

The only optic that is substantially cheaper than all of them is the SR4.

So in my mind, FR is the most ideal, although I'd still use SR4 for in-rack, multi-mode cabling.

Mark.


From nanog at ics-il.net  Mon Apr  3 21:20:05 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Apr 2023 16:20:05 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <9fe9fab599304900b93393540cba97c4@ox.com>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
 <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
 <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
 <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>
Message-ID: <631619927.25505.1680556805228.JavaMail.zimbra@ics-il.net>

I don't see any route-maps applied to interfaces, so there must not be any PBR going on. I only see ACLs, setting communities, setting local pref, etc. in the route maps that are applied to neighbors. 



----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 


From: "Mike Hammett" <nanog at ics-il.net> 
To: "Matthew Huff" <mhuff at ox.com> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 8:26:30 AM 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

Only two VRFs, default and manangement. IIRC, everything I saw before mentioned the default VRF. 

I do see a ton of route-maps. It's mostly Greek to me, so I'll have to dig through this a bit to see what's going on. 



----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 


From: "Matthew Huff" <mhuff at ox.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 8:06:51 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

What about VRFs and/or policy based routing? 

switch-core1# show vrf 
VRF-Name VRF-ID State Reason 
default 1 Up -- 
management 2 Up -- 

switch-core1# show route-map 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10 
Match clauses: 
interface: Ethernet1/33 
route-type: internal 
Set clauses: 
metric 40000000 10 255 1 1500 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20 
Match clauses: 
interface: Ethernet1/34 
route-type: internal 
Set clauses: 
metric 40000000 30 255 1 1500 
route-map rmap_static_to_eigrp, permit, sequence 10 
Match clauses: 
ip address prefix-lists: prefix_static_to_eigrp 
Set clauses: 
route-map rmap_static_to_eigrp_v6, permit, sequence 10 
Match clauses: 
ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp 
Set clauses: 



From: Mike Hammett <nanog at ics-il.net> 
Sent: Monday, April 3, 2023 9:00 AM 
To: Matthew Huff <mhuff at ox.com> 
Cc: NANOG <nanog at nanog.org> 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It could be an sFlow bug, but I come at this from a reported problem and gathering data on that problem as opposed to looking at data for problems. 

The snmp if index reported by the Nexus matches the if index in ElastiFlow. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto:mhuff at ox.com> 
To: "Mike Hammett" <mailto:nanog at ics-il.net> 
Cc: "NANOG" <mailto:nanog at nanog.org> 
Sent: Monday, April 3, 2023 7:50:08 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 
SFlow misconfiguration or bug on either the nexus or the sflow monitor? On the monitor, can you verify that the snmp interfaces are mapped to the correct ones on the nexus? 





From: Mike Hammett <mailto:nanog at ics-il.net> 
Sent: Monday, April 3, 2023 8:47 AM 
To: Matthew Huff <mailto:mhuff at ox.com> 
Cc: NANOG <mailto:nanog at nanog.org> 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It shows the desired result. 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto:mhuff at ox.com> 
To: "Mike Hammett" <mailto:nanog at ics-il.net>, "NANOG" <mailto:nanog at nanog.org> 
Sent: Monday, April 3, 2023 5:38:23 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

switch-core1# sh forwarding route x.x.x.x 

slot 1 
======= 


IPv4 routes for table default/base 

------------------+-----------------------------------------+----------------------+-----------------+----------------- 
Prefix | Next-hop | Interface | Labels | Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+----------------- 
x.x.x.x/24 x.x.x.250 Ethernet1/29 


switch-core1# show routing hash x.x.x.x y.y.y.y 
Load-share parameters used for software forwarding: 
load-share mode: address source-destination port source-destination 
Hash for VRF "default" 
Hashing to path *y.y.y.y Eth1/29 
For route: 
y.y.y.0/24, ubest/mbest: 1/0 
*via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal 




From: NANOG <mailto:nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of Mike Hammett 
Sent: Monday, April 3, 2023 1:21 AM 
To: NANOG <mailto:nanog at nanog.org> 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/c4f91c46/attachment.html>

From davidbass570 at gmail.com  Tue Apr  4 02:12:52 2023
From: davidbass570 at gmail.com (David Bass)
Date: Mon, 3 Apr 2023 22:12:52 -0400
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <631619927.25505.1680556805228.JavaMail.zimbra@ics-il.net>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <9fe9fab599304900b93393540cba97c4@ox.com>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
 <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
 <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
 <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>
 <631619927.25505.1680556805228.JavaMail.zimbra@ics-il.net>
Message-ID: <CAJ7C-Op=8c6DeB7J0AA-rsbuu2jyxkJPE6crEPyzB2DcwmfLdw@mail.gmail.com>

You said that they are seeing traffic from another upstream?are you
advertising the prefix to them?  Are you advertising their prefix to your
upstream?

Looks like the route maps are involved in some dual redistribution?might
want to make sure everything is matching correctly, and being advertised
like you want.

On Mon, Apr 3, 2023 at 4:20 PM Mike Hammett <nanog at ics-il.net> wrote:

> I don't see any route-maps applied to interfaces, so there must not be any
> PBR going on. I only see ACLs, setting communities, setting local pref,
> etc. in the route maps that are applied to neighbors.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ------------------------------
> *From: *"Mike Hammett" <nanog at ics-il.net>
> *To: *"Matthew Huff" <mhuff at ox.com>
> *Cc: *"NANOG" <nanog at nanog.org>
> *Sent: *Monday, April 3, 2023 8:26:30 AM
>
> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> Only two VRFs, default and manangement. IIRC, everything I saw before
> mentioned the default VRF.
>
> I do see a ton of route-maps. It's mostly Greek to me, so I'll have to dig
> through this a bit to see what's going on.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ------------------------------
> *From: *"Matthew Huff" <mhuff at ox.com>
> *To: *"Mike Hammett" <nanog at ics-il.net>
> *Cc: *"NANOG" <nanog at nanog.org>
> *Sent: *Monday, April 3, 2023 8:06:51 AM
> *Subject: *RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> What about VRFs and/or policy based routing?
>
> switch-core1# show vrf
> VRF-Name                           VRF-ID State   Reason
>
> default                                 1 Up      --
>
> management                              2 Up      --
>
>
> switch-core1# show route-map
> route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10
>   Match clauses:
>     interface: Ethernet1/33
>     route-type: internal
>   Set clauses:
>     metric 40000000 10 255 1 1500
> route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20
>   Match clauses:
>     interface: Ethernet1/34
>     route-type: internal
>   Set clauses:
>     metric 40000000 30 255 1 1500
> route-map rmap_static_to_eigrp, permit, sequence 10
>   Match clauses:
>     ip address prefix-lists: prefix_static_to_eigrp
>   Set clauses:
> route-map rmap_static_to_eigrp_v6, permit, sequence 10
>   Match clauses:
>     ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp
>   Set clauses:
>
>
>
> From: Mike Hammett <nanog at ics-il.net>
> Sent: Monday, April 3, 2023 9:00 AM
> To: Matthew Huff <mhuff at ox.com>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> It could be an sFlow bug, but I come at this from a reported problem and
> gathering data on that problem as opposed to looking at data for problems.
>
> The snmp if index reported by the Nexus matches the if index in ElastiFlow.
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ________________________________________
> From: "Matthew Huff" <mailto:mhuff at ox.com>
> To: "Mike Hammett" <mailto:nanog at ics-il.net>
> Cc: "NANOG" <mailto:nanog at nanog.org>
> Sent: Monday, April 3, 2023 7:50:08 AM
> Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
> SFlow misconfiguration or bug on either the nexus or the sflow monitor? On
> the monitor, can you verify that the snmp interfaces are mapped to the
> correct ones on the nexus?
>
>
>
>
>
> From: Mike Hammett <mailto:nanog at ics-il.net>
> Sent: Monday, April 3, 2023 8:47 AM
> To: Matthew Huff <mailto:mhuff at ox.com>
> Cc: NANOG <mailto:nanog at nanog.org>
> Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> It shows the desired result.
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ________________________________________
> From: "Matthew Huff" <mailto:mhuff at ox.com>
> To: "Mike Hammett" <mailto:nanog at ics-il.net>, "NANOG" <mailto:
> nanog at nanog.org>
> Sent: Monday, April 3, 2023 5:38:23 AM
> Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> switch-core1# sh forwarding route x.x.x.x
>
> slot  1
> =======
>
>
> IPv4 routes for table default/base
>
>
> ------------------+-----------------------------------------+----------------------+-----------------+-----------------
> Prefix            | Next-hop                                | Interface
>          | Labels          | Partial Install
>
> ------------------+-----------------------------------------+----------------------+-----------------+-----------------
> x.x.x.x/24      x.x.x.250                            Ethernet1/29
>
>
> switch-core1# show routing hash x.x.x.x y.y.y.y
> Load-share parameters used for software forwarding:
> load-share mode: address source-destination port source-destination
> Hash for VRF "default"
> Hashing to path *y.y.y.y Eth1/29
> For route:
> y.y.y.0/24, ubest/mbest: 1/0
>     *via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal
>
>
>
>
> From: NANOG <mailto:nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of
> Mike Hammett
> Sent: Monday, April 3, 2023 1:21 AM
> To: NANOG <mailto:nanog at nanog.org>
> Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> We have a Nexus 3064 that is setup with partial BGP tables and is routing
> based on that.
>
>
> I've done a show ip bgp for an IP of interest and it has an expected next
> hop IP. I show ip arp on that next hop IP and it has the expected
> interface.
>
>
> However, sFlows show the packets leaving on a different interface, the one
> that would carry the default route for routes not otherwise known.
>
>
> If the next hop IP is expected and the ARP of that next hop IP is
> expected, why are packets leaving out an unexpected interface?
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230403/50cc4811/attachment.html>

From josmon at rigozsaurus.com  Tue Apr  4 02:57:03 2023
From: josmon at rigozsaurus.com (John Osmon)
Date: Mon, 3 Apr 2023 20:57:03 -0600
Subject: ABQNOG -- May 4, 2023
Message-ID: <20230404025703.GA6525@jeeves.rigozsaurus.com>

For folks that might be in the southwest US (and any that want to
visit!), we're going to hold an operators group meeting on May 4,
2023 in Albuquerque, New Mexico.

Come to the land of green chile chessburgers, and meet some of the
local operators.  This inaugural meeting is free.  We hope to 
see you in May!

http://abqnog.org




From mark at tinka.africa  Tue Apr  4 04:44:50 2023
From: mark at tinka.africa (Mark Tinka)
Date: Tue, 4 Apr 2023 06:44:50 +0200
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <00cb01d9666e$8d1b90d0$a752b270$@wicks.co.nz>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
 <c3e5d888-d20d-c471-c59e-3452244a9f0d@tinka.africa>
 <00cb01d9666e$8d1b90d0$a752b270$@wicks.co.nz>
Message-ID: <300b460e-cdb0-5ff7-4654-7a96db898eec@tinka.africa>



On 4/3/23 22:54, Tony Wicks wrote:

> I have been using the  QSFP-100G-CWDM4 2k optics for within rack/DC for a couple of years now. They are about the same price as SR optics but allow the use of simple duplex single mode patches without blasting 10K optics at each other over a 2M patch. Never had one fail or any compatibility issues.

Our use of multi-mode fibre is historical, from the days when vendors 
sold line cards that were mode-fixed and not pluggable. The installed 
base is so large that it's just easier to carry on with multi-mode for 
in-rack cabling, where it's needed.

Mark.

From brandon at rd.bbc.co.uk  Tue Apr  4 06:54:38 2023
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Tue, 4 Apr 2023 07:54:38 +0100
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <00cb01d9666e$8d1b90d0$a752b270$@wicks.co.nz>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
 <c3e5d888-d20d-c471-c59e-3452244a9f0d@tinka.africa>
 <00cb01d9666e$8d1b90d0$a752b270$@wicks.co.nz>
Message-ID: <20230404065437.GB26837@sunf68.rd.bbc.co.uk>

On Tue Apr 04, 2023 at 08:54:55AM +1200, Tony Wicks wrote:
> I have been using the  QSFP-100G-CWDM4 2k optics for within rack/DC
> for a couple of years now. They are about the same price as SR optics
> but allow the use of simple duplex single mode patches without blasting
> 10K optics at each other over a 2M patch

10k used to be standard part at lower speeds. It's a bogus measure of link
budget which is what really matters and is lower for the same rated
distance with each speed increase.

At 4.3dB an LR4 is hardly blasting. While you are fine in rack with
the 1.6dB of FR4, in the average DC with a MMR it is marginal/broken. I'd
prefer they had the old 1G LX's 9dB.

brandon

From nanog at ics-il.net  Tue Apr  4 12:45:00 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 4 Apr 2023 07:45:00 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <CAJ7C-Op=8c6DeB7J0AA-rsbuu2jyxkJPE6crEPyzB2DcwmfLdw@mail.gmail.com>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
 <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
 <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
 <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>
 <631619927.25505.1680556805228.JavaMail.zimbra@ics-il.net>
 <CAJ7C-Op=8c6DeB7J0AA-rsbuu2jyxkJPE6crEPyzB2DcwmfLdw@mail.gmail.com>
Message-ID: <761501209.605.1680612295892.JavaMail.mhammett@Thunderfuck2>






sh ip bgp neighbor advertised-routes shows the only routes being advertised to Y are the routes that should be advertised to them. I checked a variety of other peers and have the expected results. 






>From my perspective: 


Packets come in on port A, supposed to leave on port X, but they leave on port Y. All of the troubleshooting steps I've done on my own (or suggested by mailing lists) say the packets should be leaving on the desired port X. 




>From the customer's perspective, they're supposed to be coming from me on port X, but they're arriving on port Y, another network . 


Port X in both scenarios is our direct connection, while port Y is a mutual upstream provider. 




Without knowing more about the specific platform, it seems to me like a bug in the platform. If all indicators (not just configurations, but show commands as well) say the packet should be leaving on X and it leaves on Y, then I'm not sure what else it could be, besides a bug. 





----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "David Bass" <davidbass570 at gmail.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "Matthew Huff" <mhuff at ox.com>, "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 9:12:52 PM 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 


You said that they are seeing traffic from another upstream?are you advertising the prefix to them? Are you advertising their prefix to your upstream? 


Looks like the route maps are involved in some dual redistribution?might want to make sure everything is matching correctly, and being advertised like you want. 



On Mon, Apr 3, 2023 at 4:20 PM Mike Hammett < nanog at ics-il.net > wrote: 





I don't see any route-maps applied to interfaces, so there must not be any PBR going on. I only see ACLs, setting communities, setting local pref, etc. in the route maps that are applied to neighbors. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Mike Hammett" < nanog at ics-il.net > 
To: "Matthew Huff" < mhuff at ox.com > 
Cc: "NANOG" < nanog at nanog.org > 
Sent: Monday, April 3, 2023 8:26:30 AM 



Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 




Only two VRFs, default and manangement. IIRC, everything I saw before mentioned the default VRF. 

I do see a ton of route-maps. It's mostly Greek to me, so I'll have to dig through this a bit to see what's going on. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Matthew Huff" < mhuff at ox.com > 
To: "Mike Hammett" < nanog at ics-il.net > 
Cc: "NANOG" < nanog at nanog.org > 
Sent: Monday, April 3, 2023 8:06:51 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

What about VRFs and/or policy based routing? 

switch-core1# show vrf 
VRF-Name VRF-ID State Reason 
default 1 Up -- 
management 2 Up -- 

switch-core1# show route-map 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10 
Match clauses: 
interface: Ethernet1/33 
route-type: internal 
Set clauses: 
metric 40000000 10 255 1 1500 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20 
Match clauses: 
interface: Ethernet1/34 
route-type: internal 
Set clauses: 
metric 40000000 30 255 1 1500 
route-map rmap_static_to_eigrp, permit, sequence 10 
Match clauses: 
ip address prefix-lists: prefix_static_to_eigrp 
Set clauses: 
route-map rmap_static_to_eigrp_v6, permit, sequence 10 
Match clauses: 
ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp 
Set clauses: 



From: Mike Hammett < nanog at ics-il.net > 
Sent: Monday, April 3, 2023 9:00 AM 
To: Matthew Huff < mhuff at ox.com > 
Cc: NANOG < nanog at nanog.org > 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It could be an sFlow bug, but I come at this from a reported problem and gathering data on that problem as opposed to looking at data for problems. 

The snmp if index reported by the Nexus matches the if index in ElastiFlow. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto: mhuff at ox.com > 
To: "Mike Hammett" <mailto: nanog at ics-il.net > 
Cc: "NANOG" <mailto: nanog at nanog.org > 
Sent: Monday, April 3, 2023 7:50:08 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 
SFlow misconfiguration or bug on either the nexus or the sflow monitor? On the monitor, can you verify that the snmp interfaces are mapped to the correct ones on the nexus? 





From: Mike Hammett <mailto: nanog at ics-il.net > 
Sent: Monday, April 3, 2023 8:47 AM 
To: Matthew Huff <mailto: mhuff at ox.com > 
Cc: NANOG <mailto: nanog at nanog.org > 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It shows the desired result. 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto: mhuff at ox.com > 
To: "Mike Hammett" <mailto: nanog at ics-il.net >, "NANOG" <mailto: nanog at nanog.org > 
Sent: Monday, April 3, 2023 5:38:23 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

switch-core1# sh forwarding route x.x.x.x 

slot 1 
======= 


IPv4 routes for table default/base 

------------------+-----------------------------------------+----------------------+-----------------+----------------- 
Prefix | Next-hop | Interface | Labels | Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+----------------- 
x.x.x.x/24 x.x.x.250 Ethernet1/29 


switch-core1# show routing hash x.x.x.x y.y.y.y 
Load-share parameters used for software forwarding: 
load-share mode: address source-destination port source-destination 
Hash for VRF "default" 
Hashing to path *y.y.y.y Eth1/29 
For route: 
y.y.y.0/24, ubest/mbest: 1/0 
*via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal 




From: NANOG <mailto: nanog-bounces+mhuff = ox.com at nanog.org > On Behalf Of Mike Hammett 
Sent: Monday, April 3, 2023 1:21 AM 
To: NANOG <mailto: nanog at nanog.org > 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/45a5c4a5/attachment.html>

From nanog at ics-il.net  Tue Apr  4 13:04:02 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 4 Apr 2023 08:04:02 -0500 (CDT)
Subject: Flow Tools AS-Path
In-Reply-To: <2010877999.611.1680613253518.JavaMail.mhammett@Thunderfuck2>
Message-ID: <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>

One of the reasons to analyze flow data is to make purchase\peering decisions. The sFlow standard seems to only include source and destination AS, though I know some route platforms have extensions to provide additional data. 


1) How common is it to have the additional extensions to include that data for analysis? 
2) I have seen flow tools that show the entire AS path. Are they just cherry picking which platforms they showcase for the best marketing, or are they enriching the data they receive from "lesser" platforms from an outside source? 


For that purpose, knowing what ASes your data goes to is useful. It's even more useful to find an upstream network that includes a bunch of those. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/ad3c3aac/attachment.html>

From Roland.Dobbins at netscout.com  Tue Apr  4 13:30:16 2023
From: Roland.Dobbins at netscout.com (Dobbins, Roland)
Date: Tue, 4 Apr 2023 13:30:16 +0000
Subject: Flow Tools AS-Path
In-Reply-To: <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
References: <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
Message-ID: <A930F943-C761-47CD-B8F1-906792131A0A@netscout.com>


On 4 Apr 2023, at 20:04, Mike Hammett <nanog at ics-il.net<mailto:nanog at ics-il.net>> wrote:

2) I have seen flow tools that show the entire AS path. Are they just cherry picking which platforms they showcase for the best marketing, or are they enriching the data they receive from "lesser" platforms from an outside source?

Full AS-path information isn?t typically included in flow telemetry records.  One typically receives origin-AS and destination-AS from exporting devices, along with BGP next-hop information.

Tools which provide the detailed type of information you?re describing typically provide combinatorial analysis of both flow telemetry received from edge routers and either live or offline BGP routing information.

[Full disclosure: I work for a vendor of such tools.]

--------------------------------------------
Roland Dobbins <roland.dobbins at netscout.com<mailto:roland.dobbins at netscout.com>>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/8b87ad3d/attachment.html>

From niels=nanog at bakker.net  Tue Apr  4 13:50:49 2023
From: niels=nanog at bakker.net (Niels Bakker)
Date: Tue, 4 Apr 2023 15:50:49 +0200
Subject: Flow Tools AS-Path
In-Reply-To: <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
References: <2010877999.611.1680613253518.JavaMail.mhammett@Thunderfuck2>
 <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
Message-ID: <ZCwrOdRfmTlO1sGv@jima.tpb.net>

* nanog at ics-il.net (Mike Hammett) [Tue 04 Apr 2023, 15:06 CEST]:
>1) How common is it to have the additional extensions to include 
>that data for analysis?

pmacct is a commonly used tool to enrich flow data with such 
information.


	-- Niels.

From peter.phaal at gmail.com  Tue Apr  4 14:48:29 2023
From: peter.phaal at gmail.com (Peter Phaal)
Date: Tue, 4 Apr 2023 07:48:29 -0700
Subject: Flow Tools AS-Path
In-Reply-To: <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
References: <2010877999.611.1680613253518.JavaMail.mhammett@Thunderfuck2>
 <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
Message-ID: <CAB8g2zyqgCaFKxtkpkYAjQyjoBpQReOFLHtW4gabw6BBoNYegQ@mail.gmail.com>

Export of destination AS-Path is supported in the sFlow extended_gateway
structure.

/* Extended Gateway Data */
/* opaque = flow_data; enterprise = 0; format = 1003 */

struct extended_gateway {
   next_hop nexthop;           /* Address of the border router that should
                                  be used for the destination network */
   unsigned int as;            /* Autonomous system number of router */
   unsigned int src_as;        /* Autonomous system number of source */
   unsigned int src_peer_as;   /* Autonomous system number of source peer */
   as_path_type dst_as_path<>; /* Autonomous system path to the destination */
   unsigned int communities<>; /* Communities associated with this route */
   unsigned int localpref;     /* LocalPref associated with this route */
}

Arista EOS supports aspath if you enable sflow extension bgp. Cisco
also claims to support the feature on IOS XR platforms.

In addition to BGP, there are a number of MPLS, tunnel encap/decap
etc. sFlow extended structures.

Also optical interface metrics, dropped packet notifications, and more:

https://sflow.org/developers/specifications.php


On Tue, Apr 4, 2023 at 6:06?AM Mike Hammett <nanog at ics-il.net> wrote:

> One of the reasons to analyze flow data is to make purchase\peering
> decisions. The sFlow standard seems to only include source and destination
> AS, though I know some route platforms have extensions to provide
> additional data.
>
> 1) How common is it to have the additional extensions to include that data
> for analysis?
> 2) I have seen flow tools that show the entire AS path. Are they just
> cherry picking which platforms they showcase for the best marketing, or are
> they enriching the data they receive from "lesser" platforms from an
> outside source?
>
> For that purpose, knowing what ASes your data goes to is useful. It's even
> more useful to find an upstream network that includes a bunch of those.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/b45e4d14/attachment.html>

From Roland.Dobbins at netscout.com  Tue Apr  4 15:03:53 2023
From: Roland.Dobbins at netscout.com (Dobbins, Roland)
Date: Tue, 4 Apr 2023 15:03:53 +0000
Subject: Flow Tools AS-Path
In-Reply-To: <CAB8g2zyqgCaFKxtkpkYAjQyjoBpQReOFLHtW4gabw6BBoNYegQ@mail.gmail.com>
References: <2010877999.611.1680613253518.JavaMail.mhammett@Thunderfuck2>
 <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
 <CAB8g2zyqgCaFKxtkpkYAjQyjoBpQReOFLHtW4gabw6BBoNYegQ@mail.gmail.com>
Message-ID: <235FE6CC-F26E-460F-B1FE-080148C5C920@netscout.com>



On 4 Apr 2023, at 21:48, Peter Phaal <peter.phaal at gmail.com<mailto:peter.phaal at gmail.com>> wrote:

Export of destination AS-Path is supported in the sFlow extended_gateway structure.

As a consumer of sFlow, [as well as NetFlow, IPFIX, etc.] I haven?t run into the use of this option in production, FWIW.

In addition to BGP, there are a number of MPLS, tunnel encap/decap etc. sFlow extended structures.

Some of these options are encountered fairly frequently; others, not so much.  As you note, they have different applications.

Also optical interface metrics, dropped packet notifications, and more:

Dropped traffic is pretty much universally supported and utilized, in my experience.  Other options, again, not very often.

Some flow telemetry implementations support packet export, to one degree or another; and, of course, there?s PSAMP, which utilizes IPFIX as its transport.  AFAIK, these aren?t observed very often in production, to date.

--------------------------------------------
Roland Dobbins <roland.dobbins at netscout.com<mailto:roland.dobbins at netscout.com>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/f38c699f/attachment.html>

From jk at ip-clear.de  Tue Apr  4 15:13:33 2023
From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg_Kost?=)
Date: Tue, 04 Apr 2023 17:13:33 +0200
Subject: Flow Tools AS-Path
In-Reply-To: <CAB8g2zyqgCaFKxtkpkYAjQyjoBpQReOFLHtW4gabw6BBoNYegQ@mail.gmail.com>
References: <2010877999.611.1680613253518.JavaMail.mhammett@Thunderfuck2>
 <696990415.622.1680613436589.JavaMail.mhammett@Thunderfuck2>
 <CAB8g2zyqgCaFKxtkpkYAjQyjoBpQReOFLHtW4gabw6BBoNYegQ@mail.gmail.com>
Message-ID: <D86CD506-16A6-4A92-A00A-795FB40F2A70@ip-clear.de>

Hi,

Extreme also supports it, and we use it for conducting statistics against dst_as/dst_peer_as to perform "traffic engineering" specifically for the transit paths. dst_as_path can also identify possible future peering situations or undesirable paths.

BR
J?rg

On 4 Apr 2023, at 16:48, Peter Phaal wrote:

> Export of destination AS-Path is supported in the sFlow extended_gateway
> structure.
>
> /* Extended Gateway Data */
> /* opaque = flow_data; enterprise = 0; format = 1003 */
>
> struct extended_gateway {
>    next_hop nexthop;           /* Address of the border router that should
>                                   be used for the destination network */
>    unsigned int as;            /* Autonomous system number of router */
>    unsigned int src_as;        /* Autonomous system number of source */
>    unsigned int src_peer_as;   /* Autonomous system number of source peer */
>    as_path_type dst_as_path<>; /* Autonomous system path to the destination */
>    unsigned int communities<>; /* Communities associated with this route */
>    unsigned int localpref;     /* LocalPref associated with this route */
> }
>
> Arista EOS supports aspath if you enable sflow extension bgp. Cisco
> also claims to support the feature on IOS XR platforms.
>
> In addition to BGP, there are a number of MPLS, tunnel encap/decap
> etc. sFlow extended structures.
>
> Also optical interface metrics, dropped packet notifications, and more:
>
> https://sflow.org/developers/specifications.php
>

From jared at puck.nether.net  Tue Apr  4 15:39:08 2023
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 4 Apr 2023 11:39:08 -0400
Subject: SF union square area fiber
Message-ID: <7A78D4E2-979A-4FC0-9ECA-137A613E0CE3@puck.nether.net>

Can someone who is familiar with the fiber assets around the union square area in SF ping me off-list?

Thanks.

- jared

From jared at puck.nether.net  Tue Apr  4 15:42:30 2023
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 4 Apr 2023 11:42:30 -0400
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
Message-ID: <56EE0B27-C5B0-443B-AB49-50E6BEDEF5E8@puck.nether.net>

We are willing to do 100G-LR1 if someone asks these days.  It lets us be able to roll it up into 400G optics on our side as appropriate.  

The big difference in DR/FR is the receiver sensitivity, they are all compatible optically, so it?s really about the DR/FR being yield rejects for LR1.  It?s also less components in the LR1 vs 100G-LR4 since you don?t need 4 transmitters and 4 receivers and if one fails you toss the optic, so fewer components is also lower cost.

- Jared

> On Apr 2, 2023, at 8:14 PM, David Siegel <arizonagull at gmail.com> wrote:
> 
> At this point, I'd be happy to see others happily deploy a single-lambda optic of almost any variety!  Since deploying 400G in a clients network (but 100G still being the preferred connection choice), any inquiry with respect to LR1, FR1 or DR+ is met with "no thanks, LR4 please."
> 
> If asked, I'd recommend FR1.  They're available at a great price-point, and 2km reach is adequate for most applications.
> 
> On Fri, Mar 31, 2023 at 7:25?AM Jared Mauch <jared at puck.nether.net> wrote:
> The common tech is 100G-LR4 these days - I'm wondering how many operators are supporting the LR1 to allow its use on 400G and future 800G optics as those use breakout to support 100G ports. 
> 
> Would you rather do a 400G port on a router vs 100LR1?
> 
> Curious what others think. 
> 
> Sent via RFC1925 compliant device


From jared at puck.nether.net  Tue Apr  4 15:44:09 2023
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 4 Apr 2023 11:44:09 -0400
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <00cb01d9666e$8d1b90d0$a752b270$@wicks.co.nz>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
 <c3e5d888-d20d-c471-c59e-3452244a9f0d@tinka.africa>
 <00cb01d9666e$8d1b90d0$a752b270$@wicks.co.nz>
Message-ID: <87EAE876-34C2-4DBF-8A0D-6938A01E5C20@puck.nether.net>



> On Apr 3, 2023, at 4:54 PM, Tony Wicks <tony at wicks.co.nz> wrote:
> 
> I have been using the  QSFP-100G-CWDM4 2k optics for within rack/DC for a couple of years now. They are about the same price as SR optics but allow the use of simple duplex single mode patches without blasting 10K optics at each other over a 2M patch. Never had one fail or any compatibility issues. 

We saw some issues with the CWDM4 optics failing that caused us to make some changes in how we used those optics.  I?ve also heard rumors some of the CWDM4 optics would go 10x the published spec, but I have not tested that myself.

- Jared

From woody at pch.net  Tue Apr  4 15:47:46 2023
From: woody at pch.net (Bill Woodcock)
Date: Tue, 4 Apr 2023 17:47:46 +0200
Subject: SF union square area fiber
In-Reply-To: <7A78D4E2-979A-4FC0-9ECA-137A613E0CE3@puck.nether.net>
References: <7A78D4E2-979A-4FC0-9ECA-137A613E0CE3@puck.nether.net>
Message-ID: <22456947-8325-4831-8052-C3F7EA95B03E@pch.net>

> On Apr 4, 2023, at 5:39 PM, Jared Mauch <jared at puck.nether.net> wrote:
> Can someone who is familiar with the fiber assets around the union square area in SF ping me off-list?

Heh.  Somewhere, I have photos that Steve Feldman and I took while spelunking around under there trying to find fiber for the NANOG that was held there in 1997.  We found a gas-chandelier maintenance department that people had just locked up and walked away from.  Tools still spread out on workbenches, lamps half-rebuilt, everything.  It was like electrification had hit one day during lunch-hour.

                                -Bill


From swmike at swm.pp.se  Tue Apr  4 15:50:03 2023
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 4 Apr 2023 17:50:03 +0200 (CEST)
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <56EE0B27-C5B0-443B-AB49-50E6BEDEF5E8@puck.nether.net>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
 <56EE0B27-C5B0-443B-AB49-50E6BEDEF5E8@puck.nether.net>
Message-ID: <alpine.DEB.2.20.2304041748320.2636@uplift.swm.pp.se>

On Tue, 4 Apr 2023, Jared Mauch wrote:

> We are willing to do 100G-LR1 if someone asks these days.  It lets us be 
> able to roll it up into 400G optics on our side as appropriate.

I hope the industry moves to 100G-LR1, as doing 2x100GBASE-LR4 in a 400G 
port is quite meh when it comes to faceplate capacity.

Unfortunately 100GBASE-LR4 will be with us for a long long time.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From dave.taht at gmail.com  Tue Apr  4 15:57:24 2023
From: dave.taht at gmail.com (Dave Taht)
Date: Tue, 4 Apr 2023 08:57:24 -0700
Subject: SF union square area fiber
In-Reply-To: <22456947-8325-4831-8052-C3F7EA95B03E@pch.net>
References: <7A78D4E2-979A-4FC0-9ECA-137A613E0CE3@puck.nether.net>
 <22456947-8325-4831-8052-C3F7EA95B03E@pch.net>
Message-ID: <CAA93jw6cSJXbmq1G11R9rB4=pfchEr+_yNGy=QR8VHkvFuSmNA@mail.gmail.com>

That is a very illustrative photo of the state of the internet plant,
even today. I hope you find it!

On Tue, Apr 4, 2023 at 8:51?AM Bill Woodcock <woody at pch.net> wrote:
>
> > On Apr 4, 2023, at 5:39 PM, Jared Mauch <jared at puck.nether.net> wrote:
> > Can someone who is familiar with the fiber assets around the union square area in SF ping me off-list?
>
> Heh.  Somewhere, I have photos that Steve Feldman and I took while spelunking around under there trying to find fiber for the NANOG that was held there in 1997.  We found a gas-chandelier maintenance department that people had just locked up and walked away from.  Tools still spread out on workbenches, lamps half-rebuilt, everything.  It was like electrification had hit one day during lunch-hour.
>
>                                 -Bill
>


-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave T?ht CEO, TekLibre, LLC

From Tyler at tgconrad.com  Tue Apr  4 16:03:47 2023
From: Tyler at tgconrad.com (Tyler Conrad)
Date: Tue, 4 Apr 2023 09:03:47 -0700
Subject: 100G-LR1 (DR/FR)
In-Reply-To: <alpine.DEB.2.20.2304041748320.2636@uplift.swm.pp.se>
References: <2946A06F-B335-4997-B78C-0D795DEEBFF8@puck.nether.net>
 <CAK-XZrJzLV4GMaa7z6vRcujbqh=fQwQQRhQ7Twitk=kcbjLD=A@mail.gmail.com>
 <56EE0B27-C5B0-443B-AB49-50E6BEDEF5E8@puck.nether.net>
 <alpine.DEB.2.20.2304041748320.2636@uplift.swm.pp.se>
Message-ID: <CA+2=Zx8t6wXFkj=2=VqTSewQod-CerVoQaT0ep821sCK+3Y4Rg@mail.gmail.com>

Tangentially related to xR1, have any of you started deploying SN
connectors on your 400G head-ends? It looks like a pretty clever
technology, adding discrete connectors per lane, but curious what the
adoption has been thus far.

On Tue, Apr 4, 2023 at 8:55?AM Mikael Abrahamsson via NANOG <nanog at nanog.org>
wrote:

> On Tue, 4 Apr 2023, Jared Mauch wrote:
>
> > We are willing to do 100G-LR1 if someone asks these days.  It lets us be
> > able to roll it up into 400G optics on our side as appropriate.
>
> I hope the industry moves to 100G-LR1, as doing 2x100GBASE-LR4 in a 400G
> port is quite meh when it comes to faceplate capacity.
>
> Unfortunately 100GBASE-LR4 will be with us for a long long time.
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/2a1a96f7/attachment.html>

From davidbass570 at gmail.com  Tue Apr  4 16:39:26 2023
From: davidbass570 at gmail.com (David Bass)
Date: Tue, 4 Apr 2023 12:39:26 -0400
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <761501209.605.1680612295892.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <929328215.303.1680526028089.JavaMail.mhammett@Thunderfuck2>
 <d3ba772ea6ea47269bb4c03c708176ec@ox.com>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
 <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
 <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>
 <631619927.25505.1680556805228.JavaMail.zimbra@ics-il.net>
 <CAJ7C-Op=8c6DeB7J0AA-rsbuu2jyxkJPE6crEPyzB2DcwmfLdw@mail.gmail.com>
 <761501209.605.1680612295892.JavaMail.mhammett@Thunderfuck2>
Message-ID: <CAJ7C-Oq7_yUHcjXn4RWFU6uX+pvYJHaKxm3BJOJLFJp0zNKAAg@mail.gmail.com>

If you are both connected to the same upstream, but the customer wants
traffic destined to the upstream to go through you (in and out), then they
need to do something on their devices to try and affect the inbound path to
their AS. From the upstream carrier in question they?ll take the best path
to a prefix, which direct connection is generally going to be preferred
over a transit AS (basic BGP best path algorithm stuff) unless there is
some manipulation of the prefix advertisement happening.

To confirm the path being taken you should be able to do a few trace routes
from various locations as well as use looking glasses.

Now the sflow data is an entirely different thing to analyze.

On Tue, Apr 4, 2023 at 7:45 AM Mike Hammett <nanog at ics-il.net> wrote:

>
> sh ip bgp neighbor advertised-routes shows the only routes being
> advertised to Y are the routes that should be advertised to them. I checked
> a variety of other peers and have the expected results.
>
>
>
> From my perspective:
>
> Packets come in on port A, supposed to leave on port X, but they leave on
> port Y. All of the troubleshooting steps I've done on my own (or suggested
> by mailing lists) say the packets should be leaving on the desired port X.
>
>
> From the customer's perspective, they're supposed to be coming from me on
> port X, but they're arriving on port Y, another network.
>
> Port X in both scenarios is our direct connection, while port Y is a
> mutual upstream provider.
>
>
> Without knowing more about the specific platform, it seems to me like a
> bug in the platform. If all indicators (not just configurations, but show
> commands as well) say the packet should be leaving on X and it leaves on Y,
> then I'm not sure what else it could be, besides a bug.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ------------------------------
> *From: *"David Bass" <davidbass570 at gmail.com>
> *To: *"Mike Hammett" <nanog at ics-il.net>
> *Cc: *"Matthew Huff" <mhuff at ox.com>, "NANOG" <nanog at nanog.org>
> *Sent: *Monday, April 3, 2023 9:12:52 PM
>
> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> You said that they are seeing traffic from another upstream?are you
> advertising the prefix to them?  Are you advertising their prefix to your
> upstream?
>
> Looks like the route maps are involved in some dual redistribution?might
> want to make sure everything is matching correctly, and being advertised
> like you want.
>
> On Mon, Apr 3, 2023 at 4:20 PM Mike Hammett <nanog at ics-il.net> wrote:
>
>> I don't see any route-maps applied to interfaces, so there must not be
>> any PBR going on. I only see ACLs, setting communities, setting local pref,
>> etc. in the route maps that are applied to neighbors.
>>
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> ------------------------------
>> *From: *"Mike Hammett" <nanog at ics-il.net>
>> *To: *"Matthew Huff" <mhuff at ox.com>
>> *Cc: *"NANOG" <nanog at nanog.org>
>> *Sent: *Monday, April 3, 2023 8:26:30 AM
>>
>> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>
>> Only two VRFs, default and manangement. IIRC, everything I saw before
>> mentioned the default VRF.
>>
>> I do see a ton of route-maps. It's mostly Greek to me, so I'll have to
>> dig through this a bit to see what's going on.
>>
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> ------------------------------
>> *From: *"Matthew Huff" <mhuff at ox.com>
>> *To: *"Mike Hammett" <nanog at ics-il.net>
>> *Cc: *"NANOG" <nanog at nanog.org>
>> *Sent: *Monday, April 3, 2023 8:06:51 AM
>> *Subject: *RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>
>> What about VRFs and/or policy based routing?
>>
>> switch-core1# show vrf
>> VRF-Name                           VRF-ID State   Reason
>>
>> default                                 1 Up      --
>>
>> management                              2 Up      --
>>
>>
>> switch-core1# show route-map
>> route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10
>>   Match clauses:
>>     interface: Ethernet1/33
>>     route-type: internal
>>   Set clauses:
>>     metric 40000000 10 255 1 1500
>> route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20
>>   Match clauses:
>>     interface: Ethernet1/34
>>     route-type: internal
>>   Set clauses:
>>     metric 40000000 30 255 1 1500
>> route-map rmap_static_to_eigrp, permit, sequence 10
>>   Match clauses:
>>     ip address prefix-lists: prefix_static_to_eigrp
>>   Set clauses:
>> route-map rmap_static_to_eigrp_v6, permit, sequence 10
>>   Match clauses:
>>     ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp
>>   Set clauses:
>>
>>
>>
>> From: Mike Hammett <nanog at ics-il.net>
>> Sent: Monday, April 3, 2023 9:00 AM
>> To: Matthew Huff <mhuff at ox.com>
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>
>> It could be an sFlow bug, but I come at this from a reported problem and
>> gathering data on that problem as opposed to looking at data for problems.
>>
>> The snmp if index reported by the Nexus matches the if index in
>> ElastiFlow.
>>
>>
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> ________________________________________
>> From: "Matthew Huff" <mailto:mhuff at ox.com>
>> To: "Mike Hammett" <mailto:nanog at ics-il.net>
>> Cc: "NANOG" <mailto:nanog at nanog.org>
>> Sent: Monday, April 3, 2023 7:50:08 AM
>> Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>> SFlow misconfiguration or bug on either the nexus or the sflow monitor?
>> On the monitor, can you verify that the snmp interfaces are mapped to the
>> correct ones on the nexus?
>>
>>
>>
>>
>>
>> From: Mike Hammett <mailto:nanog at ics-il.net>
>> Sent: Monday, April 3, 2023 8:47 AM
>> To: Matthew Huff <mailto:mhuff at ox.com>
>> Cc: NANOG <mailto:nanog at nanog.org>
>> Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>
>> It shows the desired result.
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> ________________________________________
>> From: "Matthew Huff" <mailto:mhuff at ox.com>
>> To: "Mike Hammett" <mailto:nanog at ics-il.net>, "NANOG" <mailto:
>> nanog at nanog.org>
>> Sent: Monday, April 3, 2023 5:38:23 AM
>> Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>
>> switch-core1# sh forwarding route x.x.x.x
>>
>> slot  1
>> =======
>>
>>
>> IPv4 routes for table default/base
>>
>>
>> ------------------+-----------------------------------------+----------------------+-----------------+-----------------
>> Prefix            | Next-hop                                | Interface
>>          | Labels          | Partial Install
>>
>> ------------------+-----------------------------------------+----------------------+-----------------+-----------------
>> x.x.x.x/24      x.x.x.250                            Ethernet1/29
>>
>>
>> switch-core1# show routing hash x.x.x.x y.y.y.y
>> Load-share parameters used for software forwarding:
>> load-share mode: address source-destination port source-destination
>> Hash for VRF "default"
>> Hashing to path *y.y.y.y Eth1/29
>> For route:
>> y.y.y.0/24, ubest/mbest: 1/0
>>     *via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal
>>
>>
>>
>>
>> From: NANOG <mailto:nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of
>> Mike Hammett
>> Sent: Monday, April 3, 2023 1:21 AM
>> To: NANOG <mailto:nanog at nanog.org>
>> Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>
>> We have a Nexus 3064 that is setup with partial BGP tables and is routing
>> based on that.
>>
>>
>> I've done a show ip bgp for an IP of interest and it has an expected next
>> hop IP. I show ip arp on that next hop IP and it has the expected
>> interface.
>>
>>
>> However, sFlows show the packets leaving on a different interface, the
>> one that would carry the default route for routes not otherwise known.
>>
>>
>> If the next hop IP is expected and the ARP of that next hop IP is
>> expected, why are packets leaving out an unexpected interface?
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/62b3cd1e/attachment.html>

From nanog at ics-il.net  Tue Apr  4 16:46:33 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 4 Apr 2023 11:46:33 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <CAJ7C-Oq7_yUHcjXn4RWFU6uX+pvYJHaKxm3BJOJLFJp0zNKAAg@mail.gmail.com>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
 <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
 <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>
 <631619927.25505.1680556805228.JavaMail.zimbra@ics-il.net>
 <CAJ7C-Op=8c6DeB7J0AA-rsbuu2jyxkJPE6crEPyzB2DcwmfLdw@mail.gmail.com>
 <761501209.605.1680612295892.JavaMail.mhammett@Thunderfuck2>
 <CAJ7C-Oq7_yUHcjXn4RWFU6uX+pvYJHaKxm3BJOJLFJp0zNKAAg@mail.gmail.com>
Message-ID: <815206146.874.1680626788549.JavaMail.mhammett@Thunderfuck2>

Via all mechanisms I could find in the router, it thinks the best path is the direct path, the packets just don't go that way. 


The in traffic isn't a concern at this time, just the out (from my perspective). 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "David Bass" <davidbass570 at gmail.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "Matthew Huff" <mhuff at ox.com>, "NANOG" <nanog at nanog.org> 
Sent: Tuesday, April 4, 2023 11:39:26 AM 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 


If you are both connected to the same upstream, but the customer wants traffic destined to the upstream to go through you (in and out), then they need to do something on their devices to try and affect the inbound path to their AS. From the upstream carrier in question they?ll take the best path to a prefix, which direct connection is generally going to be preferred over a transit AS (basic BGP best path algorithm stuff) unless there is some manipulation of the prefix advertisement happening. 


To confirm the path being taken you should be able to do a few trace routes from various locations as well as use looking glasses. 


Now the sflow data is an entirely different thing to analyze. 



On Tue, Apr 4, 2023 at 7:45 AM Mike Hammett < nanog at ics-il.net > wrote: 









sh ip bgp neighbor advertised-routes shows the only routes being advertised to Y are the routes that should be advertised to them. I checked a variety of other peers and have the expected results. 






>From my perspective: 


Packets come in on port A, supposed to leave on port X, but they leave on port Y. All of the troubleshooting steps I've done on my own (or suggested by mailing lists) say the packets should be leaving on the desired port X. 




>From the customer's perspective, they're supposed to be coming from me on port X, but they're arriving on port Y, another network . 


Port X in both scenarios is our direct connection, while port Y is a mutual upstream provider. 




Without knowing more about the specific platform, it seems to me like a bug in the platform. If all indicators (not just configurations, but show commands as well) say the packet should be leaving on X and it leaves on Y, then I'm not sure what else it could be, besides a bug. 





----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "David Bass" < davidbass570 at gmail.com > 
To: "Mike Hammett" < nanog at ics-il.net > 
Cc: "Matthew Huff" < mhuff at ox.com >, "NANOG" < nanog at nanog.org > 
Sent: Monday, April 3, 2023 9:12:52 PM 




Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 


You said that they are seeing traffic from another upstream?are you advertising the prefix to them? Are you advertising their prefix to your upstream? 


Looks like the route maps are involved in some dual redistribution?might want to make sure everything is matching correctly, and being advertised like you want. 



On Mon, Apr 3, 2023 at 4:20 PM Mike Hammett < nanog at ics-il.net > wrote: 

<blockquote>



I don't see any route-maps applied to interfaces, so there must not be any PBR going on. I only see ACLs, setting communities, setting local pref, etc. in the route maps that are applied to neighbors. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Mike Hammett" < nanog at ics-il.net > 
To: "Matthew Huff" < mhuff at ox.com > 
Cc: "NANOG" < nanog at nanog.org > 
Sent: Monday, April 3, 2023 8:26:30 AM 



Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 




Only two VRFs, default and manangement. IIRC, everything I saw before mentioned the default VRF. 

I do see a ton of route-maps. It's mostly Greek to me, so I'll have to dig through this a bit to see what's going on. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Matthew Huff" < mhuff at ox.com > 
To: "Mike Hammett" < nanog at ics-il.net > 
Cc: "NANOG" < nanog at nanog.org > 
Sent: Monday, April 3, 2023 8:06:51 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

What about VRFs and/or policy based routing? 

switch-core1# show vrf 
VRF-Name VRF-ID State Reason 
default 1 Up -- 
management 2 Up -- 

switch-core1# show route-map 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10 
Match clauses: 
interface: Ethernet1/33 
route-type: internal 
Set clauses: 
metric 40000000 10 255 1 1500 
route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20 
Match clauses: 
interface: Ethernet1/34 
route-type: internal 
Set clauses: 
metric 40000000 30 255 1 1500 
route-map rmap_static_to_eigrp, permit, sequence 10 
Match clauses: 
ip address prefix-lists: prefix_static_to_eigrp 
Set clauses: 
route-map rmap_static_to_eigrp_v6, permit, sequence 10 
Match clauses: 
ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp 
Set clauses: 



From: Mike Hammett < nanog at ics-il.net > 
Sent: Monday, April 3, 2023 9:00 AM 
To: Matthew Huff < mhuff at ox.com > 
Cc: NANOG < nanog at nanog.org > 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It could be an sFlow bug, but I come at this from a reported problem and gathering data on that problem as opposed to looking at data for problems. 

The snmp if index reported by the Nexus matches the if index in ElastiFlow. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto: mhuff at ox.com > 
To: "Mike Hammett" <mailto: nanog at ics-il.net > 
Cc: "NANOG" <mailto: nanog at nanog.org > 
Sent: Monday, April 3, 2023 7:50:08 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 
SFlow misconfiguration or bug on either the nexus or the sflow monitor? On the monitor, can you verify that the snmp interfaces are mapped to the correct ones on the nexus? 





From: Mike Hammett <mailto: nanog at ics-il.net > 
Sent: Monday, April 3, 2023 8:47 AM 
To: Matthew Huff <mailto: mhuff at ox.com > 
Cc: NANOG <mailto: nanog at nanog.org > 
Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

It shows the desired result. 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

________________________________________ 
From: "Matthew Huff" <mailto: mhuff at ox.com > 
To: "Mike Hammett" <mailto: nanog at ics-il.net >, "NANOG" <mailto: nanog at nanog.org > 
Sent: Monday, April 3, 2023 5:38:23 AM 
Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

switch-core1# sh forwarding route x.x.x.x 

slot 1 
======= 


IPv4 routes for table default/base 

------------------+-----------------------------------------+----------------------+-----------------+----------------- 
Prefix | Next-hop | Interface | Labels | Partial Install 
------------------+-----------------------------------------+----------------------+-----------------+----------------- 
x.x.x.x/24 x.x.x.250 Ethernet1/29 


switch-core1# show routing hash x.x.x.x y.y.y.y 
Load-share parameters used for software forwarding: 
load-share mode: address source-destination port source-destination 
Hash for VRF "default" 
Hashing to path *y.y.y.y Eth1/29 
For route: 
y.y.y.0/24, ubest/mbest: 1/0 
*via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal 




From: NANOG <mailto: nanog-bounces+mhuff = ox.com at nanog.org > On Behalf Of Mike Hammett 
Sent: Monday, April 3, 2023 1:21 AM 
To: NANOG <mailto: nanog at nanog.org > 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 

We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 







</blockquote>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/421e5045/attachment.html>

From nick at 141networks.com  Tue Apr  4 22:01:12 2023
From: nick at 141networks.com (Nick Olsen)
Date: Tue, 4 Apr 2023 23:01:12 +0100
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <815206146.874.1680626788549.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
 <1449551141.352.1680526788034.JavaMail.mhammett@Thunderfuck2>
 <494acdaf5b9e4d3a9d5706ad5c5ea05f@ox.com>
 <517858062.383.1680528390235.JavaMail.mhammett@Thunderfuck2>
 <631619927.25505.1680556805228.JavaMail.zimbra@ics-il.net>
 <CAJ7C-Op=8c6DeB7J0AA-rsbuu2jyxkJPE6crEPyzB2DcwmfLdw@mail.gmail.com>
 <761501209.605.1680612295892.JavaMail.mhammett@Thunderfuck2>
 <CAJ7C-Oq7_yUHcjXn4RWFU6uX+pvYJHaKxm3BJOJLFJp0zNKAAg@mail.gmail.com>
 <815206146.874.1680626788549.JavaMail.mhammett@Thunderfuck2>
Message-ID: <CAPr_aJbdtrwLJgAVwZXjSsYKVjKNseEt83SjVBFMhcjdX1hzyQ@mail.gmail.com>

Not that it's a "Fix" but have you tried rebooting the box? If this is a
bug in the forwarding plane that might clear/rebuild it. And maybe it works
correctly after that.

Friend saw something similar on a Juniper MX with DPC cards that had run
out of FIB space. It would show correctly in all places, but was failing to
install in FIB (Router cut a error about it in the log). So the actual
traffic didn't follow the same path. I saw you specifically referenced
"forwarding" in one of your copy pastes. And it looked right. But I don't
know enough about Cisco to say if that's really what is in FIB. Or just
what it thinks is in FIB.

On Tue, Apr 4, 2023 at 5:47?PM Mike Hammett <nanog at ics-il.net> wrote:

> Via all mechanisms I could find in the router, it thinks the best path is
> the direct path, the packets just don't go that way.
>
> The in traffic isn't a concern at this time, just the out (from my
> perspective).
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ------------------------------
> *From: *"David Bass" <davidbass570 at gmail.com>
> *To: *"Mike Hammett" <nanog at ics-il.net>
> *Cc: *"Matthew Huff" <mhuff at ox.com>, "NANOG" <nanog at nanog.org>
> *Sent: *Tuesday, April 4, 2023 11:39:26 AM
> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>
> If you are both connected to the same upstream, but the customer wants
> traffic destined to the upstream to go through you (in and out), then they
> need to do something on their devices to try and affect the inbound path to
> their AS. From the upstream carrier in question they?ll take the best path
> to a prefix, which direct connection is generally going to be preferred
> over a transit AS (basic BGP best path algorithm stuff) unless there is
> some manipulation of the prefix advertisement happening.
>
> To confirm the path being taken you should be able to do a few trace
> routes from various locations as well as use looking glasses.
>
> Now the sflow data is an entirely different thing to analyze.
>
> On Tue, Apr 4, 2023 at 7:45 AM Mike Hammett <nanog at ics-il.net> wrote:
>
>>
>> sh ip bgp neighbor advertised-routes shows the only routes being
>> advertised to Y are the routes that should be advertised to them. I checked
>> a variety of other peers and have the expected results.
>>
>>
>>
>> From my perspective:
>>
>> Packets come in on port A, supposed to leave on port X, but they leave on
>> port Y. All of the troubleshooting steps I've done on my own (or suggested
>> by mailing lists) say the packets should be leaving on the desired port X.
>>
>>
>> From the customer's perspective, they're supposed to be coming from me on
>> port X, but they're arriving on port Y, another network.
>>
>> Port X in both scenarios is our direct connection, while port Y is a
>> mutual upstream provider.
>>
>>
>> Without knowing more about the specific platform, it seems to me like a
>> bug in the platform. If all indicators (not just configurations, but show
>> commands as well) say the packet should be leaving on X and it leaves on Y,
>> then I'm not sure what else it could be, besides a bug.
>>
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>> ------------------------------
>> *From: *"David Bass" <davidbass570 at gmail.com>
>> *To: *"Mike Hammett" <nanog at ics-il.net>
>> *Cc: *"Matthew Huff" <mhuff at ox.com>, "NANOG" <nanog at nanog.org>
>> *Sent: *Monday, April 3, 2023 9:12:52 PM
>>
>> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>
>> You said that they are seeing traffic from another upstream?are you
>> advertising the prefix to them?  Are you advertising their prefix to your
>> upstream?
>>
>> Looks like the route maps are involved in some dual redistribution?might
>> want to make sure everything is matching correctly, and being advertised
>> like you want.
>>
>> On Mon, Apr 3, 2023 at 4:20 PM Mike Hammett <nanog at ics-il.net> wrote:
>>
>>> I don't see any route-maps applied to interfaces, so there must not be
>>> any PBR going on. I only see ACLs, setting communities, setting local pref,
>>> etc. in the route maps that are applied to neighbors.
>>>
>>>
>>>
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>>
>>> ------------------------------
>>> *From: *"Mike Hammett" <nanog at ics-il.net>
>>> *To: *"Matthew Huff" <mhuff at ox.com>
>>> *Cc: *"NANOG" <nanog at nanog.org>
>>> *Sent: *Monday, April 3, 2023 8:26:30 AM
>>>
>>> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding
>>> Debugging
>>>
>>> Only two VRFs, default and manangement. IIRC, everything I saw before
>>> mentioned the default VRF.
>>>
>>> I do see a ton of route-maps. It's mostly Greek to me, so I'll have to
>>> dig through this a bit to see what's going on.
>>>
>>>
>>>
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>>
>>> ------------------------------
>>> *From: *"Matthew Huff" <mhuff at ox.com>
>>> *To: *"Mike Hammett" <nanog at ics-il.net>
>>> *Cc: *"NANOG" <nanog at nanog.org>
>>> *Sent: *Monday, April 3, 2023 8:06:51 AM
>>> *Subject: *RE: Cisco Nexus 3k Route Selection\Packet Forwarding
>>> Debugging
>>>
>>> What about VRFs and/or policy based routing?
>>>
>>> switch-core1# show vrf
>>> VRF-Name                           VRF-ID State   Reason
>>>
>>> default                                 1 Up      --
>>>
>>> management                              2 Up      --
>>>
>>>
>>> switch-core1# show route-map
>>> route-map rmap_bgp_to_eigrp_b2b, permit, sequence 10
>>>   Match clauses:
>>>     interface: Ethernet1/33
>>>     route-type: internal
>>>   Set clauses:
>>>     metric 40000000 10 255 1 1500
>>> route-map rmap_bgp_to_eigrp_b2b, permit, sequence 20
>>>   Match clauses:
>>>     interface: Ethernet1/34
>>>     route-type: internal
>>>   Set clauses:
>>>     metric 40000000 30 255 1 1500
>>> route-map rmap_static_to_eigrp, permit, sequence 10
>>>   Match clauses:
>>>     ip address prefix-lists: prefix_static_to_eigrp
>>>   Set clauses:
>>> route-map rmap_static_to_eigrp_v6, permit, sequence 10
>>>   Match clauses:
>>>     ipv6 address prefix-lists: prefix_ipv6_static_to_eigrp
>>>   Set clauses:
>>>
>>>
>>>
>>> From: Mike Hammett <nanog at ics-il.net>
>>> Sent: Monday, April 3, 2023 9:00 AM
>>> To: Matthew Huff <mhuff at ox.com>
>>> Cc: NANOG <nanog at nanog.org>
>>> Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>>
>>> It could be an sFlow bug, but I come at this from a reported problem and
>>> gathering data on that problem as opposed to looking at data for problems.
>>>
>>> The snmp if index reported by the Nexus matches the if index in
>>> ElastiFlow.
>>>
>>>
>>>
>>>
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>>
>>> ________________________________________
>>> From: "Matthew Huff" <mailto:mhuff at ox.com>
>>> To: "Mike Hammett" <mailto:nanog at ics-il.net>
>>> Cc: "NANOG" <mailto:nanog at nanog.org>
>>> Sent: Monday, April 3, 2023 7:50:08 AM
>>> Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>> SFlow misconfiguration or bug on either the nexus or the sflow monitor?
>>> On the monitor, can you verify that the snmp interfaces are mapped to the
>>> correct ones on the nexus?
>>>
>>>
>>>
>>>
>>>
>>> From: Mike Hammett <mailto:nanog at ics-il.net>
>>> Sent: Monday, April 3, 2023 8:47 AM
>>> To: Matthew Huff <mailto:mhuff at ox.com>
>>> Cc: NANOG <mailto:nanog at nanog.org>
>>> Subject: Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>>
>>> It shows the desired result.
>>>
>>>
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>>
>>> ________________________________________
>>> From: "Matthew Huff" <mailto:mhuff at ox.com>
>>> To: "Mike Hammett" <mailto:nanog at ics-il.net>, "NANOG" <mailto:
>>> nanog at nanog.org>
>>> Sent: Monday, April 3, 2023 5:38:23 AM
>>> Subject: RE: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>>
>>> switch-core1# sh forwarding route x.x.x.x
>>>
>>> slot  1
>>> =======
>>>
>>>
>>> IPv4 routes for table default/base
>>>
>>>
>>> ------------------+-----------------------------------------+----------------------+-----------------+-----------------
>>> Prefix            | Next-hop                                | Interface
>>>            | Labels          | Partial Install
>>>
>>> ------------------+-----------------------------------------+----------------------+-----------------+-----------------
>>> x.x.x.x/24      x.x.x.250                            Ethernet1/29
>>>
>>>
>>> switch-core1# show routing hash x.x.x.x y.y.y.y
>>> Load-share parameters used for software forwarding:
>>> load-share mode: address source-destination port source-destination
>>> Hash for VRF "default"
>>> Hashing to path *y.y.y.y Eth1/29
>>> For route:
>>> y.y.y.0/24, ubest/mbest: 1/0
>>>     *via z.z.z.z, Eth1/29, [90/3072], 1w2d, eigrp-100, internal
>>>
>>>
>>>
>>>
>>> From: NANOG <mailto:nanog-bounces+mhuff=ox.com at nanog.org> On Behalf Of
>>> Mike Hammett
>>> Sent: Monday, April 3, 2023 1:21 AM
>>> To: NANOG <mailto:nanog at nanog.org>
>>> Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
>>>
>>> We have a Nexus 3064 that is setup with partial BGP tables and is
>>> routing based on that.
>>>
>>>
>>> I've done a show ip bgp for an IP of interest and it has an expected
>>> next hop IP. I show ip arp on that next hop IP and it has the expected
>>> interface.
>>>
>>>
>>> However, sFlows show the packets leaving on a different interface, the
>>> one that would carry the default route for routes not otherwise known.
>>>
>>>
>>> If the next hop IP is expected and the ARP of that next hop IP is
>>> expected, why are packets leaving out an unexpected interface?
>>>
>>>
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230404/5e080084/attachment.html>

From rbonica at juniper.net  Wed Apr  5 16:24:22 2023
From: rbonica at juniper.net (Ron Bonica)
Date: Wed, 5 Apr 2023 16:24:22 +0000
Subject: Route Hijacks
Message-ID: <BL0PR05MB53162ECFB0529F9E15E42FCEAE909@BL0PR05MB5316.namprd05.prod.outlook.com>

Folks,

Can anyone point me at literature regarding the frequency and cost of BGP route hijacks?

Also, please email me privately if there is any information that you can share in confidence.

                                                                                 Ron



Juniper Business Use Only
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230405/c1730268/attachment.html>

From news at nanog.org  Thu Apr  6 19:25:55 2023
From: news at nanog.org (Nanog News)
Date: Thu, 6 Apr 2023 15:25:55 -0400
Subject: Early Bird Reg. Rates End Sunday + Start Your Seattle Coffee Tour Here
Message-ID: <CAHf5Ly14+NtP2=+9Vw4Aa5kwQ5eJdVDZPRNNJdwC=6VzyrYjqw@mail.gmail.com>

*NANOG 88 Early Bird Registration Deadline Sunday *
*Discounted Rates Will End this Sunday 9 April*

Join us for our 88th community-wide meeting, NANOG 88, taking place 12 -
14, June in Seattle, Wa.

Register before Sunday, 9 April to receive our most discounted registration
rate.

*REGISTER NOW * <https://www.nanog.org/events/nanog-88/register/>

*Start Your Seattle Coffee Tour Here*
*Your Guide to the "Coffee Capital" of the U.S.*

Coffee is like a fine wine, "the best cup" can only be determined by the
person whose pallet it touches.

Check out this curated list of legendary cafes in the coffee capital of the
United States. Then plan your hunt for the best cup of coffee during your
stay in the Emerald City for our upcoming meeting, NANOG 88.

*READ NOW  <https://nanog.org/stories/start-your-seattle-coffee-tour-here/>*

*Don't Wait to Submit Your Presentation  for N88!*
*Presentation Submission Deadline is Monday, 24 April*

The NANOG PC is looking to schedule over 1,600 minutes of content between
General Session and Breakout Rooms for NANOG 88 - so don?t wait!

Presentation abstracts and draft slides should be submitted before Monday,
24 April.

*MORE INFO * <https://www.nanog.org/program/call-presentations/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230406/44ae06ff/attachment.html>

From tim at mid.net  Fri Apr  7 00:32:41 2023
From: tim at mid.net (Tim Burke)
Date: Fri, 7 Apr 2023 00:32:41 +0000
Subject: Auth0 geolocation?
Message-ID: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>

Anyone know who Auth0 is using for geolocation services? Have a customer reporting that Auth0, Lowes, Bank of America, and some other sites are reporting their IP in the wrong location. Checked the usual suspects, BrothersWISP.com<http://BrothersWISP.com> geolocation providers list, etcetera and they?re all showing in the correct location.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230407/0aae9336/attachment.html>

From tim at mid.net  Fri Apr  7 13:46:07 2023
From: tim at mid.net (Tim Burke)
Date: Fri, 7 Apr 2023 13:46:07 +0000
Subject: Auth0 geolocation?
Message-ID: <9C3A1173-5902-4DA7-BA9F-452E371D0499@mid.net>

?I thought so too, but we already send good geofeed data to Maxmind, and queried their DB to verify.

On Apr 7, 2023, at 8:16 AM, Joel Esler <joel at joelesler.net> wrote:

? I bet money it?s maxmind.

?
Sent from my iPhone

On Apr 6, 2023, at 20:33, Tim Burke <tim at mid.net> wrote:

? Anyone know who Auth0 is using for geolocation services? Have a customer reporting that Auth0, Lowes, Bank of America, and some other sites are reporting their IP in the wrong location. Checked the usual suspects, BrothersWISP.com<http://BrothersWISP.com> geolocation providers list, etcetera and they?re all showing in the correct location.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230407/1f45c2f5/attachment.html>

From cb.list6 at gmail.com  Fri Apr  7 14:05:23 2023
From: cb.list6 at gmail.com (Ca By)
Date: Fri, 7 Apr 2023 07:05:23 -0700
Subject: Auth0 geolocation?
In-Reply-To: <9C3A1173-5902-4DA7-BA9F-452E371D0499@mid.net>
References: <9C3A1173-5902-4DA7-BA9F-452E371D0499@mid.net>
Message-ID: <CAD6AjGRCQn1jJX8rVam6D=LKc1rc7G0+j54=f+SELABjd3NGTQ@mail.gmail.com>

On Fri, Apr 7, 2023 at 6:47 AM Tim Burke <tim at mid.net> wrote:

> ?I thought so too, but we already send good geofeed data to Maxmind, and
> queried their DB to verify.
>

The worst of the worst is brightcloud / opentext

They randomly assigned my arin ip space to china 2 weeks ago

This space has

1. Not changed in any way and been with me from arin for 10 years

2. Has a proper geofeed

And i opened a ticket with brghtcloud / opentext, they agreed to fix ? a
week later not fix? i followed up? they said still working on it ?.

Geolocation companies are bad for QA, but brightcloud takes the cake for
bizarrely moving my arin space to China and then acknowledging and not
fixing.



> On Apr 7, 2023, at 8:16 AM, Joel Esler <joel at joelesler.net> wrote:
>
> ? I bet money it?s maxmind.
>
> ?
> Sent from my iPhone
>
> On Apr 6, 2023, at 20:33, Tim Burke <tim at mid.net> wrote:
>
> ? Anyone know who Auth0 is using for geolocation services? Have a customer
> reporting that Auth0, Lowes, Bank of America, and some other sites are
> reporting their IP in the wrong location. Checked the usual suspects,
> BrothersWISP.com geolocation providers list, etcetera and they?re all
> showing in the correct location.
>
> Thanks,
> Tim
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230407/4dfbc2b3/attachment.html>

From cscora at apnic.net  Fri Apr  7 18:03:36 2023
From: cscora at apnic.net (Routing Table Analysis Role Account)
Date: Sat, 8 Apr 2023 04:03:36 +1000 (AEST)
Subject: Weekly Global IPv4 Routing Table Report
Message-ID: <20230407180336.A8611C0F45@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the 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 bgp-stats at lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

IPv4 Routing Table Report   04:00 +10GMT Sat 08 Apr, 2023

  BGP Table (Global) as seen in Japan.

Report Website:     https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              917911
    Prefixes after maximum aggregation (per Origin AS):          348250
    Deaggregation factor:                                          2.64
    Unique aggregates announced (without unneeded subnets):      447962
Total ASes present in the Internet Routing Table:                 74298
    Prefixes per ASN:                                             12.35
Origin-only ASes present in the Internet Routing Table:           63737
Origin ASes announcing only one prefix:                           26192
Transit ASes present in the Internet Routing Table:               10561
Transit-only ASes present in the Internet Routing Table:            448
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      55
    Max AS path prepend of ASN (265020)                              50
Prefixes from unregistered ASNs in the Routing Table:              1103
    Number of instances of unregistered ASNs:                      1103
Number of 32-bit ASNs allocated by the RIRs:                      41624
Number of 32-bit ASNs visible in the Routing Table:               34433
Prefixes from 32-bit ASNs in the Routing Table:                  169845
Number of bogon 32-bit ASNs visible in the Routing Table:            56
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            713
Number of addresses announced to Internet:                   3062021376
    Equivalent to 182 /8s, 130 /16s and 189 /24s
    Percentage of available address space announced:               82.7
    Percentage of allocated address space announced:               82.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               99.6
Total number of prefixes smaller than registry allocations:      307012

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   242441
    Total APNIC prefixes after maximum aggregation:               69292
    APNIC Deaggregation factor:                                    3.50
Prefixes being announced from the APNIC address blocks:          236823
    Unique aggregates announced from the APNIC address blocks:    97741
APNIC Region origin ASes present in the Internet Routing Table:   13397
    APNIC Prefixes per ASN:                                       17.68
APNIC Region origin ASes announcing only one prefix:               3937
APNIC Region transit ASes present in the Internet Routing Table:   1808
Average APNIC Region AS path length visible:                        4.4
    Max APNIC Region AS path length visible:                         26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8686
Number of APNIC addresses announced to Internet:              773675648
    Equivalent to 46 /8s, 29 /16s and 90 /24s
APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    268778
    Total ARIN prefixes after maximum aggregation:               122061
    ARIN Deaggregation factor:                                     2.20
Prefixes being announced from the ARIN address blocks:           271173
    Unique aggregates announced from the ARIN address blocks:    130691
ARIN Region origin ASes present in the Internet Routing Table:    19085
    ARIN Prefixes per ASN:                                        14.21
ARIN Region origin ASes announcing only one prefix:                6975
ARIN Region transit ASes present in the Internet Routing Table:    1959
Average ARIN Region AS path length visible:                         3.7
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:    4781
Number of ARIN addresses announced to Internet:              1285572096
    Equivalent to 76 /8s, 160 /16s and 70 /24s
ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-401308
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  47/8,  48/8,  50/8,  52/8,  53/8,
                        54/8,  55/8,  56/8,  57/8,  63/8,  64/8,  65/8,
                        66/8,  67/8,  68/8,  69/8,  70/8,  71/8,  72/8,
                        73/8,  74/8,  75/8,  76/8,  96/8,  97/8,  98/8,
                        99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8,
                       130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8,
                       138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8,
                       147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8,
                       158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8,
                       166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8,
                       174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8,
                       206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8,
                      

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    258784
    Total RIPE prefixes after maximum aggregation:               121878
    RIPE Deaggregation factor:                                     2.12
Prefixes being announced from the RIPE address blocks:           254754
    Unique aggregates announced from the RIPE address blocks:    157516
RIPE Region origin ASes present in the Internet Routing Table:    28287
    RIPE Prefixes per ASN:                                         9.01
RIPE Region origin ASes announcing only one prefix:               12034
RIPE Region transit ASes present in the Internet Routing Table:    3968
Average RIPE Region AS path length visible:                         4.3
    Max RIPE Region AS path length visible:                          31
Number of RIPE region 32-bit ASNs visible in the Routing Table:   11116
Number of RIPE addresses announced to Internet:               717837184
    Equivalent to 42 /8s, 201 /16s and 83 /24s
RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 64396-64495
                       196608-213403
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                  117557
    Total LACNIC prefixes after maximum aggregation:              28483
    LACNIC Deaggregation factor:                                   4.13
Prefixes being announced from the LACNIC address blocks:         116872
    Unique aggregates announced from the LACNIC address blocks:   49120
LACNIC Region origin ASes present in the Internet Routing Table:  10968
    LACNIC Prefixes per ASN:                                      10.66
LACNIC Region origin ASes announcing only one prefix:              2644
LACNIC Region transit ASes present in the Internet Routing Table:  2289
Average LACNIC Region AS path length visible:                       5.0
    Max LACNIC Region AS path length visible:                        55
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  8773
Number of LACNIC addresses announced to Internet:             176705536
    Equivalent to 10 /8s, 136 /16s and 80 /24s
LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-273820 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  29248
    Total AfriNIC prefixes after maximum aggregation:              5772
    AfriNIC Deaggregation factor:                                  5.07
Prefixes being announced from the AfriNIC address blocks:         37576
    Unique aggregates announced from the AfriNIC address blocks:  12283
AfriNIC Region origin ASes present in the Internet Routing Table:  1729
    AfriNIC Prefixes per ASN:                                     21.73
AfriNIC Region origin ASes announcing only one prefix:              602
AfriNIC Region transit ASes present in the Internet Routing Table:  333
Average AfriNIC Region AS path length visible:                      4.9
    Max AfriNIC Region AS path length visible:                       40
Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1077
Number of AfriNIC addresses announced to Internet:            107769344
    Equivalent to 6 /8s, 108 /16s and 110 /24s
AfriNIC AS Blocks      36864-37887, 327680-329727 & ERX transfers
AfriNIC Address Blocks  41/8,  45/8, 102/8, 105/8, 154/8, 196/8, 197/8,
                      

APNIC Region per AS prefix count summary
----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  9808        9492       8884      51  CHINAMOBILE-CN China Mobile Communicati
  7545        5744        786     689  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4865       4192      75  ERX-CERNET-BKB China Education and Rese
  7552        3563       1331      21  VIETEL-AS-AP Viettel Group, VN
  7713        3546       1043      65  TELKOMNET-AS-AP PT Telekomunikasi Indon
 45899        3383       1872      93  VNPT-AS-VN VNPT Corp, VN
  9498        2901        491     237  BBIL-AP BHARTI Airtel Ltd., IN
  4766        2555      11252     592  KIXS-AS-KR Korea Telecom, KR
 24560        2363        835     442  AIRTELBROADBAND-AS-AP Bharti Airtel Ltd
 45090        2184       1438      79  TENCENT-NET-AP Shenzhen Tencent Compute

Complete listing at https://thyme.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 16509        8269      10783    2879  AMAZON-02, US
 11492        4541        301     610  CABLEONE, US
  7155        3967        279      48  VIASAT-SP-BACKBONE, US
 22773        3608       3057     281  ASN-CXA-ALL-CCI-22773-RDC, US
  6327        3514       1320      64  SHAW, CA
 16625        3160       1589    2342  AKAMAI-AS, US
   749        3054      50541    2321  DNIC-AS-00749, US
396982        2631       3590     363  GOOGLE-CLOUD-PLATFORM, US
  7018        2565      24118    1562  ATT-INTERNET4, US
 30036        2488        359     526  MEDIACOM-ENTERPRISE-BUSINESS, US

Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 12479        7244       1705     149  UNI2-AS, ES
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 20940        4058       3399     164  AKAMAI-ASN1, NL
  8551        3885        370      37  BEZEQ-INTERNATIONAL-AS Bezeqint Interne
 12389        2954       2292     911  ROSTELECOM-AS, RU
  9009        2646        248    1379  M247, RO
 34984        2272        359     611  TELLCOM-AS, TR
  6849        2076        307      18  UKRTELNET, UA
 58224        1850        950     543  TCI, IR
 13188        1606        100      26  TRIOLAN, UA

Complete listing at https://thyme.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11211       3343     578  Uninet S.A. de C.V., MX
 10620        3499        506     850  Telmex Colombia S.A., CO
 13999        2311        370     610  Mega Cable, S.A. de C.V., MX
 11830        2264        369      64  Instituto Costarricense de Electricidad
 28573        1332       2325     235  Claro NXT Telecomunicacoes Ltda, BR
  3816        1303        767     159  COLOMBIA TELECOMUNICACIONES S.A. ESP, C
  6503        1299        339     514  Axtel, S.A.B. de C.V., MX
  6147        1131        370      22  Telefonica del Peru S.A.A., PE
 11664        1101        180     446  Techtel LMDS Comunicaciones Interactiva
 26615        1030       2498      45  TIM SA, BR

Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 24863        1576        393      19  LINKdotNET-AS, EG
 24835        1541        533      30  RAYA-AS, EG
 36992        1356       1518     275  ETISALAT-MISR, EG
 36903        1242        550      99  MT-MPLS, MA
 29571        1016         67      48  ORANGE-COTE-IVOIRE, CI
 36935         872        520      42  Vodafone-, EG
  6713         550       1861      34  IAM-AS, MA
 15399         532         54      47  WANANCHI-, KE
 37342         493         32       1  MOVITEL, MZ
 24757         488         73       5  EthioNet-AS, ET

Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11211       3343     578  Uninet S.A. de C.V., MX
  9808        9492       8884      51  CHINAMOBILE-CN China Mobile Communicati
 16509        8269      10783    2879  AMAZON-02, US
 12479        7244       1705     149  UNI2-AS, ES
  7545        5744        786     689  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4865       4192      75  ERX-CERNET-BKB China Education and Rese
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 11492        4541        301     610  CABLEONE, US
 20940        4058       3399     164  AKAMAI-ASN1, NL
  7155        3967        279      48  VIASAT-SP-BACKBONE, US

Complete listing at https://thyme.apnic.net/current/data-ASnet

Global Per AS Maximum Aggregation summary
-----------------------------------------

   ASN  No of nets  Net Savings  Description
  9808        9492         9441  CHINAMOBILE-CN China Mobile Communications Grou
 12479        7244         7095  UNI2-AS, ES
 16509        8269         5390  AMAZON-02, US
  7545        5744         5055  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4865         4790  ERX-CERNET-BKB China Education and Research Net
 39891        4833         4774  ALJAWWALSTC-AS, SA
 11492        4541         3931  CABLEONE, US
  7155        3967         3919  VIASAT-SP-BACKBONE, US
 20940        4058         3894  AKAMAI-ASN1, NL
  8551        3885         3848  BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo

Complete listing at https://thyme.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

    Bad AS  Designation  Net Originated      Transit AS  Transit AS Name
      3507  UNALLOCATED  5.105.166.0/24          213035  AS-SERVERION Serverion B.V.,
     33123  UNALLOCATED  8.10.69.0/24             11168  SCC, US
     12169  UNALLOCATED  8.15.207.0/24            32787  PROLEXIC-TECHNOLOGIES-DDOS-M
     53775  UNALLOCATED  8.20.88.0/24              7029  WINDSTREAM, US
     62828  UNALLOCATED  8.21.130.0/24             3356  LEVEL3, US
    393266  UNALLOCATED  8.23.52.0/24             46887  LIGHTOWER, US
    396894  UNALLOCATED  8.28.201.0/24            46887  LIGHTOWER, US
    394936  UNALLOCATED  8.33.224.0/24            22442  HOU-PHONOSCOPE, US
     54338  UNALLOCATED  8.33.241.0/24             6461  ZAYO-6461, US
     18798  UNALLOCATED  8.40.106.0/24             6461  ZAYO-6461, US

Complete listing at https://thyme.apnic.net/current/data-badAS

Prefixes from the Special Purpose Address Registry (Global)
-----------------------------------------------------------

Prefix                Origin AS  Description
192.88.99.0/24             6939  HURRICANE, US

Complete listing at https://thyme.apnic.net/current/data-spar

Advertised Unallocated Addresses
--------------------------------

Unassigned Network     ASN Information  AS Name
23.131.185.0/24      Origin:       174  COGENT-174, US
23.131.185.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.186.0/24      Origin:       174  COGENT-174, US
23.131.186.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.187.0/24      Origin:       174  COGENT-174, US
23.131.187.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.188.0/24      Origin:       174  COGENT-174, US
23.131.188.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.136.112.0/24      Origin:     54835  UNASSIGNED
23.136.112.0/24     Transit:     21559  OSNET, PR

Complete listing at https://thyme.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:39      /11:103     /12:299     
/13:578     /14:1198    /15:2036    /16:13471   /17:8269    /18:13858   
/19:25180   /20:44264   /21:51593   /22:109702  /23:97592   /24:548972  
/25:728     /26:0       /27:0       /28:0       /29:0       /30:0       
/31:0       /32:0       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

   ASN  No of nets  Total ann.  Description
 12479        6305        7244  UNI2-AS, ES
  8151        5175       11211  Uninet S.A. de C.V., MX
 39891        3632        4833  ALJAWWALSTC-AS, SA
 11492        3449        4541  CABLEONE, US
  8551        3357        3885  BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo
  6327        3323        3514  SHAW, CA
  7155        3039        3967  VIASAT-SP-BACKBONE, US
 22773        2675        3608  ASN-CXA-ALL-CCI-22773-RDC, US
 30036        2145        2488  MEDIACOM-ENTERPRISE-BUSINESS, US
 10620        2053        3499  Telmex Colombia S.A., CO

Complete listing at https://thyme.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1703      2:1237      3:172       4:5         5:4485      6:122    
   7:6         8:1548      9:1        11:172      12:1558     13:394    
  14:2310     15:299      16:185      17:371      18:417      20:248    
  21:4        22:188      23:6158     24:2578     25:6        27:2491   
  29:19       31:2524     32:97       34:10       35:107      36:1918   
  37:4644     38:4453     39:805      40:151      41:3959     42:987    
  43:2345     44:308      45:16542    46:4238     47:363      49:1758   
  50:1837     51:571      52:1595     54:389      55:855      56:8      
  57:90       58:1756     59:1128     60:978      61:2444     62:2648   
  63:1923     64:5689     65:2327     66:4946     67:3020     68:1375   
  69:4154     70:1255     71:671      72:2974     74:2615     75:1464   
  76:610      77:2433     78:1863     79:3163     80:2096     81:1745   
  82:1485     83:1279     84:1533     85:2992     86:747      87:2003   
  88:1240     89:3626     90:614      91:7687     92:2058     93:2616   
  94:3598     95:3996     96:1328     97:336      98:1157     99:745    
 100:73      101:1069    102:2646    103:31259   104:4640    105:483    
 106:906     107:2507    108:1022    109:4418    110:2079    111:3233   
 112:2054    113:1563    114:1640    115:2028    116:1933    117:2559   
 118:2284    119:2023    120:1798    121:1109    122:2624    123:2188   
 124:1615    125:2537    128:1312    129:1063    130:1002    131:1986   
 132:801     133:422     134:1902    135:305     136:839     137:945    
 138:2549    139:1538    140:1234    141:1458    142:1432    143:1499   
 144:1165    145:346     146:1936    147:1572    148:2345    149:2009   
 150:870     151:1155    152:1843    153:489     154:4411    155:1421   
 156:1801    157:1301    158:1054    159:2280    160:2537    161:1532   
 162:3526    163:1504    164:1592    165:1713    166:1004    167:1717   
 168:3883    169:939     170:4605    171:880     172:3536    173:2934   
 174:1072    175:1154    176:3682    177:4546    178:3628    179:2145   
 180:2410    181:3435    182:3376    183:1929    184:2353    185:20177  
 186:4678    187:3945    188:4117    189:3559    190:9158    191:1447   
 192:10923   193:8851    194:7300    195:5152    196:3085    197:2377   
 198:5966    199:6088    200:7895    201:5878    202:10672   203:10223  
 204:4623    205:3540    206:4127    207:3457    208:4103    209:4894   
 210:4433    211:2496    212:4101    213:3573    214:1083    215:59     
 216:6622    217:2681    218:1295    219:576     220:2018    221:973    
 222:890     223:2182   

End of report

From spoofer-info at caida.org  Sat Apr  8 17:00:07 2023
From: spoofer-info at caida.org (CAIDA Spoofer Project)
Date: Sat, 8 Apr 2023 10:00:07 -0700
Subject: Spoofer Report for NANOG for Mar 2023
Message-ID: <1680973207.697253.11665.nullmailer@caida.org>

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 Mar 2023:
ASN    Name                                           Fixed-By
33185  TGLO-VGLO                                      2023-03-03
54825  PACKET                                         2023-03-08
62005  AdNet-Telecom                                  2023-03-20
399445                                                2023-03-27

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Mar 2023:
ASN    Name                           First-Spoofed Last-Spoofed
6939   HURRICANE                         2016-02-22   2023-03-24
209    CENTURYLINK-US-LEGACY-QWEST       2016-08-16   2023-03-30
20412  CLARITY-TELECOM                   2016-09-30   2023-03-31
6181   FUSE-NET                          2016-10-10   2023-03-26
25787  ROWE-NETWORKS                     2016-10-21   2023-03-30
10796  TWC-10796-MIDWEST                 2016-10-24   2023-03-30
271    BCNET                             2016-10-24   2023-03-31
1403   EBOX                              2016-11-12   2023-03-28
2828   XO-AS15                           2016-11-21   2023-03-17
852    ASN852                            2017-04-16   2023-03-26
6461   ZAYO-6461                         2017-06-21   2023-03-28
33452  RW                                2018-09-19   2023-03-26
21804  ACCESS-SK                         2019-06-09   2023-03-05
11814  DISTRIBUTEL-AS11814               2020-11-22   2023-03-22
398836                                   2021-03-12   2023-03-27
22773  ASN-CXA-ALL-CCI-22773-RDC         2021-10-24   2023-03-13
46997                                    2021-12-22   2023-03-29
394414 E2WS                              2022-05-08   2023-03-28
397086 GLOBAL-FRAG-NETWORKS-HOUSTON      2022-06-16   2023-03-27
11976  FIDN                              2022-11-16   2023-03-29
12183  TALKIE-COMMUNICATIONS             2022-12-10   2023-03-30
21555  LHTC                              2023-01-01   2023-03-24
33185  TGLO-VGLO                         2023-02-04   2023-03-03
399852                                   2023-02-16   2023-03-26
210546                                   2023-02-27   2023-03-07
203394 asn-Lighting                      2023-03-07   2023-03-21
199785                                   2023-03-11   2023-03-24
211380                                   2023-03-15   2023-03-29
964    GONET-ASN-17                      2023-03-15   2023-03-29
140224                                   2023-03-18   2023-03-18
199868                                   2023-03-18   2023-03-24
41378  KirinoNET                         2023-03-23   2023-03-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=1

Please send any feedback or suggestions to spoofer-info at caida.org

From joel at joelesler.net  Fri Apr  7 13:15:39 2023
From: joel at joelesler.net (Joel Esler)
Date: Fri, 7 Apr 2023 09:15:39 -0400
Subject: Auth0 geolocation?
In-Reply-To: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>
References: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>
Message-ID: <BE4D76BC-9F94-45D1-96BF-0C40843653EE@joelesler.net>

An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230407/8d054415/attachment.html>

From tim at mid.net  Mon Apr 10 13:29:07 2023
From: tim at mid.net (Tim Burke)
Date: Mon, 10 Apr 2023 13:29:07 +0000
Subject: Auth0 geolocation?
In-Reply-To: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>
References: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>
Message-ID: <6348da2c7af64a269040af873f604283@mid.net>

Apple and Best Buy are other ones that just came up over the weekend, seems to be spread out across an entire /17. Oddly, we've had this /17 for close to a year and a half, and this is just popping up...

________________________________
From: NANOG <nanog-bounces+tim=mid.net at nanog.org> on behalf of Tim Burke <tim at mid.net>
Sent: Thursday, April 6, 2023 7:32:41 PM
To: NANOG
Subject: Auth0 geolocation?

Anyone know who Auth0 is using for geolocation services? Have a customer reporting that Auth0, Lowes, Bank of America, and some other sites are reporting their IP in the wrong location. Checked the usual suspects, BrothersWISP.com<http://BrothersWISP.com> geolocation providers list, etcetera and they?re all showing in the correct location.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230410/1af45f62/attachment.html>

From jhaas at pfrc.org  Tue Apr 11 14:31:05 2023
From: jhaas at pfrc.org (Jeffrey Haas)
Date: Tue, 11 Apr 2023 10:31:05 -0400
Subject: Fwd: WG Last Call on draft-ietf-idr-bgp-model-16
References: <71ab1fab3f124b69804ab22d30ec12fd@huawei.com>
Message-ID: <FD0ED90B-8722-4DEB-8966-3C4F32F7D869@pfrc.org>

The IETF BGP YANG module authors would like to draw your collective attention to a Working Group Last Call that has begun for the IETF BGP YANG module.

This module provides the base for core IETF BGP technologies, and will serve as the primary point of extension for BGP-related technologies modeled in YANG in the IETF, including the BGP portion of VPN technologies.

Your operational wisdom and scrutiny would be greatly appreciated.

A URL for the WGLC mail is here:
https://mailarchive.ietf.org/arch/msg/idr/263_yrn_ZnNRokmUwgye7Id5mHo/

For those of you who haven't participated in IETF mail lists before, the IDR datatracker page has subscription information for the mailing list:
https://datatracker.ietf.org/wg/idr/about/

Thanks!

-- Jeff (for the authors)

> Begin forwarded message:
> 
> From: "Dongjie (Jimmy)" <jie.dong at huawei.com>
> Subject: WG Last Call on draft-ietf-idr-bgp-model-16
> Date: April 10, 2023 at 10:17:26 PM EDT
> To: "idr at ietf.org" <idr at ietf.org>
> Cc: "idr-chairs at ietf.org" <idr-chairs at ietf.org>, "Dongjie (Jimmy)" <jie.dong at huawei.com>
> Resent-From: <alias-bounces at ietf.org>
> Resent-To: skh at ndzh.com, keyur at arrcus.com, jhaas at pfrc.org, jie.dong at huawei.com
> 
> Hi WG, 
>  
> This begins the Working Group Last Call for "YANG Model for Border Gateway Protocol (BGP-4)", draft-ietf-idr-bgp-model-16. The draft could be found at: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16>. 
>  
> Since all the IDR chairs are coauthors of this document, I?m helping with this last call procedure. Please reply to the list with your comments. Considering this is a long document with a big YANG model, the last call will last for 4 weeks and conclude on Sunday, 7 May, 2023.
>  
> The authors are requested to state whether they are aware of applicable IPR related to this draft. Similarly, if others in the Working Group are aware of applicable IPR, please also disclose them.
>  
> People are encouraged to indicate whether there is implementation of this document. According to the IDR rule, at least two implementations will be required to advance the document.
>  
>  
> Best regards,
> Jie (on behalf of the IDR chairs)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230411/3e733bfe/attachment.html>

From bobin.public at gmail.com  Tue Apr 11 15:12:35 2023
From: bobin.public at gmail.com (Samuel Jackson)
Date: Tue, 11 Apr 2023 08:12:35 -0700
Subject: DNS resolution for hhs.gov
Message-ID: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>

I wanted to run this by everyone to make sure I am not the one losing my
mind over this.

A dig +trace cob.cms.hhs.gov fails for me as it looks like the NS for
hhs.gov does not seem to resolve the hostname.

However dig +trace cms.hhs.gov resolves and so does dig +trace
eclkc.ohs.acf.hhs.gov

However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it
works. Any thoughts on why this is the case?

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230411/9c25498d/attachment.html>

From rstory at ant.isi.edu  Tue Apr 11 16:16:36 2023
From: rstory at ant.isi.edu (Robert Story)
Date: Tue, 11 Apr 2023 12:16:36 -0400
Subject: DNS resolution for hhs.gov
In-Reply-To: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
Message-ID: <20230411121636.4de736ca@p1g4.rs.isi.edu>

On Tue 2023-04-11 08:12:35-0700 Samuel wrote:
> A dig +trace cob.cms.hhs.gov fails for me as it looks like the NS for
> hhs.gov does not seem to resolve the hostname.
> 
> However dig +trace cms.hhs.gov resolves and so does dig +trace
> eclkc.ohs.acf.hhs.gov
> 
> However if I simply ask my local resolver to resolve cob.cms.hhs.gov,
> it works. Any thoughts on why this is the case?

Looks like their v6 resolvers are failing, but v4 works fine.

DNSVis.net is a good place to check nameserver issues..

-- 
Regards,
Robert

--
Robert Story 
USC Information Sciences Institute <http://www.isi.edu/>
Networking and?Cybersecurity?Division

From bortzmeyer at nic.fr  Tue Apr 11 16:32:55 2023
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 11 Apr 2023 18:32:55 +0200
Subject: DNS resolution for hhs.gov
In-Reply-To: <20230411121636.4de736ca@p1g4.rs.isi.edu>
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
 <20230411121636.4de736ca@p1g4.rs.isi.edu>
Message-ID: <ZDWLt7T8u4ffOOFn@nic.fr>

On Tue, Apr 11, 2023 at 12:16:36PM -0400,
 Robert Story <rstory at ant.isi.edu> wrote 
 a message of 22 lines which said:

> DNSVis.net is a good place to check nameserver issues..

DNSViZ.net. Yes, great service.

From bobin.public at gmail.com  Tue Apr 11 17:13:08 2023
From: bobin.public at gmail.com (Samuel Jackson)
Date: Tue, 11 Apr 2023 10:13:08 -0700
Subject: DNS resolution for hhs.gov
In-Reply-To: <ZDWLt7T8u4ffOOFn@nic.fr>
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
 <20230411121636.4de736ca@p1g4.rs.isi.edu> <ZDWLt7T8u4ffOOFn@nic.fr>
Message-ID: <CAOAsu-QSUCbRhsjXN6qE9rqehj+srPiq34CeXfDGvqB_gK6Bdg@mail.gmail.com>

Thanks,
Yeah, I did run it on that site too. What I am trying to figure out is why
trace does not seem to work. Our DNS servers perform queries similar to
what trace would do. They fail to resolve the hostname.

They do not use another local resolver.

Thanks,

On Tue, Apr 11, 2023 at 9:33?AM Stephane Bortzmeyer <bortzmeyer at nic.fr>
wrote:

> On Tue, Apr 11, 2023 at 12:16:36PM -0400,
>  Robert Story <rstory at ant.isi.edu> wrote
>  a message of 22 lines which said:
>
> > DNSVis.net is a good place to check nameserver issues..
>
> DNSViZ.net. Yes, great service.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230411/2ac708ce/attachment.html>

From matthew at corp.crocker.com  Tue Apr 11 18:10:26 2023
From: matthew at corp.crocker.com (Matthew Crocker)
Date: Tue, 11 Apr 2023 18:10:26 +0000
Subject: Santander bank contact
Message-ID: <BL0PR14MB355412195B0A42BF82A67885829A9@BL0PR14MB3554.namprd14.prod.outlook.com>


If anyone on this list is affiliated with Santander bank please reach me off-list.  You are blocking one of my subnets and my customers cannot access your bank website.

Thanks

-Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230411/932072de/attachment.html>

From marka at isc.org  Tue Apr 11 23:38:45 2023
From: marka at isc.org (Mark Andrews)
Date: Wed, 12 Apr 2023 09:38:45 +1000
Subject: DNS resolution for hhs.gov
In-Reply-To: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
Message-ID: <DC75D603-6B86-443E-92CD-DAE5A6B2E256@isc.org>

The nameservers are not answering all in scope questions being sent to the servers.  Something is blocking or not generating NXDOMAIN responses.  This impacts on QNAME minimisation queries that usually elicit a NXDOMAIN response.  This happens irrespective of DNSSEC records being requested so I doubt that it is a fragmentation issue.

Both _.dhhs.gov <http://dhhs.gov/> and foobar.dhhs.gov <http://foobar.dhhs.gov/> time out but dhhs.gov <http://dhhs.gov/> itself doesn?t.

% dig _.dhhs.gov @158.74.30.103 +dnssec
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out

; <<>> DiG 9.19.11-dev <<>> _.dhhs.gov @158.74.30.103 +dnssec
;; global options: +cmd
;; no servers could be reached

% dig dhhs.gov @158.74.30.103 +dnssec

; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.103 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18125
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: d939ecfdb6cd2d902678cca26435eb2dd6fcebd65fe5c58f (good)
;; QUESTION SECTION:
;dhhs.gov. IN A

;; ANSWER SECTION:
dhhs.gov. 9000 IN A 52.7.111.176
dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 11710 dhhs.gov. YCEsecATdJEHs3OtxQs/kE2A/37/mzgUpGLzQwrPP9xqaGmBq2mDteKx QyUnh0JuURBq0Qy1htxsOD9kX4dxSxUNCEO7/KHw0AOoIbnh2+GL8kc3 jKB2jkcN+whA9+CqThto020nLSCXcgdm7qOfyNBUFICoYNtVrd7/lLCJ kho=
dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 21469 dhhs.gov. OkEdR/ofhV+JogwAkZtLmHyxn3pK2E4zaGUV786kKbtQrI6SzetCk+sC Db3W0LrYRZy1BEqqxZeRnLXVEjyyyKfnYMRPtoP3sCTLPuuDeu8oDmhw eniXLbJ10od6YWywgQDl2bYrTLEt6R8+TGG7up446TGgRk9wOV/uU2Jb d+U=

;; Query time: 308 msec
;; SERVER: 158.74.30.103#53(158.74.30.103) (UDP)
;; WHEN: Wed Apr 12 09:20:13 AEST 2023
;; MSG SIZE  rcvd: 417

% dig foobar.dhhs.gov @158.74.30.103 +dnssec
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out

; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 +dnssec
;; global options: +cmd
;; no servers could be reached

% dig foobar.dhhs.gov @158.74.30.103 
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out
;; communications error to 158.74.30.103#53: timed out

; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103
;; global options: +cmd
;; no servers could be reached

% 

> On 12 Apr 2023, at 01:12, Samuel Jackson <bobin.public at gmail.com> wrote:
> 
> I wanted to run this by everyone to make sure I am not the one losing my mind over this.
> 
> A dig +trace cob.cms.hhs.gov fails for me as it looks like the NS for hhs.gov does not seem to resolve the hostname.
> 
> However dig +trace cms.hhs.gov resolves and so does dig +trace eclkc.ohs.acf.hhs.gov
> 
> However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it works. Any thoughts on why this is the case?
> 
> Thanks,
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From marka at isc.org  Wed Apr 12 06:47:04 2023
From: marka at isc.org (Mark Andrews)
Date: Wed, 12 Apr 2023 16:47:04 +1000
Subject: Your DNS Servers are not working correctly.
Message-ID: <0788A807-DC2B-4E86-92E3-65336C4DBB35@isc.org>

I work for a DNS vendor and saw reports about DNS resolution errors when looking up names under dhhs.gov.
It looks like your servers are not returning non-existence answers over UDP which breaks servers that are trying to do DNS QNAME minimisation (See RFC 7816).

Below are three queries that the servers should be capable of answering if they are following the DNS protocol correctly.  dhhs.gov is answered but foobar.dhhs.gov doesn?t return anything and I would expect a NXDOMAIN (Name Error) response.  Additionally 355.dhhs.gov should be returning a NODATA/NOERROR response at a minimum as it part of your DNS servers names.

If I ask the same questions over TCP instead of UDP I get answers.

This really smells like a misconfigured firewall.

Mark

% dig dhhs.gov @158.74.30.99

; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.99
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59012
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7b8cd5530b5fa45190ac7ac264364fe858d1f83093c6da62 (good)
;; QUESTION SECTION:
;dhhs.gov. IN A

;; ANSWER SECTION:
dhhs.gov. 9000 IN A 52.7.111.176

;; Query time: 243 msec
;; SERVER: 158.74.30.99#53(158.74.30.99) (UDP)
;; WHEN: Wed Apr 12 16:30:00 AEST 2023
;; MSG SIZE  rcvd: 81

% dig foobar.dhhs.gov @158.74.30.99
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out

; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.99
;; global options: +cmd
;; no servers could be reached

[ant-7641:~/git/bind9] marka% dig 355.dhhs.gov @158.74.30.99
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out

; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov @158.74.30.99
;; global options: +cmd
;; no servers could be reached

% 

% dig dhhs.gov @158.74.30.99 +tcp

; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.99 +tcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18254
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 710a14c38e16a91fd4060d86643652ecca2dce18d21e3144 (good)
;; QUESTION SECTION:
;dhhs.gov. IN A

;; ANSWER SECTION:
dhhs.gov. 9000 IN A 52.7.111.176

;; Query time: 246 msec
;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
;; WHEN: Wed Apr 12 16:42:52 AEST 2023
;; MSG SIZE  rcvd: 81

% dig 355.dhhs.gov @158.74.30.99 +tcp

; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov @158.74.30.99 +tcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56223
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e10fe6bd8dccc0ed038bbff1643652fb582c8d51b5d3a25c (good)
;; QUESTION SECTION:
;355.dhhs.gov. IN A

;; AUTHORITY SECTION:
dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021759 1200 300 2419200 3600

;; Query time: 246 msec
;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
;; WHEN: Wed Apr 12 16:43:07 AEST 2023
;; MSG SIZE  rcvd: 137


% 
 -- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From bjorn at mork.no  Wed Apr 12 07:16:15 2023
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Wed, 12 Apr 2023 09:16:15 +0200
Subject: DNS resolution for hhs.gov
In-Reply-To: <DC75D603-6B86-443E-92CD-DAE5A6B2E256@isc.org> (Mark Andrews's
 message of "Wed, 12 Apr 2023 09:38:45 +1000")
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
 <DC75D603-6B86-443E-92CD-DAE5A6B2E256@isc.org>
Message-ID: <87ile1y3i8.fsf@miraculix.mork.no>

Interestingly enough, the company behind this mess decided to sign it:

 bjorn at canardo:~$ dig dhhs.gov @158.74.30.99 +nsid|grep NSID
 ; NSID: 4c 65 69 64 6f 73 20 62 75 69 6c 64 20 57 2e 56 45 52 4e 41 20 32 30 32 33 ("Leidos build W.VERNA 2023")


Guessing this was done by "security professionals" from
https://www.leidos.com/




Bj?rn

Mark Andrews <marka at isc.org> writes:

> The nameservers are not answering all in scope questions being sent to the servers.  Something is blocking or not generating NXDOMAIN responses.  This impacts on QNAME minimisation queries that usually elicit a NXDOMAIN response.  This happens irrespective of DNSSEC records being requested so I doubt that it is a fragmentation issue.
>
> Both _.dhhs.gov <http://dhhs.gov/> and foobar.dhhs.gov <http://foobar.dhhs.gov/> time out but dhhs.gov <http://dhhs.gov/> itself doesn?t.
>
> % dig _.dhhs.gov @158.74.30.103 +dnssec
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
>
> ; <<>> DiG 9.19.11-dev <<>> _.dhhs.gov @158.74.30.103 +dnssec
> ;; global options: +cmd
> ;; no servers could be reached
>
> % dig dhhs.gov @158.74.30.103 +dnssec
>
> ; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.103 +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18125
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ; COOKIE: d939ecfdb6cd2d902678cca26435eb2dd6fcebd65fe5c58f (good)
> ;; QUESTION SECTION:
> ;dhhs.gov. IN A
>
> ;; ANSWER SECTION:
> dhhs.gov. 9000 IN A 52.7.111.176
> dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 11710 dhhs.gov. YCEsecATdJEHs3OtxQs/kE2A/37/mzgUpGLzQwrPP9xqaGmBq2mDteKx QyUnh0JuURBq0Qy1htxsOD9kX4dxSxUNCEO7/KHw0AOoIbnh2+GL8kc3 jKB2jkcN+whA9+CqThto020nLSCXcgdm7qOfyNBUFICoYNtVrd7/lLCJ kho=
> dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 21469 dhhs.gov. OkEdR/ofhV+JogwAkZtLmHyxn3pK2E4zaGUV786kKbtQrI6SzetCk+sC Db3W0LrYRZy1BEqqxZeRnLXVEjyyyKfnYMRPtoP3sCTLPuuDeu8oDmhw eniXLbJ10od6YWywgQDl2bYrTLEt6R8+TGG7up446TGgRk9wOV/uU2Jb d+U=
>
> ;; Query time: 308 msec
> ;; SERVER: 158.74.30.103#53(158.74.30.103) (UDP)
> ;; WHEN: Wed Apr 12 09:20:13 AEST 2023
> ;; MSG SIZE  rcvd: 417
>
> % dig foobar.dhhs.gov @158.74.30.103 +dnssec
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
>
> ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 +dnssec
> ;; global options: +cmd
> ;; no servers could be reached
>
> % dig foobar.dhhs.gov @158.74.30.103 
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
> ;; communications error to 158.74.30.103#53: timed out
>
> ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103
> ;; global options: +cmd
> ;; no servers could be reached
>
> % 
>
>> On 12 Apr 2023, at 01:12, Samuel Jackson <bobin.public at gmail.com> wrote:
>> 
>> I wanted to run this by everyone to make sure I am not the one losing my mind over this.
>> 
>> A dig +trace cob.cms.hhs.gov fails for me as it looks like the NS for hhs.gov does not seem to resolve the hostname.
>> 
>> However dig +trace cms.hhs.gov resolves and so does dig +trace eclkc.ohs.acf.hhs.gov
>> 
>> However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it works. Any thoughts on why this is the case?
>> 
>> Thanks,
>> 

From cgrundemann at gmail.com  Wed Apr 12 14:05:42 2023
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 12 Apr 2023 08:05:42 -0600
Subject: ABQNOG -- May 4, 2023
In-Reply-To: <20230404025703.GA6525@jeeves.rigozsaurus.com>
References: <20230404025703.GA6525@jeeves.rigozsaurus.com>
Message-ID: <CAC1-dt=cwsJ32-0t7bhzk8MW6X-CnHXGR71e-R_=VOw3_hTvJA@mail.gmail.com>

Thanks for sharing, John. I'm excited for this event, long overdue!

See everyone there - find me wherever the green chile is being served. =)

~Chris



On Mon, Apr 3, 2023 at 8:58?PM John Osmon <josmon at rigozsaurus.com> wrote:

> For folks that might be in the southwest US (and any that want to
> visit!), we're going to hold an operators group meeting on May 4,
> 2023 in Albuquerque, New Mexico.
>
> Come to the land of green chile chessburgers, and meet some of the
> local operators.  This inaugural meeting is free.  We hope to
> see you in May!
>
> http://abqnog.org
>
>
>
>

-- 
@ChrisGrundemann
http://chrisgrundemann.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230412/38d5fc59/attachment.html>

From news at nanog.org  Wed Apr 12 14:17:30 2023
From: news at nanog.org (Nanog News)
Date: Wed, 12 Apr 2023 10:17:30 -0400
Subject: N88 Sponsorships, Peering Forum, Final Call for Presentations +
 CaribNOG 25 Empowers Underserved Students + Inspires Community
Message-ID: <CAHf5Ly2vb8ANDKk0sSGCNQbuQ7g+PWtKGE0po40mQ9BLnhj9Fw@mail.gmail.com>

*Become a Sponsor of NANOG 88!*
*Invest in the Strength of the Community We've Built *

*Sponsorship Benefits: *

? Showcase your newest technologies + solutions
? Increase your brand?s visibility + reach
? Amplify your organization?s message
? Connect with industry influencers + decision makers
? Empower people + inspire change

*MORE INFO*
<https://nanog.org/events/sponsorship/sponsorship-opportunities/>

*Creating Global Connectivity by Connecting Globally*
*CaribNOG 25 Empowers Underserved Students + Inspires Community*

Network Engineer II at Akamai Technologies, Aaron Atac, is a part of the
millennial community at NANOG and serves on the Outreach and Programming
Committee. This was his first time attending CaribNOG, and "events like
these" originally motivated him to get involved.

Atac has a shared mission in helping these communities inspired by his dad,
who grew up in Turkey with limited access to education.

*READ NOW
<https://nanog.org/stories/creating-global-connectivity-by-connecting-globally/>*

*Sign up for the NANOG 88 Peering Forum *
*Meet + Greet Peers in this 90 Min Session *

The Peering Coordination Forum applications will remain open until 20
applications have been received or until the deadline date of 05, June.

The forum provides time for attendees to meet and network with others in
the peering community present at NANOG.

<https://nanog.org/events/nanog-88/>
*MORE INFO* <https://nanog.org/events/nanog-88/>

*Fundamentals of Designing and Deploying Computer Networks*
*ISOC Presents Moderated Course with Instructor *

This course will discuss the fundamentals of networking, Ethernet, and WIFI
technologies. It will additionally teach the planning, design, and
deployment of simple LANs and cover how to connect a LAN to the Internet.

*MORE INFO
<https://nanog.org/events/fundamentals-of-designing-and-deploying-computer-networks/>*

*Deadline for N88 Presentations is Approaching!*
*Presentation Submission Deadline is Monday, 24 April*

The NANOG PC is looking to schedule over 1,600 minutes of content between
General Session and Breakout Rooms for NANOG 88 - so don?t wait!

*MORE INFO * <https://nanog.org/program/call-presentations/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230412/764039d7/attachment.html>

From 3356 at blargh.com  Wed Apr 12 20:36:55 2023
From: 3356 at blargh.com (Andrew Gray)
Date: Wed, 12 Apr 2023 14:36:55 -0600
Subject: TLS issues with Lumen (CenturyLink)
Message-ID: <4b8ace07-3890-6845-52d1-da8df249d3d2@blargh.com>

Can someone from Lumen/CenturyLink contact me off-list?

We are seeing issues with some traffic coming from customers inside 
AS209 (and only AS209) that appear to be hitting some sort of 
in-the-middle inspection that is causing TLS issues (showing that the 
certificates are invalid).

Thanks!



From tim at mid.net  Thu Apr 13 13:43:14 2023
From: tim at mid.net (Tim Burke)
Date: Thu, 13 Apr 2023 13:43:14 +0000
Subject: Auth0 geolocation?
In-Reply-To: <6348da2c7af64a269040af873f604283@mid.net>
References: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>,
 <6348da2c7af64a269040af873f604283@mid.net>
Message-ID: <d97cc929a1d34672b920020d700007d3@mid.net>

For those following along at home, it appears that Akamai was the culprit. Didn't even know they offered geolocation services! Many thanks and much respect to those who reached out off-list.


Best,

Tim

________________________________
From: Tim Burke
Sent: Monday, April 10, 2023 8:29:07 AM
To: NANOG
Subject: Re: Auth0 geolocation?


Apple and Best Buy are other ones that just came up over the weekend, seems to be spread out across an entire /17. Oddly, we've had this /17 for close to a year and a half, and this is just popping up...

________________________________
From: NANOG <nanog-bounces+tim=mid.net at nanog.org> on behalf of Tim Burke <tim at mid.net>
Sent: Thursday, April 6, 2023 7:32:41 PM
To: NANOG
Subject: Auth0 geolocation?

Anyone know who Auth0 is using for geolocation services? Have a customer reporting that Auth0, Lowes, Bank of America, and some other sites are reporting their IP in the wrong location. Checked the usual suspects, BrothersWISP.com<http://BrothersWISP.com> geolocation providers list, etcetera and they?re all showing in the correct location.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230413/3e78b98d/attachment.html>

From josh at imaginenetworksllc.com  Thu Apr 13 13:56:53 2023
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Thu, 13 Apr 2023 09:56:53 -0400
Subject: Auth0 geolocation?
In-Reply-To: <d97cc929a1d34672b920020d700007d3@mid.net>
References: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>
 <6348da2c7af64a269040af873f604283@mid.net>
 <d97cc929a1d34672b920020d700007d3@mid.net>
Message-ID: <CAN9qwJ88vdZo1n2pFn14TqH8onTsOsLQXy32MfW-xucHOHBECg@mail.gmail.com>

Is there a publicly available email address/form/etc that we can put on TBW
page?

On Thu, Apr 13, 2023 at 9:43?AM Tim Burke <tim at mid.net> wrote:

> For those following along at home, it appears that Akamai was the culprit.
> Didn't even know they offered geolocation services! Many thanks and much
> respect to those who reached out off-list.
>
>
> Best,
>
> Tim
> ------------------------------
> *From:* Tim Burke
> *Sent:* Monday, April 10, 2023 8:29:07 AM
> *To:* NANOG
> *Subject:* Re: Auth0 geolocation?
>
>
> Apple and Best Buy are other ones that just came up over the weekend,
> seems to be spread out across an entire /17. Oddly, we've had this /17 for
> close to a year and a half, and this is just popping up...
> ------------------------------
> *From:* NANOG <nanog-bounces+tim=mid.net at nanog.org> on behalf of Tim
> Burke <tim at mid.net>
> *Sent:* Thursday, April 6, 2023 7:32:41 PM
> *To:* NANOG
> *Subject:* Auth0 geolocation?
>
> Anyone know who Auth0 is using for geolocation services? Have a customer
> reporting that Auth0, Lowes, Bank of America, and some other sites are
> reporting their IP in the wrong location. Checked the usual suspects,
> BrothersWISP.com geolocation providers list, etcetera and they?re all
> showing in the correct location.
>
> Thanks,
> Tim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230413/8b3fae5a/attachment.html>

From tim at mid.net  Thu Apr 13 14:03:57 2023
From: tim at mid.net (Tim Burke)
Date: Thu, 13 Apr 2023 14:03:57 +0000
Subject: Auth0 geolocation?
In-Reply-To: <CAN9qwJ88vdZo1n2pFn14TqH8onTsOsLQXy32MfW-xucHOHBECg@mail.gmail.com>
References: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>
 <6348da2c7af64a269040af873f604283@mid.net>
 <d97cc929a1d34672b920020d700007d3@mid.net>,
 <CAN9qwJ88vdZo1n2pFn14TqH8onTsOsLQXy32MfW-xucHOHBECg@mail.gmail.com>
Message-ID: <d38a6ee92b1d43c9aebd0386edf58e0f@mid.net>

I don't believe so. Someone was gracious enough to dip the Akamai DB for me... I ended up just emailing support at akamai.com after finding the discrepancy, waiting for them to finish processing the changes. There's gotta be a better way to do this, though!

________________________________
From: Josh Luthman <josh at imaginenetworksllc.com>
Sent: Thursday, April 13, 2023 8:56:53 AM
To: Tim Burke
Cc: NANOG
Subject: Re: Auth0 geolocation?

Is there a publicly available email address/form/etc that we can put on TBW page?

On Thu, Apr 13, 2023 at 9:43?AM Tim Burke <tim at mid.net<mailto:tim at mid.net>> wrote:

For those following along at home, it appears that Akamai was the culprit. Didn't even know they offered geolocation services! Many thanks and much respect to those who reached out off-list.


Best,

Tim

________________________________
From: Tim Burke
Sent: Monday, April 10, 2023 8:29:07 AM
To: NANOG
Subject: Re: Auth0 geolocation?


Apple and Best Buy are other ones that just came up over the weekend, seems to be spread out across an entire /17. Oddly, we've had this /17 for close to a year and a half, and this is just popping up...

________________________________
From: NANOG <nanog-bounces+tim=mid.net at nanog.org<mailto:mid.net at nanog.org>> on behalf of Tim Burke <tim at mid.net<mailto:tim at mid.net>>
Sent: Thursday, April 6, 2023 7:32:41 PM
To: NANOG
Subject: Auth0 geolocation?

Anyone know who Auth0 is using for geolocation services? Have a customer reporting that Auth0, Lowes, Bank of America, and some other sites are reporting their IP in the wrong location. Checked the usual suspects, BrothersWISP.com<http://BrothersWISP.com> geolocation providers list, etcetera and they?re all showing in the correct location.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230413/122d4aad/attachment.html>

From josh at imaginenetworksllc.com  Thu Apr 13 14:06:44 2023
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Thu, 13 Apr 2023 10:06:44 -0400
Subject: Auth0 geolocation?
In-Reply-To: <d38a6ee92b1d43c9aebd0386edf58e0f@mid.net>
References: <66DA24CF-70F0-4216-918E-9C4B9C22719F@mid.net>
 <6348da2c7af64a269040af873f604283@mid.net>
 <d97cc929a1d34672b920020d700007d3@mid.net>
 <CAN9qwJ88vdZo1n2pFn14TqH8onTsOsLQXy32MfW-xucHOHBECg@mail.gmail.com>
 <d38a6ee92b1d43c9aebd0386edf58e0f@mid.net>
Message-ID: <CAN9qwJ8iYkMbwdkxWLL45mDzSr2-8nyZrM4pNgr=6FUUA=giLA@mail.gmail.com>

So the contact helped you but the email to support was the fix?  Could you
share the sanitized details of what you sent to support?

On Thu, Apr 13, 2023 at 10:04?AM Tim Burke <tim at mid.net> wrote:

> I don't believe so. Someone was gracious enough to dip the Akamai DB for
> me... I ended up just emailing support at akamai.com after finding the
> discrepancy, waiting for them to finish processing the changes. There's
> gotta be a better way to do this, though!
> ------------------------------
> *From:* Josh Luthman <josh at imaginenetworksllc.com>
> *Sent:* Thursday, April 13, 2023 8:56:53 AM
> *To:* Tim Burke
> *Cc:* NANOG
> *Subject:* Re: Auth0 geolocation?
>
> Is there a publicly available email address/form/etc that we can put on
> TBW page?
>
> On Thu, Apr 13, 2023 at 9:43?AM Tim Burke <tim at mid.net> wrote:
>
>> For those following along at home, it appears that Akamai was the
>> culprit. Didn't even know they offered geolocation services! Many thanks
>> and much respect to those who reached out off-list.
>>
>>
>> Best,
>>
>> Tim
>> ------------------------------
>> *From:* Tim Burke
>> *Sent:* Monday, April 10, 2023 8:29:07 AM
>> *To:* NANOG
>> *Subject:* Re: Auth0 geolocation?
>>
>>
>> Apple and Best Buy are other ones that just came up over the weekend,
>> seems to be spread out across an entire /17. Oddly, we've had this /17 for
>> close to a year and a half, and this is just popping up...
>> ------------------------------
>> *From:* NANOG <nanog-bounces+tim=mid.net at nanog.org> on behalf of Tim
>> Burke <tim at mid.net>
>> *Sent:* Thursday, April 6, 2023 7:32:41 PM
>> *To:* NANOG
>> *Subject:* Auth0 geolocation?
>>
>> Anyone know who Auth0 is using for geolocation services? Have a customer
>> reporting that Auth0, Lowes, Bank of America, and some other sites are
>> reporting their IP in the wrong location. Checked the usual suspects,
>> BrothersWISP.com geolocation providers list, etcetera and they?re all
>> showing in the correct location.
>>
>> Thanks,
>> Tim
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230413/84bd8291/attachment.html>

From Jacques.Latour at cira.ca  Thu Apr 13 17:13:36 2023
From: Jacques.Latour at cira.ca (Jacques Latour)
Date: Thu, 13 Apr 2023 17:13:36 +0000
Subject: Call for Participation -- ICANN DNSSEC and Security Workshop for
 ICANN77 Policy Forum
Message-ID: <YT2P288MB0252997DC816986F9C816F488A989@YT2P288MB0252.CANP288.PROD.OUTLOOK.COM>

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN77 Policy Forum



In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), we are planning a DNSSEC and Security Workshop for the ICANN77 Policy Forum being held in Washington, DC and as a hybrid meeting from 12-15 June 2023 in the Eastern Time Zone (UTC -4). This workshop date will be determined once ICANN creates a block schedule for us to follow; then we will be able to request a day and time. The DNSSEC and Security Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.  For reference, the most recent session was held at the ICANN76 Community Forum on Wednesday,  15 March 2023. The presentations and transcripts are available at: https://icann76.sched.com/event/1J2JA/dnssec-and-security-workshop-1-of-3,

https://icann76.sched.com/event/1J2JD/dnssec-and-security-workshop-2-of-3 and

https://icann76.sched.com/event/1J2JE/dnssec-and-security-workshop-3-of-3.


The DNSSEC Workshop Program Committee is developing a program for the upcoming meeting.  Proposals will be considered for the following topic areas and included if space permits.  In addition, we welcome suggestions for additional topics either for inclusion in the ICANN77 workshop, or for consideration for future workshops.



1.  Global DNSSEC Activities Panel

For this panel, we are seeking participation from those who have been involved in DNSSEC deployment as well as from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment, including Root Key Signing Key (KSK) Rollover activities and plans.



2.  DNSSEC Best Practice

Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC?


  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones?



Activities and issues related to DNSSEC in the DNS Root Zone are also desired.



3. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC.  In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?



4. Security Panel

The program committee is looking for presentations on DNS, DNSSEC, routing and other topics that could impact the security and/or stability of the Internet.



We are looking for presentations that cover implementation issues, challenges, opportunities and best practices for:


  *   Emerging threats that could impact the security and/or stability of the Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security - DNS, DNSSEC, DoH
  *   EMAIL & DNS related security - DMARC, DKIM, TLSA, etc...



If you are interested in participating, please send a brief (1-3 sentence) description of your proposed presentation to dnssec-security-workshop at icann.org<mailto:dnssec-security-workshop at icann.org> by Friday, 12 May 2023.



Thank you,

Jacques

On behalf of the DNSSEC Workshop Program Committee:

Steve Crocker, Shinkuro

Mark Elkins, DNS/ZACR

Jacques Latour, .CA

Russ Mundy, Parsons

Ondrej Filip, CZ.NIC

Yoshiro Yoneya, JPRS

Fred Baker, ISC

Dan York, Internet Society



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230413/d4623f2e/attachment.html>

From mark at duffell.net  Fri Apr 14 00:18:53 2023
From: mark at duffell.net (Mark)
Date: Fri, 14 Apr 2023 10:18:53 +1000
Subject: Call for paper - AusNOG 2023 Conference
Message-ID: <CADjNxcadcouqu7HWWUfK9i5r4gJ_DTd-NqeRySE+suf8PckjBQ@mail.gmail.com>

Hi all,

AusNOG 2023 will be held at the Sea World Conference Centre on the
Gold Coast, Queensland (Yes this is not a typo, it is not in Sydney or
Melbourne this year) on the 7th & 8th of September, 2023.

That?s Aussie Spring time, a great time of year to make some
side-trips to our beautiful beaches, hike the hinterlands and explore
our Sunshine state!

The Program Committee is seeking submissions from people wishing to
present at the conference.

Please note that AusNOG 2023 is a technical conference so
presentations must be of a technical nature (i.e. no sales or
marketing presentations). Preference will be given to presentations
that result in actual operational outcomes.

We plan on recording presentations for release after the event for
those who are unable to attend, please don?t let that deter you from
submitting, if your presentation can not be published let us know and
we will ensure to not record it.

For further information, details of important dates, or to make a
submission please see the website at the URL
https://www.ausnog.net/events/ausnog-2023

Lastly, feel free to reach out to our PC committee with any questions;
Jocelyn Bateman (Program Chair), Belynda Pagram, Mark Duffell and Phil
Mawson.

From dougb at dougbarton.us  Fri Apr 14 16:41:27 2023
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 14 Apr 2023 09:41:27 -0700
Subject: DNS resolution for hhs.gov
In-Reply-To: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
Message-ID: <14d56724-c5ab-dfc0-2950-a25d23812789@dougbarton.us>

Responses in line below.

Doug


On 4/11/23 8:12 AM, Samuel Jackson wrote:
> I wanted to run this by everyone to make sure I am not the one losing my 
> mind over this.
> 
> A dig +trace cob.cms.hhs.gov <http://cob.cms.hhs.gov> fails for me as it 
> looks like the NS for hhs.gov <http://hhs.gov> does not seem to resolve 
> the hostname.

They shouldn't, since cms.hhs.gov is a delegated subzone. (Also, resolve 
is the wrong term, since those are authoritative servers, not 
resolvers.) The hhs.gov name servers are not authoritative for the 
cms.hhs.gov zone.

Using `dig +trace cob.cms.hhs.gov` worked for me just now, so it's 
possible that they fixed something in response to Mark's message.

> However dig +trace cms.hhs.gov <http://cms.hhs.gov> resolves and so does 

That makes sense, delegated sub zone.  :)

> dig +trace eclkc.ohs.acf.hhs.gov <http://eclkc.ohs.acf.hhs.gov>

No delegated sub zones in the path here, so the hhs.gov name servers are 
authoritative for this host.

> However if I simply ask my local resolver to resolve cob.cms.hhs.gov 
> <http://cob.cms.hhs.gov>, it works. Any thoughts on why this is the case?

Because it's getting the answer from the child zone (cms) like it should.

I'm sort of curious about what `dig +trace` results you received 
originally that made you believe that you weren't getting the right 
response. Are you currently seeing what you expect to see?

From jcurran at arin.net  Fri Apr 14 17:30:24 2023
From: jcurran at arin.net (John Curran)
Date: Fri, 14 Apr 2023 17:30:24 +0000
Subject: =?utf-8?B?UlBLSSBNZ210IENoYW5nZXMgYXQgQVJJTiAod2FzOiBGd2Q6IFthcmluLWFu?=
 =?utf-8?B?bm91bmNlXSBVcGNvbWluZyBDaGFuZ2VzIHRvIEFSSU7igJlzIFJlc291cmNl?=
 =?utf-8?Q?_Public_Key_Infrastructure_(RPKI))?=
In-Reply-To: <D40C7BEE-820E-499D-A139-D194D55243DF@arin.net>
References: <D40C7BEE-820E-499D-A139-D194D55243DF@arin.net>
Message-ID: <BE7B2E4D-F11F-411B-84B7-EED5AEBFB650@arin.net>

Operators -

Some important information regarding forthcoming RPKI management changes at ARIN.

FYI ,
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN <info at arin.net>
Date: April 13, 2023 at 1:27:19 PM EDT
To: arin-announce at arin.net
Subject: [arin-announce] Upcoming Changes to ARIN?s Resource Public Key Infrastructure (RPKI)

?The upcoming May software release will include multiple improvements to ARIN?s Resource Public Key Infrastructure (RPKI) services that will impact customers who utilize Hosted RPKI. These improvements will comprise a new, streamlined process for Route Origin Authorization (ROA) creation and maintenance, the introduction of auto-renewal for ROAs, and automation of previously ticketed processes for a more efficient RPKI experience.

**ROA Creation**

Customers will no longer need a ROA request signing key to register for Hosted RPKI services. Because customers will no longer need to create a private key, the ARIN Online user interface will feature streamlined and simplified ROA creation forms.

For customers who utilize ARIN?s API, there will be a new RESTful endpoint to create ROAs that will provide parity with the user interface improvements. For the foreseeable future, ARIN will continue supporting the existing (now referred to as legacy) RESTful provisioning endpoint for organizations with their own internal signing requirements.

**ROA Auto-renewal**

After the May software release, any ROA created via ARIN Online or the new RESTful provisioning endpoint will be automatically renewed, meaning all newly created ROAs will persist indefinitely until they are manually deleted. ARIN will also apply the auto-renew feature to any existing ROAs when we deploy this new functionality.

Please note: Any new ROAs created with the legacy RESTful endpoint will not be auto-renewed. If you would like your ROAs to be auto-renewed, you will need to use ARIN Online or the new RESTful provisioning endpoint. ARIN will be contacting customers who have created ROAs in both ARIN Online and REST to determine how they prefer to manage their existing ROAs.

**More Efficient Processes**

ARIN will automate resource certificate requests for users who hold Internet number resources under a Registration Services Agreement or Legacy Registration Services Agreement with ARIN. We are also improving the user interface for ROA generation. After successfully creating a ROA, you will see a confirmation notice before returning to your list of ROAs, which puts you one click away from creating your next ROA if necessary.

We hope these changes will make signing up for RPKI services much easier for our customers.

ARIN will inform the community when the software deployments are completed in May. In the meantime, visit the ARIN Blog in the coming weeks for additional details on these improvements.

Regards,

Brad Gorman
Senior Product Owner, ARIN Routing Security
American Registry for Internet Numbers (ARIN)
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230414/7ccb5698/attachment.html>

From cscora at apnic.net  Fri Apr 14 18:03:16 2023
From: cscora at apnic.net (Routing Table Analysis Role Account)
Date: Sat, 15 Apr 2023 04:03:16 +1000 (AEST)
Subject: Weekly Global IPv4 Routing Table Report
Message-ID: <20230414180316.A4F4AC0FC7@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the 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 bgp-stats at lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

IPv4 Routing Table Report   04:00 +10GMT Sat 15 Apr, 2023

  BGP Table (Global) as seen in Japan.

Report Website:     https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              918516
    Prefixes after maximum aggregation (per Origin AS):          348679
    Deaggregation factor:                                          2.63
    Unique aggregates announced (without unneeded subnets):      448419
Total ASes present in the Internet Routing Table:                 74329
    Prefixes per ASN:                                             12.36
Origin-only ASes present in the Internet Routing Table:           63774
Origin ASes announcing only one prefix:                           26207
Transit ASes present in the Internet Routing Table:               10555
Transit-only ASes present in the Internet Routing Table:            432
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      55
    Max AS path prepend of ASN (265020)                              50
Prefixes from unregistered ASNs in the Routing Table:              1397
    Number of instances of unregistered ASNs:                      1397
Number of 32-bit ASNs allocated by the RIRs:                      41657
Number of 32-bit ASNs visible in the Routing Table:               34469
Prefixes from 32-bit ASNs in the Routing Table:                  170077
Number of bogon 32-bit ASNs visible in the Routing Table:            12
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            934
Number of addresses announced to Internet:                   3061998848
    Equivalent to 182 /8s, 130 /16s and 101 /24s
    Percentage of available address space announced:               82.7
    Percentage of allocated address space announced:               82.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               99.6
Total number of prefixes smaller than registry allocations:      307006

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   242257
    Total APNIC prefixes after maximum aggregation:               69283
    APNIC Deaggregation factor:                                    3.50
Prefixes being announced from the APNIC address blocks:          236590
    Unique aggregates announced from the APNIC address blocks:    97749
APNIC Region origin ASes present in the Internet Routing Table:   13397
    APNIC Prefixes per ASN:                                       17.66
APNIC Region origin ASes announcing only one prefix:               3932
APNIC Region transit ASes present in the Internet Routing Table:   1805
Average APNIC Region AS path length visible:                        4.4
    Max APNIC Region AS path length visible:                         26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8686
Number of APNIC addresses announced to Internet:              773666688
    Equivalent to 46 /8s, 29 /16s and 55 /24s
APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    268730
    Total ARIN prefixes after maximum aggregation:               122356
    ARIN Deaggregation factor:                                     2.20
Prefixes being announced from the ARIN address blocks:           271182
    Unique aggregates announced from the ARIN address blocks:    130874
ARIN Region origin ASes present in the Internet Routing Table:    19082
    ARIN Prefixes per ASN:                                        14.21
ARIN Region origin ASes announcing only one prefix:                6964
ARIN Region transit ASes present in the Internet Routing Table:    1963
Average ARIN Region AS path length visible:                         3.7
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:    4788
Number of ARIN addresses announced to Internet:              1285271808
    Equivalent to 76 /8s, 155 /16s and 177 /24s
ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-401308
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  47/8,  48/8,  50/8,  52/8,  53/8,
                        54/8,  55/8,  56/8,  57/8,  63/8,  64/8,  65/8,
                        66/8,  67/8,  68/8,  69/8,  70/8,  71/8,  72/8,
                        73/8,  74/8,  75/8,  76/8,  96/8,  97/8,  98/8,
                        99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8,
                       130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8,
                       138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8,
                       147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8,
                       158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8,
                       166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8,
                       174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8,
                       206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8,
                      

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    259027
    Total RIPE prefixes after maximum aggregation:               121950
    RIPE Deaggregation factor:                                     2.12
Prefixes being announced from the RIPE address blocks:           255085
    Unique aggregates announced from the RIPE address blocks:    157646
RIPE Region origin ASes present in the Internet Routing Table:    28296
    RIPE Prefixes per ASN:                                         9.01
RIPE Region origin ASes announcing only one prefix:               12040
RIPE Region transit ASes present in the Internet Routing Table:    3962
Average RIPE Region AS path length visible:                         4.3
    Max RIPE Region AS path length visible:                          31
Number of RIPE region 32-bit ASNs visible in the Routing Table:   11132
Number of RIPE addresses announced to Internet:               717840512
    Equivalent to 42 /8s, 201 /16s and 96 /24s
RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 64396-64495
                       196608-213403
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                  117757
    Total LACNIC prefixes after maximum aggregation:              28461
    LACNIC Deaggregation factor:                                   4.14
Prefixes being announced from the LACNIC address blocks:         117044
    Unique aggregates announced from the LACNIC address blocks:   49186
LACNIC Region origin ASes present in the Internet Routing Table:  10985
    LACNIC Prefixes per ASN:                                      10.65
LACNIC Region origin ASes announcing only one prefix:              2661
LACNIC Region transit ASes present in the Internet Routing Table:  2286
Average LACNIC Region AS path length visible:                       5.0
    Max LACNIC Region AS path length visible:                        55
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  8780
Number of LACNIC addresses announced to Internet:             176708352
    Equivalent to 10 /8s, 136 /16s and 91 /24s
LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-273820 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  29348
    Total AfriNIC prefixes after maximum aggregation:              5795
    AfriNIC Deaggregation factor:                                  5.06
Prefixes being announced from the AfriNIC address blocks:         37681
    Unique aggregates announced from the AfriNIC address blocks:  12293
AfriNIC Region origin ASes present in the Internet Routing Table:  1738
    AfriNIC Prefixes per ASN:                                     21.68
AfriNIC Region origin ASes announcing only one prefix:              610
AfriNIC Region transit ASes present in the Internet Routing Table:  335
Average AfriNIC Region AS path length visible:                      4.9
    Max AfriNIC Region AS path length visible:                       30
Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1083
Number of AfriNIC addresses announced to Internet:            107792384
    Equivalent to 6 /8s, 108 /16s and 200 /24s
AfriNIC AS Blocks      36864-37887, 327680-329727 & ERX transfers
AfriNIC Address Blocks  41/8,  45/8, 102/8, 105/8, 154/8, 196/8, 197/8,
                      

APNIC Region per AS prefix count summary
----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  9808        9480       8705      39  CHINAMOBILE-CN China Mobile Communicati
  7545        5728        786     689  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4865       4192      75  ERX-CERNET-BKB China Education and Rese
  7552        3552       1331      21  VIETEL-AS-AP Viettel Group, VN
  7713        3545       1043      65  TELKOMNET-AS-AP PT Telekomunikasi Indon
 45899        3388       1872      93  VNPT-AS-VN VNPT Corp, VN
  9498        2932        491     237  BBIL-AP BHARTI Airtel Ltd., IN
  4766        2551      11252     591  KIXS-AS-KR Korea Telecom, KR
 24560        2375        836     442  AIRTELBROADBAND-AS-AP Bharti Airtel Ltd
 45090        2184       1438      79  TENCENT-NET-AP Shenzhen Tencent Compute

Complete listing at https://thyme.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 16509        8240      10779    2906  AMAZON-02, US
 11492        4541        301     607  CABLEONE, US
  7155        3967        279      48  VIASAT-SP-BACKBONE, US
 22773        3600       3056     280  ASN-CXA-ALL-CCI-22773-RDC, US
  6327        3514       1320      64  SHAW, CA
 16625        3165       1590    2343  AKAMAI-AS, US
   749        3055      50540    2322  DNIC-AS-00749, US
396982        2630       3590     362  GOOGLE-CLOUD-PLATFORM, US
  7018        2566      24116    1563  ATT-INTERNET4, US
 30036        2493        360     505  MEDIACOM-ENTERPRISE-BUSINESS, US

Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 12479        7237       1705     149  UNI2-AS, ES
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 20940        4066       3399     164  AKAMAI-ASN1, NL
  8551        3889        370      37  BEZEQ-INTERNATIONAL-AS Bezeqint Interne
 12389        2949       2292     909  ROSTELECOM-AS, RU
  9009        2659        249    1390  M247, RO
 34984        2271        359     611  TELLCOM-AS, TR
  6849        2017        307      18  UKRTELNET, UA
 58224        1850        950     543  TCI, IR
 13188        1606        100      26  TRIOLAN, UA

Complete listing at https://thyme.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11234       3343     579  Uninet S.A. de C.V., MX
 10620        3500        507     851  Telmex Colombia S.A., CO
 13999        2317        355     615  Mega Cable, S.A. de C.V., MX
 11830        2262        369      64  Instituto Costarricense de Electricidad
 28573        1332       2324     240  Claro NXT Telecomunicacoes Ltda, BR
  6503        1299        339     514  Axtel, S.A.B. de C.V., MX
  3816        1293        760     170  COLOMBIA TELECOMUNICACIONES S.A. ESP, C
  6147        1133        370      22  Telefonica del Peru S.A.A., PE
 11664        1103        180     447  Techtel LMDS Comunicaciones Interactiva
 26615        1028       2498      45  TIM SA, BR

Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 24863        1578        393      19  LINKdotNET-AS, EG
 24835        1541        533      30  RAYA-AS, EG
 36992        1338       1518     275  ETISALAT-MISR, EG
 36903        1242        550      99  MT-MPLS, MA
 29571        1023         67      48  ORANGE-COTE-IVOIRE, CI
 36935         875        520      42  Vodafone-, EG
  6713         550       1861      34  IAM-AS, MA
 15399         535         54      47  WANANCHI-, KE
 37342         493         32       1  MOVITEL, MZ
 24757         488         73       5  EthioNet-AS, ET

Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11234       3343     579  Uninet S.A. de C.V., MX
  9808        9480       8705      39  CHINAMOBILE-CN China Mobile Communicati
 16509        8240      10779    2906  AMAZON-02, US
 12479        7237       1705     149  UNI2-AS, ES
  7545        5728        786     689  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4865       4192      75  ERX-CERNET-BKB China Education and Rese
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 11492        4541        301     607  CABLEONE, US
 20940        4066       3399     164  AKAMAI-ASN1, NL
  7155        3967        279      48  VIASAT-SP-BACKBONE, US

Complete listing at https://thyme.apnic.net/current/data-ASnet

Global Per AS Maximum Aggregation summary
-----------------------------------------

   ASN  No of nets  Net Savings  Description
  9808        9480         9441  CHINAMOBILE-CN China Mobile Communications Grou
 12479        7237         7088  UNI2-AS, ES
 16509        8240         5334  AMAZON-02, US
  7545        5728         5039  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4865         4790  ERX-CERNET-BKB China Education and Research Net
 39891        4833         4774  ALJAWWALSTC-AS, SA
 11492        4541         3934  CABLEONE, US
  7155        3967         3919  VIASAT-SP-BACKBONE, US
 20940        4066         3902  AKAMAI-ASN1, NL
  8551        3889         3852  BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo

Complete listing at https://thyme.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

    Bad AS  Designation  Net Originated      Transit AS  Transit AS Name
      3507  UNALLOCATED  5.105.166.0/24          213035  AS-SERVERION Serverion B.V.,
    398083  UNALLOCATED  5.133.124.0/24          399587  UT, US
     33492  UNALLOCATED  8.6.184.0/23             33650  COMCAST-33650, US
     33123  UNALLOCATED  8.10.69.0/24             11168  SCC, US
     12169  UNALLOCATED  8.15.207.0/24             3356  LEVEL3, US
     53775  UNALLOCATED  8.20.88.0/24              7029  WINDSTREAM, US
     62828  UNALLOCATED  8.21.130.0/24             3356  LEVEL3, US
    393266  UNALLOCATED  8.23.52.0/24             46887  LIGHTOWER, US
    396894  UNALLOCATED  8.28.201.0/24            46887  LIGHTOWER, US
    394936  UNALLOCATED  8.33.224.0/24            22442  HOU-PHONOSCOPE, US

Complete listing at https://thyme.apnic.net/current/data-badAS

Prefixes from the Special Purpose Address Registry (Global)
-----------------------------------------------------------

Prefix                Origin AS  Description
192.88.99.0/24             6939  HURRICANE, US

Complete listing at https://thyme.apnic.net/current/data-spar

Advertised Unallocated Addresses
--------------------------------

Unassigned Network     ASN Information  AS Name
23.131.185.0/24      Origin:       174  COGENT-174, US
23.131.185.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.186.0/24      Origin:       174  COGENT-174, US
23.131.186.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.187.0/24      Origin:       174  COGENT-174, US
23.131.187.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.188.0/24      Origin:       174  COGENT-174, US
23.131.188.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.136.112.0/24      Origin:     54835  UNASSIGNED
23.136.112.0/24     Transit:     21559  OSNET, PR

Complete listing at https://thyme.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:39      /11:103     /12:299     
/13:578     /14:1198    /15:2034    /16:13480   /17:8257    /18:13837   
/19:25149   /20:44265   /21:51412   /22:109764  /23:97735   /24:549596  
/25:741     /26:0       /27:0       /28:0       /29:0       /30:0       
/31:0       /32:0       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

   ASN  No of nets  Total ann.  Description
 12479        6297        7237  UNI2-AS, ES
  8151        5196       11234  Uninet S.A. de C.V., MX
 39891        3632        4833  ALJAWWALSTC-AS, SA
 11492        3450        4541  CABLEONE, US
  8551        3361        3889  BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo
  6327        3323        3514  SHAW, CA
  7155        3039        3967  VIASAT-SP-BACKBONE, US
 22773        2668        3600  ASN-CXA-ALL-CCI-22773-RDC, US
 30036        2150        2493  MEDIACOM-ENTERPRISE-BUSINESS, US
 10620        2054        3500  Telmex Colombia S.A., CO

Complete listing at https://thyme.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1703      2:1239      3:173       4:5         5:4490      6:128    
   7:6         8:1549      9:1        11:172      12:1548     13:391    
  14:2319     15:299      16:183      17:372      18:415      20:255    
  21:4        22:188      23:6227     24:2586     25:6        27:2489   
  29:19       31:2522     32:89       34:10       35:107      36:1932   
  37:4652     38:4438     39:811      40:151      41:3973     42:988    
  43:2351     44:308      45:16557    46:4265     47:363      49:1757   
  50:1838     51:571      52:1589     54:389      55:858      56:8      
  57:112      58:1757     59:1127     60:972      61:2447     62:2655   
  63:1923     64:5676     65:2320     66:4941     67:3016     68:1367   
  69:4162     70:1252     71:671      72:2968     74:2626     75:1466   
  76:610      77:2435     78:1864     79:3170     80:2095     81:1750   
  82:1486     83:1279     84:1533     85:2995     86:759      87:1986   
  88:1245     89:3613     90:612      91:7699     92:2064     93:2624   
  94:3592     95:4000     96:1328     97:336      98:1157     99:744    
 100:72      101:1071    102:2672    103:31271   104:4652    105:484    
 106:905     107:2526    108:1028    109:4425    110:2080    111:3234   
 112:2061    113:1565    114:1649    115:2022    116:1936    117:2557   
 118:2280    119:2020    120:1795    121:1115    122:2610    123:2160   
 124:1616    125:2524    128:1312    129:1060    130:1016    131:1984   
 132:811     133:422     134:1902    135:304     136:878     137:944    
 138:2550    139:1573    140:1232    141:1460    142:1436    143:1493   
 144:1164    145:347     146:1940    147:1574    148:2350    149:2092   
 150:871     151:1152    152:1844    153:488     154:4398    155:1435   
 156:1797    157:1309    158:1055    159:2287    160:2531    161:1518   
 162:3515    163:1516    164:1624    165:1711    166:1021    167:1723   
 168:3883    169:937     170:4616    171:886     172:3557    173:2940   
 174:1072    175:1153    176:3677    177:4583    178:3585    179:2132   
 180:2422    181:3424    182:3376    183:1930    184:2356    185:20185  
 186:4742    187:3966    188:4106    189:3546    190:9120    191:1435   
 192:10929   193:8865    194:7310    195:5157    196:3094    197:2395   
 198:5956    199:6099    200:8016    201:5852    202:10664   203:10223  
 204:4601    205:3555    206:4148    207:3459    208:4077    209:4867   
 210:4428    211:2487    212:4113    213:3576    214:1083    215:59     
 216:6633    217:2694    218:1295    219:577     220:2016    221:971    
 222:887     223:2184   

End of report

From cb.list6 at gmail.com  Fri Apr 14 21:41:04 2023
From: cb.list6 at gmail.com (Ca By)
Date: Fri, 14 Apr 2023 17:41:04 -0400
Subject: =?UTF-8?Q?Re=3A_RPKI_Mgmt_Changes_at_ARIN_=28was=3A_Fwd=3A_=5Barin=2Dannou?=
 =?UTF-8?Q?nce=5D_Upcoming_Changes_to_ARIN=E2=80=99s_Resource_Public_Key_Infras?=
 =?UTF-8?Q?tructure_=28RPKI=29=29?=
In-Reply-To: <BE7B2E4D-F11F-411B-84B7-EED5AEBFB650@arin.net>
References: <D40C7BEE-820E-499D-A139-D194D55243DF@arin.net>
 <BE7B2E4D-F11F-411B-84B7-EED5AEBFB650@arin.net>
Message-ID: <CAD6AjGRVULne=jGBj4z9QEVNvMG0dF3D=gS8Dw8Uuk8Sf2oc0g@mail.gmail.com>

> **ROA Auto-renewal**
>
> After the May software release, any ROA created via ARIN Online or the new
> RESTful provisioning endpoint will be automatically renewed, meaning all
> newly created ROAs will persist indefinitely until they are manually
> deleted. ARIN will also apply the auto-renew feature to any existing ROAs
> when we deploy this new functionality.
>
> Please note: Any new ROAs created with the legacy RESTful endpoint will
> not be auto-renewed. If you would like your ROAs to be auto-renewed, you
> will need to use ARIN Online or the new RESTful provisioning endpoint. ARIN
> will be contacting customers who have created ROAs in both ARIN Online and
> REST to determine how they prefer to manage their existing ROAs
>
> Thanks John and ARIN team, this auto-renew is a big deal and helps take a
lot of stress off our plates

CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230414/6b358005/attachment.html>

From sean at donelan.com  Fri Apr 14 23:17:23 2023
From: sean at donelan.com (Sean Donelan)
Date: Fri, 14 Apr 2023 19:17:23 -0400 (EDT)
Subject: Backup DC power standardization with Photovoltiac battery systems?
Message-ID: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>


Are broadband CPE (ONTs, CMs, NIDs, etc) manufacturers and PV battery 
wall engineers working on any standardized CPE backup power connectors?

AC/DC/AC & wall wart DC again is inefficient and reduces runtime.

It would be nice if PV/DC battery wall and broadband CPE had a standard DC 
connector instead of the incompatible hacky/proprietary used now. A DC 
bus would be nice, but even the EU regulatory approach of requring a USB-C 
power connector on ONTs and Cable Modems would be a start.

All these darn wall warts are almost, but slightly different (5v, 12v, 
24v).  No -48v CPE?

I have enough EE knowledge to build magic DC boxes, but I would prefer a 
good UL-listed interoperable solution.

From jgreco at ns.sol.net  Sat Apr 15 05:29:12 2023
From: jgreco at ns.sol.net (Joe Greco)
Date: Sat, 15 Apr 2023 00:29:12 -0500
Subject: Backup DC power standardization with Photovoltiac battery systems?
In-Reply-To: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>
References: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>
Message-ID: <20230415052912.GA4115@ns.sol.net>

On Fri, Apr 14, 2023 at 07:17:23PM -0400, Sean Donelan wrote:
> All these darn wall warts are almost, but slightly different (5v, 12v, 
> 24v).  No -48v CPE?

Ubiquiti EdgeRouter PoE 5 can use 48VDC.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

From marka at isc.org  Fri Apr 14 23:40:16 2023
From: marka at isc.org (Mark Andrews)
Date: Sat, 15 Apr 2023 09:40:16 +1000
Subject: DNS resolution for hhs.gov
In-Reply-To: <14d56724-c5ab-dfc0-2950-a25d23812789@dougbarton.us>
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
 <14d56724-c5ab-dfc0-2950-a25d23812789@dougbarton.us>
Message-ID: <CD7365F9-B6BD-4120-8241-2548CF779773@isc.org>



> On 15 Apr 2023, at 02:41, Doug Barton <dougb at dougbarton.us> wrote:
> 
> Responses in line below.
> 
> Doug
> 
> 
> On 4/11/23 8:12 AM, Samuel Jackson wrote:
>> I wanted to run this by everyone to make sure I am not the one losing my mind over this.
>> A dig +trace cob.cms.hhs.gov <http://cob.cms.hhs.gov> fails for me as it looks like the NS for hhs.gov <http://hhs.gov> does not seem to resolve the hostname.
> 
> They shouldn't, since cms.hhs.gov is a delegated subzone. (Also, resolve is the wrong term, since those are authoritative servers, not resolvers.) The hhs.gov name servers are not authoritative for the cms.hhs.gov zone.
> 
> Using `dig +trace cob.cms.hhs.gov` worked for me just now, so it's possible that they fixed something in response to Mark's message.

No, they haven?t.

The problem is that QNAME minimisation asks _.<domain>/A queries to elicit referrals and the servers for hhs.gov don?t respond to them.  Optimally we would ask NS queries but there are delegations where the child NS RRset are complete garbage and in this case hss.gov don?t respond to some of them either over TCP as was shown in the earlier messages.

Telling named to only use TCP with the servers for hss.gov should help.

e.g.
server 158.74.30.99 { tcp-only yes; };

For 'dig +trace? the addresses of the nameservers are looked up and glue is not good enough.  When named
attempts to resolve rh202ns2.355.dhhs.gov and similar the queries it makes do not get responses.

% dig rh202ns2.355.dhhs.gov @158.74.30.99

; <<>> DiG 9.19.11-dev <<>> rh202ns2.355.dhhs.gov @158.74.30.99
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50815
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2636ce7eeb438b88fe1b0a2d6439dcce550e6799df6049a8 (good)
;; QUESTION SECTION:
;rh202ns2.355.dhhs.gov. IN A

;; ANSWER SECTION:
rh202ns2.355.dhhs.gov. 9000 IN A 158.74.30.99

;; Query time: 328 msec
;; SERVER: 158.74.30.99#53(158.74.30.99) (UDP)
;; WHEN: Sat Apr 15 09:07:58 AEST 2023
;; MSG SIZE  rcvd: 94

% dig _.355.dhhs.gov @158.74.30.99
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out

; <<>> DiG 9.19.11-dev <<>> _.355.dhhs.gov @158.74.30.99
;; global options: +cmd
;; no servers could be reached

% dig 355.dhhs.gov ns @158.74.30.99
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out
;; communications error to 158.74.30.99#53: timed out

; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov ns @158.74.30.99
;; global options: +cmd
;; no servers could be reached

% dig 355.dhhs.gov ns @158.74.30.99 +tcp

; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov ns @158.74.30.99 +tcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51550
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 86462f55438e987dd7cd37926439dd174d9cf5907438ce51 (good)
;; QUESTION SECTION:
;355.dhhs.gov. IN NS

;; AUTHORITY SECTION:
dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021761 1200 300 2419200 3600

;; Query time: 351 msec
;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
;; WHEN: Sat Apr 15 09:09:11 AEST 2023
;; MSG SIZE  rcvd: 137

% dig _.355.dhhs.gov @158.74.30.99 +tcp

; <<>> DiG 9.19.11-dev <<>> _.355.dhhs.gov @158.74.30.99 +tcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19166
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 22078767daaad75caba70a826439dd1dcc25d44396d38240 (good)
;; QUESTION SECTION:
;_.355.dhhs.gov. IN A

;; AUTHORITY SECTION:
dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021761 1200 300 2419200 3600

;; Query time: 244 msec
;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
;; WHEN: Sat Apr 15 09:09:17 AEST 2023
;; MSG SIZE  rcvd: 139

% 

At this stage I don?t know if the email I sent earlier has even reached the administrator responsible.  I haven?t seen a response.  It could still be queued on our outbound SMTP servers trying to resolve MX records or their targets.

Also if named times out asking all 8 servers for an in-scope name why should expect to get an answer for a different in-scope name? Playing silly games by not answering consistently just causes issues.

>> However dig +trace cms.hhs.gov <http://cms.hhs.gov> resolves and so does 
> 
> That makes sense, delegated sub zone.  :)
> 
>> dig +trace eclkc.ohs.acf.hhs.gov <http://eclkc.ohs.acf.hhs.gov>
> 
> No delegated sub zones in the path here, so the hhs.gov name servers are authoritative for this host.
> 
>> However if I simply ask my local resolver to resolve cob.cms.hhs.gov <http://cob.cms.hhs.gov>, it works. Any thoughts on why this is the case?
> 
> Because it's getting the answer from the child zone (cms) like it should.
> 
> I'm sort of curious about what `dig +trace` results you received originally that made you believe that you weren't getting the right response. Are you currently seeing what you expect to see?

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org


From sean at donelan.com  Sat Apr 15 01:06:54 2023
From: sean at donelan.com (Sean Donelan)
Date: Fri, 14 Apr 2023 21:06:54 -0400 (EDT)
Subject: Backup DC power standardization with Photovoltiac battery systems?
In-Reply-To: <20230415052912.GA4115@ns.sol.net>
References: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>
 <20230415052912.GA4115@ns.sol.net>
Message-ID: <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>

On Sat, 15 Apr 2023, Joe Greco wrote:
> Ubiquiti EdgeRouter PoE 5 can use 48VDC.

If both PV battery walls and broadband CPE supported Power-Over-Ethernet 
as a backup power source, that would work too.  POE supports greater 
distances than USB-C.

From hank at efes.iucc.ac.il  Sat Apr 15 17:25:00 2023
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Sat, 15 Apr 2023 20:25:00 +0300
Subject: RPKI in Lacnic?
Message-ID: <335aca18-d764-58b9-1da0-88896af3f4cf@efes.iucc.ac.il>

Just got this:


Possible TA malfunction or incomplete VRP file: 100.00% of the ROAs 
disappeared from lacnic

DETAILS:
------------------------------------------------------
Event type:?????????? rpki-diff
When event started:?? 2023-04-15 17:17:30 UTC
Last event:?????????? 2023-04-15 17:17:30 UTC


Only us or everyone?


Thanks,

Hank


From morrowc.lists at gmail.com  Sat Apr 15 18:10:40 2023
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 15 Apr 2023 14:10:40 -0400
Subject: =?UTF-8?Q?Re=3A_RPKI_Mgmt_Changes_at_ARIN_=28was=3A_Fwd=3A_=5Barin=2Dannou?=
 =?UTF-8?Q?nce=5D_Upcoming_Changes_to_ARIN=E2=80=99s_Resource_Public_Key_Infras?=
 =?UTF-8?Q?tructure_=28RPKI=29=29?=
In-Reply-To: <CAD6AjGRVULne=jGBj4z9QEVNvMG0dF3D=gS8Dw8Uuk8Sf2oc0g@mail.gmail.com>
References: <D40C7BEE-820E-499D-A139-D194D55243DF@arin.net>
 <BE7B2E4D-F11F-411B-84B7-EED5AEBFB650@arin.net>
 <CAD6AjGRVULne=jGBj4z9QEVNvMG0dF3D=gS8Dw8Uuk8Sf2oc0g@mail.gmail.com>
Message-ID: <CAL9jLaYSd3sgV2Zve88LE5juxyEaCtJbpkSbCpiTEbpy0PHAwg@mail.gmail.com>

On Fri, Apr 14, 2023 at 5:41?PM Ca By <cb.list6 at gmail.com> wrote:
>
>
>
>>
>> **ROA Auto-renewal**
>>
>> After the May software release, any ROA created via ARIN Online or the new RESTful provisioning endpoint will be automatically renewed, meaning all newly created ROAs will persist indefinitely until they are manually deleted. ARIN will also apply the auto-renew feature to any existing ROAs when we deploy this new functionality.
>>
>> Please note: Any new ROAs created with the legacy RESTful endpoint will not be auto-renewed. If you would like your ROAs to be auto-renewed, you will need to use ARIN Online or the new RESTful provisioning endpoint. ARIN will be contacting customers who have created ROAs in both ARIN Online and REST to determine how they prefer to manage their existing ROAs
>
> Thanks John and ARIN team, this auto-renew is a big deal and helps take a lot of stress off our plates

oh! there's a bunch of pretty good improvements here, thanks! (john
and cameron for raising this mail up in the my stack)

-chris

From jcurran at arin.net  Sat Apr 15 18:26:12 2023
From: jcurran at arin.net (John Curran)
Date: Sat, 15 Apr 2023 18:26:12 +0000
Subject: =?utf-8?B?UmU6IFJQS0kgTWdtdCBDaGFuZ2VzIGF0IEFSSU4gKHdhczogRndkOiBbYXJp?=
 =?utf-8?B?bi1hbm5vdW5jZV0gVXBjb21pbmcgQ2hhbmdlcyB0byBBUklO4oCZcyBSZXNv?=
 =?utf-8?Q?urce_Public_Key_Infrastructure_(RPKI))?=
In-Reply-To: <CAL9jLaYSd3sgV2Zve88LE5juxyEaCtJbpkSbCpiTEbpy0PHAwg@mail.gmail.com>
References: <CAL9jLaYSd3sgV2Zve88LE5juxyEaCtJbpkSbCpiTEbpy0PHAwg@mail.gmail.com>
Message-ID: <D7A25B65-1B78-4918-A720-88683F2A7515@arin.net>

Chris -

Indeed - these are some frequently sought changes that also bring our RPKI interface closer to practices in other regions.

I will note that we do lose something in the process - currently ARIN?s RPKI system has clear non-repudiation attributes (i.e., the issuance of an ROA is assuredly done by the controlling operator [as opposed to a function of ARIN?s automation or staff]) since ARIN never possesses the necessary private key.    Changing to allow easy issuance and rollover appears to be the community?s preference, so we have undertaken the necessary development and process changes.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

> On Apr 15, 2023, at 2:10 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
> 
> ?On Fri, Apr 14, 2023 at 5:41?PM Ca By <cb.list6 at gmail.com> wrote:
>> 
>> 
>> 
>>> 
>>> **ROA Auto-renewal**
>>> 
>>> After the May software release, any ROA created via ARIN Online or the new RESTful provisioning endpoint will be automatically renewed, meaning all newly created ROAs will persist indefinitely until they are manually deleted. ARIN will also apply the auto-renew feature to any existing ROAs when we deploy this new functionality.
>>> 
>>> Please note: Any new ROAs created with the legacy RESTful endpoint will not be auto-renewed. If you would like your ROAs to be auto-renewed, you will need to use ARIN Online or the new RESTful provisioning endpoint. ARIN will be contacting customers who have created ROAs in both ARIN Online and REST to determine how they prefer to manage their existing ROAs
>> 
>> Thanks John and ARIN team, this auto-renew is a big deal and helps take a lot of stress off our plates
> 
> oh! there's a bunch of pretty good improvements here, thanks! (john
> and cameron for raising this mail up in the my stack)
> 
> -chris

From dougb at dougbarton.us  Sat Apr 15 19:31:18 2023
From: dougb at dougbarton.us (Doug Barton)
Date: Sat, 15 Apr 2023 12:31:18 -0700
Subject: DNS resolution for hhs.gov
In-Reply-To: <CD7365F9-B6BD-4120-8241-2548CF779773@isc.org>
References: <CAOAsu-QjOd4ZK75jaS2Hrw6p-O4R5ROvZLwN2quJYBE12pUMPg@mail.gmail.com>
 <14d56724-c5ab-dfc0-2950-a25d23812789@dougbarton.us>
 <CD7365F9-B6BD-4120-8241-2548CF779773@isc.org>
Message-ID: <8346a2f7-d2d5-27a7-28e0-d2a2208166e8@dougbarton.us>

Always love your in-depth analysis. Thanks, Mark.  :)


On 4/14/23 4:40 PM, Mark Andrews wrote:
> 
> 
>> On 15 Apr 2023, at 02:41, Doug Barton <dougb at dougbarton.us> wrote:
>>
>> Responses in line below.
>>
>> Doug
>>
>>
>> On 4/11/23 8:12 AM, Samuel Jackson wrote:
>>> I wanted to run this by everyone to make sure I am not the one losing my mind over this.
>>> A dig +trace cob.cms.hhs.gov <http://cob.cms.hhs.gov> fails for me as it looks like the NS for hhs.gov <http://hhs.gov> does not seem to resolve the hostname.
>>
>> They shouldn't, since cms.hhs.gov is a delegated subzone. (Also, resolve is the wrong term, since those are authoritative servers, not resolvers.) The hhs.gov name servers are not authoritative for the cms.hhs.gov zone.
>>
>> Using `dig +trace cob.cms.hhs.gov` worked for me just now, so it's possible that they fixed something in response to Mark's message.
> 
> No, they haven?t.
> 
> The problem is that QNAME minimisation asks _.<domain>/A queries to elicit referrals and the servers for hhs.gov don?t respond to them.  Optimally we would ask NS queries but there are delegations where the child NS RRset are complete garbage and in this case hss.gov don?t respond to some of them either over TCP as was shown in the earlier messages.
> 
> Telling named to only use TCP with the servers for hss.gov should help.
> 
> e.g.
> server 158.74.30.99 { tcp-only yes; };
> 
> For 'dig +trace? the addresses of the nameservers are looked up and glue is not good enough.  When named
> attempts to resolve rh202ns2.355.dhhs.gov and similar the queries it makes do not get responses.
> 
> % dig rh202ns2.355.dhhs.gov @158.74.30.99
> 
> ; <<>> DiG 9.19.11-dev <<>> rh202ns2.355.dhhs.gov @158.74.30.99
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50815
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 2636ce7eeb438b88fe1b0a2d6439dcce550e6799df6049a8 (good)
> ;; QUESTION SECTION:
> ;rh202ns2.355.dhhs.gov. IN A
> 
> ;; ANSWER SECTION:
> rh202ns2.355.dhhs.gov. 9000 IN A 158.74.30.99
> 
> ;; Query time: 328 msec
> ;; SERVER: 158.74.30.99#53(158.74.30.99) (UDP)
> ;; WHEN: Sat Apr 15 09:07:58 AEST 2023
> ;; MSG SIZE  rcvd: 94
> 
> % dig _.355.dhhs.gov @158.74.30.99
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> 
> ; <<>> DiG 9.19.11-dev <<>> _.355.dhhs.gov @158.74.30.99
> ;; global options: +cmd
> ;; no servers could be reached
> 
> % dig 355.dhhs.gov ns @158.74.30.99
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> 
> ; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov ns @158.74.30.99
> ;; global options: +cmd
> ;; no servers could be reached
> 
> % dig 355.dhhs.gov ns @158.74.30.99 +tcp
> 
> ; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov ns @158.74.30.99 +tcp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51550
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 86462f55438e987dd7cd37926439dd174d9cf5907438ce51 (good)
> ;; QUESTION SECTION:
> ;355.dhhs.gov. IN NS
> 
> ;; AUTHORITY SECTION:
> dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021761 1200 300 2419200 3600
> 
> ;; Query time: 351 msec
> ;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
> ;; WHEN: Sat Apr 15 09:09:11 AEST 2023
> ;; MSG SIZE  rcvd: 137
> 
> % dig _.355.dhhs.gov @158.74.30.99 +tcp
> 
> ; <<>> DiG 9.19.11-dev <<>> _.355.dhhs.gov @158.74.30.99 +tcp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19166
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 22078767daaad75caba70a826439dd1dcc25d44396d38240 (good)
> ;; QUESTION SECTION:
> ;_.355.dhhs.gov. IN A
> 
> ;; AUTHORITY SECTION:
> dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021761 1200 300 2419200 3600
> 
> ;; Query time: 244 msec
> ;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
> ;; WHEN: Sat Apr 15 09:09:17 AEST 2023
> ;; MSG SIZE  rcvd: 139
> 
> %
> 
> At this stage I don?t know if the email I sent earlier has even reached the administrator responsible.  I haven?t seen a response.  It could still be queued on our outbound SMTP servers trying to resolve MX records or their targets.
> 
> Also if named times out asking all 8 servers for an in-scope name why should expect to get an answer for a different in-scope name? Playing silly games by not answering consistently just causes issues.
> 
>>> However dig +trace cms.hhs.gov <http://cms.hhs.gov> resolves and so does
>>
>> That makes sense, delegated sub zone.  :)
>>
>>> dig +trace eclkc.ohs.acf.hhs.gov <http://eclkc.ohs.acf.hhs.gov>
>>
>> No delegated sub zones in the path here, so the hhs.gov name servers are authoritative for this host.
>>
>>> However if I simply ask my local resolver to resolve cob.cms.hhs.gov <http://cob.cms.hhs.gov>, it works. Any thoughts on why this is the case?
>>
>> Because it's getting the answer from the child zone (cms) like it should.
>>
>> I'm sort of curious about what `dig +trace` results you received originally that made you believe that you weren't getting the right response. Are you currently seeing what you expect to see?
> 

From massimo at ntt.net  Sat Apr 15 18:09:17 2023
From: massimo at ntt.net (Massimo Candela)
Date: Sat, 15 Apr 2023 20:09:17 +0200
Subject: RPKI in Lacnic?
In-Reply-To: <335aca18-d764-58b9-1da0-88896af3f4cf@efes.iucc.ac.il>
References: <335aca18-d764-58b9-1da0-88896af3f4cf@efes.iucc.ac.il>
Message-ID: <c57b55a6-39d0-aa94-c389-1a3785ca11ad@ntt.net>

Hi Hank,

On 15/04/2023 02:25, Hank Nussbacher wrote:
> Just got this:
> 
> 
> Possible TA malfunction or incomplete VRP file: 100.00% of the ROAs 
> disappeared from lacnic
> 
> DETAILS:
> ------------------------------------------------------
> Event type:?????????? rpki-diff
> When event started:?? 2023-04-15 17:17:30 UTC
> Last event:?????????? 2023-04-15 17:17:30 UTC
> 
> 
> Only us or everyone?


Visible also on rpki-client.org, ntt, and cloudflare public vrps.

Reported both by BGPalerter and PacketVis: 
https://packetvis.com/bgp/event/e248290619cceb560b9b670c3a72e6f8-84dcd47f-7273-47bf-9612-23a10ccfaad3/08d06fc38849a8c328c5d90c521815abb03995ae

I contacted the LACNIC staff and they are working on it.

Ciao,
Massimo

From padnezz at gmail.com  Sat Apr 15 17:37:18 2023
From: padnezz at gmail.com (=?UTF-8?Q?Andr=C3=A9_Pettersson?=)
Date: Sat, 15 Apr 2023 19:37:18 +0200
Subject: RPKI in Lacnic?
In-Reply-To: <335aca18-d764-58b9-1da0-88896af3f4cf@efes.iucc.ac.il>
References: <335aca18-d764-58b9-1da0-88896af3f4cf@efes.iucc.ac.il>
Message-ID: <CAFD3jYu7wBVqJ1U1P8GACuz6ux6mBSScpvhFd5pKACW5oVJ00Q@mail.gmail.com>

Got it also just now.

//Andr? Pettersson


Den l?r 15 apr. 2023 19:27Hank Nussbacher <hank at efes.iucc.ac.il> skrev:

> Just got this:
>
>
> Possible TA malfunction or incomplete VRP file: 100.00% of the ROAs
> disappeared from lacnic
>
> DETAILS:
> ------------------------------------------------------
> Event type:           rpki-diff
> When event started:   2023-04-15 17:17:30 UTC
> Last event:           2023-04-15 17:17:30 UTC
>
>
> Only us or everyone?
>
>
> Thanks,
>
> Hank
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230415/0a13ec4d/attachment.html>

From nanog at ics-il.net  Sun Apr 16 17:02:03 2023
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 16 Apr 2023 12:02:03 -0500 (CDT)
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
References: <772176682.250.1680499285558.JavaMail.mhammett@Thunderfuck2>
Message-ID: <912035563.405.1681664522392.JavaMail.mhammett@Thunderfuck2>

We did have our common upstream provider perform maintenance that then afterwards, had the traffic flowing on the right path. Later activity on our direct connection pushed it back to the common upstream. We haven't yet had the opportunity to bump our BGP session with the common upstream provider, but I suspect that will put the traffic back onto the right path. Seems like the router is just hanging onto the oldest BGP session it has, regardless of any other parameter or configuration. 


This seems like a bug. We do intend on upgrading NX-OS, but that's on someone else's schedule. 



----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

----- Original Message -----

From: "Mike Hammett" <nanog at ics-il.net> 
To: "NANOG" <nanog at nanog.org> 
Sent: Monday, April 3, 2023 12:21:29 AM 
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging 


We have a Nexus 3064 that is setup with partial BGP tables and is routing based on that. 


I've done a show ip bgp for an IP of interest and it has an expected next hop IP. I show ip arp on that next hop IP and it has the expected interface. 


However, sFlows show the packets leaving on a different interface, the one that would carry the default route for routes not otherwise known. 


If the next hop IP is expected and the ARP of that next hop IP is expected, why are packets leaving out an unexpected interface? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230416/21bba6a6/attachment.html>

From joelja at bogus.com  Sun Apr 16 21:04:32 2023
From: joelja at bogus.com (Joelja Bogus)
Date: Sun, 16 Apr 2023 14:04:32 -0700
Subject: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
In-Reply-To: <912035563.405.1681664522392.JavaMail.mhammett@Thunderfuck2>
References: <912035563.405.1681664522392.JavaMail.mhammett@Thunderfuck2>
Message-ID: <523D7CBD-29C5-4869-BDB1-5B20650A1236@bogus.com>

An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230416/7d113f37/attachment.html>

From josh at imaginenetworksllc.com  Mon Apr 17 13:31:54 2023
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Mon, 17 Apr 2023 09:31:54 -0400
Subject: Backup DC power standardization with Photovoltiac battery systems?
In-Reply-To: <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>
References: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>
 <20230415052912.GA4115@ns.sol.net>
 <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>
Message-ID: <CAN9qwJ_tpezt5ap8WSk+NsQ95K=-JWT5H0g3civBdGPt2GKDHg@mail.gmail.com>

Simple answer:  No.

Customer routers and CPEs are a mix match of a) voltage - 5v, 9v, 12v, etc
and b) connector - dc barrel, USB, molex, etc.  Fixed wireless and fiber
for certain and I have to assume it's the same story with DSL/cable.

On Fri, Apr 14, 2023 at 9:06?PM Sean Donelan <sean at donelan.com> wrote:

> On Sat, 15 Apr 2023, Joe Greco wrote:
> > Ubiquiti EdgeRouter PoE 5 can use 48VDC.
>
> If both PV battery walls and broadband CPE supported Power-Over-Ethernet
> as a backup power source, that would work too.  POE supports greater
> distances than USB-C.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230417/0331dd7f/attachment.html>

From cb.list6 at gmail.com  Mon Apr 17 22:01:51 2023
From: cb.list6 at gmail.com (Ca By)
Date: Mon, 17 Apr 2023 15:01:51 -0700
Subject: Brightcloud geolocation fail
Message-ID: <CAD6AjGRgJgpVu-HhUUOwMk88WHeTmyGOC=6sMJ=J8_b7g9o05Q@mail.gmail.com>

Folks,

I reached out to Brightcloud directly and they cant fix this and it has
been 3 weeks.  What can i say besides don?t use them.

https://whois.domaintools.com/172.59.72.103

They are locating 172.32.0.0/11 , which belongs to T-Mobile USA for 10+
years? to China.  There is no reason for them to do this. We have our
geofeed links and ARIN data correct, no changes ?

Brightcloud, please fix your stuff: Support Ticket Number: 82871

Everyone else, don?t use geo-policies to block things, and if you do, don?t
use Brightcloud / Opentext

I heard this negatively impacts Microsoft o365 and Azure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230417/a8344589/attachment.html>

From sean at donelan.com  Tue Apr 18 06:41:26 2023
From: sean at donelan.com (Sean Donelan)
Date: Tue, 18 Apr 2023 02:41:26 -0400 (EDT)
Subject: Backup DC power standardization with Photovoltiac battery systems?
In-Reply-To: <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>
References: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>
 <20230415052912.GA4115@ns.sol.net>
 <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>
Message-ID: <ss5s0o10-3o4o-8roq-3p65-r5q470o2q402@qbaryna.pbz>

> If both PV battery walls and broadband CPE supported Power-Over-Ethernet as a 
> backup power source, that would work too.  POE supports greater distances 
> than USB-C.

I'd prefer broadband CPE (UL listed) with a standardized backup power 
connector (doesn't exist, but I can dream).

For DIYers, building their own magic box to convert from their powerwall 
to backup low-voltage small devices.  This was one of the few DIYers who 
include appropriate fuses in their design.  Too many Youtube DIYers treat 
low-voltage as harmless and don't include safety devices.

I've seen the after-effects of a few DC/Inverter plant meltdowns.  When I 
used to visit IXPs and data centers, all of them seemed to have at least 
one melted, metal wrench :-)


https://www.youtube.com/watch?v=xsZzlF_NA6E
https://projectswithdave.com/48v-to-12v-dc-dc-converter-project-build/

From manoj.adhikari.bt at gmail.com  Tue Apr 18 06:11:54 2023
From: manoj.adhikari.bt at gmail.com (Manoj Adhikari)
Date: Tue, 18 Apr 2023 12:11:54 +0600
Subject: CALL FOR PRESENTATIONS - btNOG10 (2023), Paro, Bhutan.
Message-ID: <CAEmnQeJzi56bHd5CWLXnQfbB87Qn2QDpebLZ2Oo-p2d2i7_USg@mail.gmail.com>

Dear All


The following is an open call for presentations for the conference session
for the 10th Bhutan

Network Operators Group (btNOG) Meeting being hosted in-person from *5-9
June at Paro, Bhutan*.

Important dates regarding the Call for Presentations:


   - Call For Presentations Open: Now
   - First Draft Programme Published: 22 May 2023
   - Deadline For Proposals: 22 May 2023
   - Final acceptance notification: 22 May 2023
   - btNOG10 Workshops: 5-8 June 2023
   - btNOG10 Conference: 9 June 2023

Please submit it online at the link below.

*https://papers.apricot.net/user/login.php?event=176
<https://papers.apricot.net/user/login.php?event=176>*

Note: Any marketing, sales, and vendor proprietary content in presentation
is against the spirit of btNOG and it is strictly prohibited.

Presentations will be accepted on a first come first served basis ? so it
is important not to delay submitting if you wish to secure a presentation
slot.

The btNOG10 conference will be a one-day event that includes technical
sessions and possibly a panel discussion.

These are general sessions, and you are invited to propose talks that you
think are relevant to the Internet operational and research community. The
topics given below are not exclusive.

Presentations are expected to be no more than 30 minutes long and with
suitable technical and operational content.

   - IPv4 / IPv6 Routing and Operations
   - Routing Security, including RPKI and MANRS
   - Internet backbone operations
   - Peering, Interconnects and IXPs
   - Content Distribution Network technology &amp; operations
   - Research on Internet Operations and Deployment
   - Pandemic impact on network deployment and operations
   - Network Virtualisation
   - Network Automation/Programming
   - Network Infrastructure security
   - IPv6 deployment on fixed and Wireless/Cellular networks
   - DNS / DNSSEC and KINDNS
   - Access and Transport Technologies
   - Technical application of Web 3.0, public blockchains and cryptocurrency
   - Content & Service Delivery and
   - Cloud Computing

Submissions

Draft slides MUST be provided with submissions otherwise the Program
Committee will be unable to review the submission. For work in progress,
the most current information available at the time of submission is
acceptable.

All draft slides submitted for PC review must be in PDF or PPT format only.
The btNOG10 conference will be conducted in English. btNOG10 conference
will strive to provide the features to allow remote participation. However,
we encourage you to speak at the conference in person for the purpose of
allowing the audience to actively engage in the discussions.

Any questions or concerns should be addressed to the btNOG10 Program
Committee by email.

We look forward to welcoming you at btNOG10.

Best Regards

[image: photo]
Manoj Adhikari
Coordination Team Member - btNOG10

M   +975 77102200
P   +975 2 322828
E   manoj.adhikari.bt at gmail.com
W   +975 77102200
[image: facebook] <https://www.facebook.com/manojmjadhikari> [image:
linkedin] <https://www.linkedin.com/in/manojmjadhikari/> [image: twitter]
<https://twitter.com/ManoJonaM> [image: instagram]
<https://www.instagram.com/manoj_mj_adhikari/>
[image: App Social Buttons Image] <https://www.facebook.com/manojmjadhikari>
[image: App Social Buttons Image]
<https://www.linkedin.com/in/manojmjadhikari/>  [image: App Social Buttons
Image] <https://twitter.com/ManoJonaM>

Create your own email signature
<https://www.wisestamp.com/create-own-email-signature/?utm_source=promotion&utm_medium=signature&utm_campaign=create_your_own&srcid=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230418/ba80a80f/attachment.html>

From mark at tinka.africa  Wed Apr 19 13:56:28 2023
From: mark at tinka.africa (Mark Tinka)
Date: Wed, 19 Apr 2023 15:56:28 +0200
Subject: Backup DC power standardization with Photovoltiac battery systems?
In-Reply-To: <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>
References: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>
 <20230415052912.GA4115@ns.sol.net>
 <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>
Message-ID: <b49afb40-1e2e-1147-e208-13bda85ddda6@tinka.africa>



On 4/15/23 03:06, Sean Donelan wrote:

> If both PV battery walls and broadband CPE supported 
> Power-Over-Ethernet as a backup power source, that would work too.? 
> POE supports greater distances than USB-C.

Well, you generally want to only power your devices off the battery if 
you are unable to generate power from PV, or if you have a grid outage.

The other issue is if you also want to use the grid as a charge source 
for the battery, you are going to need an inverter, in which case 
attaching DC loads to a DC bus that contains both the battery and a 
standard, el-cheapo hybrid inverter makes things tricky.

If you don't want to use the grid for anything, then your main source of 
charge current would be PV. If it's a 48V battery, you will need 
something else to step that voltage down for devices on the DC bus that 
require less than 48VDC.

Mark.


From mark at tinka.africa  Wed Apr 19 14:09:02 2023
From: mark at tinka.africa (Mark Tinka)
Date: Wed, 19 Apr 2023 16:09:02 +0200
Subject: Backup DC power standardization with Photovoltiac battery systems?
In-Reply-To: <ss5s0o10-3o4o-8roq-3p65-r5q470o2q402@qbaryna.pbz>
References: <pnq7n2r4-89nq-n8q0-r6pr-sq95prs7n58q@qbaryna.pbz>
 <20230415052912.GA4115@ns.sol.net>
 <2q0n1ps2-08o3-p425-4074-q1n5160rq8o2@qbaryna.pbz>
 <ss5s0o10-3o4o-8roq-3p65-r5q470o2q402@qbaryna.pbz>
Message-ID: <820f41f6-c21d-d1d1-9ce8-356e4bb1551a@tinka.africa>



On 4/18/23 08:41, Sean Donelan wrote:

>
> I'd prefer broadband CPE (UL listed) with a standardized backup power 
> connector (doesn't exist, but I can dream).

Out here, most people use this to keep CPE going when the power is out:

https://www.takealot.com/gizzu-8800mah-mini-ups-dual-dc/PLID71930088?gclid=CjwKCAjwov6hBhBsEiwAvrvN6Bwdu_8uBXMXa8pC475Hd6H4Aa_fUyYeDkYg13Q-j6tkjWCGHqAFYBoC26UQAvD_BwE&gclsrc=aw.ds

Nice, compact, neat package that is portable and will give reasonable 
backup time when needed.

For CO or data centre applications, most gear should be good for 48V. If 
it's lower than that and you have a ton of them, you are probably better 
off with a protected AC source.

Mark.

From dhubbard at dino.hostasaurus.com  Wed Apr 19 16:21:33 2023
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 19 Apr 2023 16:21:33 +0000
Subject: Any Frontier AS 5650 folks on here?
Message-ID: <F61D2EE5-8E13-467F-97D9-90F5AA5D08FC@dino.hostasaurus.com>

Have spent 90 minutes with tech support trying to get a peering issue a few hundred miles away in front of the right department, and all I have to show for it is broken local equipment lol.

Thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230419/4b6e0484/attachment.html>

From jeff.richmond at gmail.com  Wed Apr 19 16:24:45 2023
From: jeff.richmond at gmail.com (Jeff Richmond)
Date: Wed, 19 Apr 2023 09:24:45 -0700
Subject: Any Frontier AS 5650 folks on here?
In-Reply-To: <F61D2EE5-8E13-467F-97D9-90F5AA5D08FC@dino.hostasaurus.com>
References: <F61D2EE5-8E13-467F-97D9-90F5AA5D08FC@dino.hostasaurus.com>
Message-ID: <AC0B1FA8-B0A2-4D04-8913-07445DB8C92F@gmail.com>

David, reply to me off list and I will see if I can help you out.

Thanks,
-Jeff

> On Apr 19, 2023, at 9:21 AM, David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
> 
> Have spent 90 minutes with tech support trying to get a peering issue a few hundred miles away in front of the right department, and all I have to show for it is broken local equipment lol.
>  
> Thanks,
>  
> David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230419/e69e5865/attachment.html>

From lists at packetflux.com  Fri Apr 21 09:38:29 2023
From: lists at packetflux.com (Forrest Christian (List Account))
Date: Fri, 21 Apr 2023 03:38:29 -0600
Subject: Reverse DNS for eyeballs?
Message-ID: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>

I have a feeling that I might be stepping into a can of worms by asking
this,  but..

What's the current thinking around reverse DNS on IPs used by typical
residential/ small business customers.

Way way back in the day I used to generate "filler" reverse dns for all of
these ranges ..  that is, records like "45.100.51.198.in-addr.arpa IN PTR
198-51-100?45.dialup.example.com", and then add a forward A record to
match.   We had a procedure to override this generic domain upon customer
request when a static IP was assigned, such as for a mail server.

As time has marched on, and other people were responsible for the reverse
dns zones,  cruft from old customers no longer with us has accumulated in
the reverse DNS override file  and I recently discovered that many newer
ranges are either nonexistent or not updated.  As I'm in the process of
cleaning up several other related messes, I'm feeling I should clean this
one up too.

I've kinda felt for a while now that reverse dns isn't really needed for
the customer IPs but before I dump the whole thing overboard and switch to
returning NXDOMAIN unless the customer really needs a reverse dns record I
figured I'd ask what the current thinking is for these among the internet
community.

I'm not talking about reverse dns for  infrastructure/router IPs here,  as
I still feel those need to be kept up to date.  This is just for the
individual end user IPs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230421/531efcac/attachment.html>

From woody at pch.net  Fri Apr 21 09:46:54 2023
From: woody at pch.net (Bill Woodcock)
Date: Fri, 21 Apr 2023 11:46:54 +0200
Subject: Reverse DNS for eyeballs?
In-Reply-To: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
Message-ID: <C0407646-0A16-4632-B490-6AF22A554A4C@pch.net>

> On Apr 21, 2023, at 11:38 AM, Forrest Christian (List Account) <lists at packetflux.com> wrote:
> What's the current thinking around reverse DNS on IPs used by typical residential/ small business customers?
> I'm not talking about reverse dns for  infrastructure/router IPs here,  as I still feel those need to be kept up to date.  This is just for the individual end user IPs.

I think it?s really useful?  but as IPv4 becomes a thing of the past, it probably needs to be supplied dynamically by a plug-in to your nameserver, rather than in giant static tables.

                                -Bill



From cma at cmadams.net  Fri Apr 21 12:37:49 2023
From: cma at cmadams.net (Chris Adams)
Date: Fri, 21 Apr 2023 07:37:49 -0500
Subject: Reverse DNS for eyeballs?
In-Reply-To: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
Message-ID: <20230421123749.GB3279@cmadams.net>

Once upon a time, Forrest Christian (List Account) <lists at packetflux.com> said:
> I have a feeling that I might be stepping into a can of worms by asking
> this,  but..
> 
> What's the current thinking around reverse DNS on IPs used by typical
> residential/ small business customers.

I don't see any benefit to programmatically-generated reverse DNS.  I
stopped setting it up a long time ago now.  Really, reverse DNS these
days is mostly only useful for:

- mail servers (where it shows a modicum of control and clue)
- infrastructure/router IPs (so mtr/traceroute can show useful info)

-- 
Chris Adams <cma at cmadams.net>

From geier at geier.ne.tz  Fri Apr 21 13:02:14 2023
From: geier at geier.ne.tz (Frank Habicht)
Date: Fri, 21 Apr 2023 16:02:14 +0300
Subject: Reverse DNS for eyeballs?
In-Reply-To: <20230421123749.GB3279@cmadams.net>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
Message-ID: <cf5376dd-572a-0e30-76d0-6d9ed4bda360@geier.ne.tz>

On 21/04/2023 15:37, Chris Adams wrote:
> I don't see any benefit to programmatically-generated reverse DNS.  I
> stopped setting it up a long time ago now.  Really, reverse DNS these
> days is mostly only useful for:
> 
> - mail servers (where it shows a modicum of control and clue)
> - infrastructure/router IPs (so mtr/traceroute can show useful info)

I would say the absence of reverse DNS tells useful info to receiving 
MTAs - to preferably not accept.

Frank


From cb.list6 at gmail.com  Fri Apr 21 13:04:32 2023
From: cb.list6 at gmail.com (Ca By)
Date: Fri, 21 Apr 2023 06:04:32 -0700
Subject: Reverse DNS for eyeballs?
In-Reply-To: <20230421123749.GB3279@cmadams.net>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
Message-ID: <CAD6AjGTZK+VxzFtB9bWUcjqbofmKQ++rtCDdHB4nKJJ6NGx+Gw@mail.gmail.com>

On Fri, Apr 21, 2023 at 5:40 AM Chris Adams <cma at cmadams.net> wrote:

> Once upon a time, Forrest Christian (List Account) <lists at packetflux.com>
> said:
> > I have a feeling that I might be stepping into a can of worms by asking
> > this,  but..
> >
> > What's the current thinking around reverse DNS on IPs used by typical
> > residential/ small business customers.
>
> I don't see any benefit to programmatically-generated reverse DNS.  I
> stopped setting it up a long time ago now.  Really, reverse DNS these
> days is mostly only useful for:
>
> - mail servers (where it shows a modicum of control and clue)
> - infrastructure/router IPs (so mtr/traceroute can show useful info)
>

Same


> --
> Chris Adams <cma at cmadams.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230421/c55a3c55/attachment.html>

From mark at tinka.africa  Fri Apr 21 13:29:48 2023
From: mark at tinka.africa (Mark Tinka)
Date: Fri, 21 Apr 2023 15:29:48 +0200
Subject: Reverse DNS for eyeballs?
In-Reply-To: <cf5376dd-572a-0e30-76d0-6d9ed4bda360@geier.ne.tz>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
 <cf5376dd-572a-0e30-76d0-6d9ed4bda360@geier.ne.tz>
Message-ID: <8c72f689-6dfe-96ad-3182-031f58c68dee@tinka.africa>



On 4/21/23 15:02, Frank Habicht wrote:

>
> I would say the absence of reverse DNS tells useful info to receiving 
> MTAs - to preferably not accept.

As does a randomly-generated one...

Mark.

From mark at tinka.africa  Fri Apr 21 13:30:27 2023
From: mark at tinka.africa (Mark Tinka)
Date: Fri, 21 Apr 2023 15:30:27 +0200
Subject: Reverse DNS for eyeballs?
In-Reply-To: <20230421123749.GB3279@cmadams.net>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
Message-ID: <58d8d76a-cde5-87bc-2b10-017fce41fcdf@tinka.africa>



On 4/21/23 14:37, Chris Adams wrote:

> I don't see any benefit to programmatically-generated reverse DNS.  I
> stopped setting it up a long time ago now.  Really, reverse DNS these
> days is mostly only useful for:
>
> - mail servers (where it shows a modicum of control and clue)
> - infrastructure/router IPs (so mtr/traceroute can show useful info)

Agreed.

Mark.

From lukas at ltri.eu  Fri Apr 21 14:03:17 2023
From: lukas at ltri.eu (Lukas Tribus)
Date: Fri, 21 Apr 2023 16:03:17 +0200
Subject: Reverse DNS for eyeballs?
In-Reply-To: <CAD6AjGTZK+VxzFtB9bWUcjqbofmKQ++rtCDdHB4nKJJ6NGx+Gw@mail.gmail.com>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
 <CAD6AjGTZK+VxzFtB9bWUcjqbofmKQ++rtCDdHB4nKJJ6NGx+Gw@mail.gmail.com>
Message-ID: <CACC_My_2M7hO4R+7OJLj4-i8MeMymRBRNnJe63jm1ZZ23qeVjw@mail.gmail.com>

Hello,


without PTRs you will probably get your prefixes listed in things like
Spamhouse PBL. So adding the correct PTR for a mailserver may not be
enough, as services like that love to classify entire IP blocks. Of
course Spamhaus provides the tools to fix this issue. But what if
there are 4 - 5 other services like that? Do you want to go down that
rabbit hole, everytime you turn up a mailserver in your prefix?

I also think reverse DNS records are useful when you have discussions
with content providers for all sorts of reasons like geolocation
issues or "VPN" classifications.

Of course whois/irr records are the proper tools for this. But if I
have to discuss my IP ranges with some first level support desk at a
large content provider, everything that stands out negatively will
impact my chances of actually getting it done and how fast it will get
done.


Considering how subjective IP classifications are, I will not return
NXDOMAIN for v4 addresses if there is even a small chance that it will
make my life harder at some point in the future.


Lukas

From heas at shrubbery.net  Fri Apr 21 15:31:12 2023
From: heas at shrubbery.net (heasley)
Date: Fri, 21 Apr 2023 15:31:12 +0000
Subject: Reverse DNS for eyeballs?
In-Reply-To: <20230421123749.GB3279@cmadams.net>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
Message-ID: <ZEKsQLPHMKc3Y07h@shrubbery.net>

Fri, Apr 21, 2023 at 07:37:49AM -0500, Chris Adams:
> Once upon a time, Forrest Christian (List Account) <lists at packetflux.com> said:
> > I have a feeling that I might be stepping into a can of worms by asking
> > this,  but..
> > 
> > What's the current thinking around reverse DNS on IPs used by typical
> > residential/ small business customers.
> 
> I don't see any benefit to programmatically-generated reverse DNS.  I
> stopped setting it up a long time ago now.  Really, reverse DNS these
> days is mostly only useful for:
> 
> - mail servers (where it shows a modicum of control and clue)
> - infrastructure/router IPs (so mtr/traceroute can show useful info)

I view complete DNS coverage to be a basic function.  All used addresses
should have forward and matching reverse records.  This is not difficult
stuff.  Bonus points for including a clli code or similar indicating the
general location of use for uses like network device interfaces, commodity
end-users, etc; also not difficult stuff.

You are tracking your allocations, right?  Programmatically generating
your device configurations?  So, generate DNS from that same database(s).

From jhealy at suffieldacademy.org  Fri Apr 21 17:01:48 2023
From: jhealy at suffieldacademy.org (Jason Healy)
Date: Fri, 21 Apr 2023 17:01:48 +0000
Subject: Reverse DNS for eyeballs?
In-Reply-To: <ZEKsQLPHMKc3Y07h@shrubbery.net>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net> <ZEKsQLPHMKc3Y07h@shrubbery.net>
Message-ID: <SA1PR15MB4856D2EE91F5BB0F385A4D85C9609@SA1PR15MB4856.namprd15.prod.outlook.com>

> I view complete DNS coverage to be a basic function.  All used addresses
> should have forward and matching reverse records.

This is not intended as snark: what do people recommend for IPv6?  I try to maintain forward/reverse for all my server/infrastructure equipment.  But clients?  They're making up temporary addresses all day long.  So far, I've given up on trying to keep track of those addresses, even though it's a network under my direct control.

Thanks,

Jason

From cma at cmadams.net  Fri Apr 21 17:54:11 2023
From: cma at cmadams.net (Chris Adams)
Date: Fri, 21 Apr 2023 12:54:11 -0500
Subject: Reverse DNS for eyeballs?
In-Reply-To: <ZEKsQLPHMKc3Y07h@shrubbery.net>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
 <ZEKsQLPHMKc3Y07h@shrubbery.net>
Message-ID: <20230421175411.GF3279@cmadams.net>

Once upon a time, heasley <heas at shrubbery.net> said:
> I view complete DNS coverage to be a basic function.  All used addresses
> should have forward and matching reverse records.

But why?  It's not like anybody can trust what's in a reverse DNS
string, even if it has matching forward.  If I'm looking for
"ownership", I'm going to registries, not DNS.  Since it can't be
guaranteed (or even flagged as) maintained, you can't trust any
information in that string.

-- 
Chris Adams <cma at cmadams.net>

From cscora at apnic.net  Fri Apr 21 18:03:31 2023
From: cscora at apnic.net (Routing Table Analysis Role Account)
Date: Sat, 22 Apr 2023 04:03:31 +1000 (AEST)
Subject: Weekly Global IPv4 Routing Table Report
Message-ID: <20230421180331.E4ACCC1134@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the 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 bgp-stats at lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

IPv4 Routing Table Report   04:00 +10GMT Sat 22 Apr, 2023

  BGP Table (Global) as seen in Japan.

Report Website:     https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              918940
    Prefixes after maximum aggregation (per Origin AS):          348842
    Deaggregation factor:                                          2.63
    Unique aggregates announced (without unneeded subnets):      448780
Total ASes present in the Internet Routing Table:                 74349
    Prefixes per ASN:                                             12.36
Origin-only ASes present in the Internet Routing Table:           63776
Origin ASes announcing only one prefix:                           26197
Transit ASes present in the Internet Routing Table:               10573
Transit-only ASes present in the Internet Routing Table:            439
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      55
    Max AS path prepend of ASN (265020)                              50
Prefixes from unregistered ASNs in the Routing Table:              1361
    Number of instances of unregistered ASNs:                      1361
Number of 32-bit ASNs allocated by the RIRs:                      41703
Number of 32-bit ASNs visible in the Routing Table:               34496
Prefixes from 32-bit ASNs in the Routing Table:                  170505
Number of bogon 32-bit ASNs visible in the Routing Table:            13
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            857
Number of addresses announced to Internet:                   3061027072
    Equivalent to 182 /8s, 115 /16s and 145 /24s
    Percentage of available address space announced:               82.7
    Percentage of allocated address space announced:               82.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               99.6
Total number of prefixes smaller than registry allocations:      307074

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   242581
    Total APNIC prefixes after maximum aggregation:               69276
    APNIC Deaggregation factor:                                    3.50
Prefixes being announced from the APNIC address blocks:          236874
    Unique aggregates announced from the APNIC address blocks:    97897
APNIC Region origin ASes present in the Internet Routing Table:   13392
    APNIC Prefixes per ASN:                                       17.69
APNIC Region origin ASes announcing only one prefix:               3937
APNIC Region transit ASes present in the Internet Routing Table:   1801
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         32
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8693
Number of APNIC addresses announced to Internet:              773697152
    Equivalent to 46 /8s, 29 /16s and 174 /24s
APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    268810
    Total ARIN prefixes after maximum aggregation:               122340
    ARIN Deaggregation factor:                                     2.20
Prefixes being announced from the ARIN address blocks:           271345
    Unique aggregates announced from the ARIN address blocks:    130919
ARIN Region origin ASes present in the Internet Routing Table:    19084
    ARIN Prefixes per ASN:                                        14.22
ARIN Region origin ASes announcing only one prefix:                6957
ARIN Region transit ASes present in the Internet Routing Table:    1960
Average ARIN Region AS path length visible:                         3.7
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:    4790
Number of ARIN addresses announced to Internet:              1284384768
    Equivalent to 76 /8s, 142 /16s and 40 /24s
ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-401308
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  47/8,  48/8,  50/8,  52/8,  53/8,
                        54/8,  55/8,  56/8,  57/8,  63/8,  64/8,  65/8,
                        66/8,  67/8,  68/8,  69/8,  70/8,  71/8,  72/8,
                        73/8,  74/8,  75/8,  76/8,  96/8,  97/8,  98/8,
                        99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8,
                       130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8,
                       138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8,
                       147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8,
                       158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8,
                       166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8,
                       174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8,
                       206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8,
                      

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    259272
    Total RIPE prefixes after maximum aggregation:               122099
    RIPE Deaggregation factor:                                     2.12
Prefixes being announced from the RIPE address blocks:           255283
    Unique aggregates announced from the RIPE address blocks:    157840
RIPE Region origin ASes present in the Internet Routing Table:    28311
    RIPE Prefixes per ASN:                                         9.02
RIPE Region origin ASes announcing only one prefix:               12055
RIPE Region transit ASes present in the Internet Routing Table:    3968
Average RIPE Region AS path length visible:                         4.2
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:   11152
Number of RIPE addresses announced to Internet:               717903232
    Equivalent to 42 /8s, 202 /16s and 85 /24s
RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 64396-64495
                       196608-213403
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                  117706
    Total LACNIC prefixes after maximum aggregation:              28516
    LACNIC Deaggregation factor:                                   4.13
Prefixes being announced from the LACNIC address blocks:         116976
    Unique aggregates announced from the LACNIC address blocks:   49247
LACNIC Region origin ASes present in the Internet Routing Table:  10982
    LACNIC Prefixes per ASN:                                      10.65
LACNIC Region origin ASes announcing only one prefix:              2638
LACNIC Region transit ASes present in the Internet Routing Table:  2301
Average LACNIC Region AS path length visible:                       5.0
    Max LACNIC Region AS path length visible:                        55
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  8773
Number of LACNIC addresses announced to Internet:             176780544
    Equivalent to 10 /8s, 137 /16s and 117 /24s
LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-273820 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  29210
    Total AfriNIC prefixes after maximum aggregation:              5806
    AfriNIC Deaggregation factor:                                  5.03
Prefixes being announced from the AfriNIC address blocks:         37605
    Unique aggregates announced from the AfriNIC address blocks:  12289
AfriNIC Region origin ASes present in the Internet Routing Table:  1743
    AfriNIC Prefixes per ASN:                                     21.57
AfriNIC Region origin ASes announcing only one prefix:              610
AfriNIC Region transit ASes present in the Internet Routing Table:  341
Average AfriNIC Region AS path length visible:                      4.9
    Max AfriNIC Region AS path length visible:                       30
Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1088
Number of AfriNIC addresses announced to Internet:            107590144
    Equivalent to 6 /8s, 105 /16s and 178 /24s
AfriNIC AS Blocks      36864-37887, 327680-329727 & ERX transfers
AfriNIC Address Blocks  41/8,  45/8, 102/8, 105/8, 154/8, 196/8, 197/8,
                      

APNIC Region per AS prefix count summary
----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  9808        9481       8706      40  CHINAMOBILE-CN China Mobile Communicati
  7545        5727        786     691  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4859       4192      75  ERX-CERNET-BKB China Education and Rese
  7713        3546       1043      65  TELKOMNET-AS-AP PT Telekomunikasi Indon
 45899        3393       1872      93  VNPT-AS-VN VNPT Corp, VN
  7552        3057       1331      21  VIETEL-AS-AP Viettel Group, VN
  9498        2938        490     237  BBIL-AP BHARTI Airtel Ltd., IN
  4766        2551      11252     591  KIXS-AS-KR Korea Telecom, KR
 24560        2380        836     440  AIRTELBROADBAND-AS-AP Bharti Airtel Ltd
 45090        2184       1438      79  TENCENT-NET-AP Shenzhen Tencent Compute

Complete listing at https://thyme.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 16509        8228      10773    2938  AMAZON-02, US
 11492        4543        301     602  CABLEONE, US
  7155        3969        279      48  VIASAT-SP-BACKBONE, US
 22773        3594       3057     284  ASN-CXA-ALL-CCI-22773-RDC, US
  6327        3522       1320      64  SHAW, CA
 16625        3165       1584    2358  AKAMAI-AS, US
   749        3071      53111    2323  DNIC-AS-00749, US
396982        2631       3590     363  GOOGLE-CLOUD-PLATFORM, US
  7018        2572      24122    1566  ATT-INTERNET4, US
 30036        2510        362     438  MEDIACOM-ENTERPRISE-BUSINESS, US

Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 12479        7217       1706     140  UNI2-AS, ES
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 20940        4076       3399     164  AKAMAI-ASN1, NL
  8551        3893        370      37  BEZEQ-INTERNATIONAL-AS Bezeqint Interne
 12389        2951       2292     909  ROSTELECOM-AS, RU
  9009        2659        250    1390  M247, RO
 34984        2276        359     612  TELLCOM-AS, TR
  6849        2018        307      18  UKRTELNET, UA
 58224        1851        950     543  TCI, IR
 13188        1606        100      26  TRIOLAN, UA

Complete listing at https://thyme.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11234       3361     589  Uninet S.A. de C.V., MX
 10620        3502        507     853  Telmex Colombia S.A., CO
 13999        2325        357     613  Mega Cable, S.A. de C.V., MX
 11830        2260        369      64  Instituto Costarricense de Electricidad
 28573        1334       2324     240  Claro NXT Telecomunicacoes Ltda, BR
  6503        1299        339     514  Axtel, S.A.B. de C.V., MX
  3816        1293        760     170  COLOMBIA TELECOMUNICACIONES S.A. ESP, C
  6147        1132        370      22  Telefonica del Peru S.A.A., PE
 11664        1098        180     444  Techtel LMDS Comunicaciones Interactiva
 26615        1032       2498      45  TIM SA, BR

Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 24863        1578        393      19  LINKdotNET-AS, EG
 24835        1553        533      30  RAYA-AS, EG
 36992        1338       1518     275  ETISALAT-MISR, EG
 36903        1242        550      99  MT-MPLS, MA
 29571        1025         67      51  ORANGE-COTE-IVOIRE, CI
 36935         875        520      42  Vodafone-, EG
  6713         549       1861      34  IAM-AS, MA
 15399         535         54      47  WANANCHI-, KE
 37342         493         32       1  MOVITEL, MZ
 24757         485         73       5  EthioNet-AS, ET

Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11234       3361     589  Uninet S.A. de C.V., MX
  9808        9481       8706      40  CHINAMOBILE-CN China Mobile Communicati
 16509        8228      10773    2938  AMAZON-02, US
 12479        7217       1706     140  UNI2-AS, ES
  7545        5727        786     691  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4859       4192      75  ERX-CERNET-BKB China Education and Rese
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 11492        4543        301     602  CABLEONE, US
 20940        4076       3399     164  AKAMAI-ASN1, NL
  7155        3969        279      48  VIASAT-SP-BACKBONE, US

Complete listing at https://thyme.apnic.net/current/data-ASnet

Global Per AS Maximum Aggregation summary
-----------------------------------------

   ASN  No of nets  Net Savings  Description
  9808        9481         9441  CHINAMOBILE-CN China Mobile Communications Grou
 12479        7217         7077  UNI2-AS, ES
 16509        8228         5290  AMAZON-02, US
  7545        5727         5036  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4859         4784  ERX-CERNET-BKB China Education and Research Net
 39891        4833         4774  ALJAWWALSTC-AS, SA
 11492        4543         3941  CABLEONE, US
  7155        3969         3921  VIASAT-SP-BACKBONE, US
 20940        4076         3912  AKAMAI-ASN1, NL
  8551        3893         3856  BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo

Complete listing at https://thyme.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

    Bad AS  Designation  Net Originated      Transit AS  Transit AS Name
    198802  UNALLOCATED  5.105.41.0/24           207279  MARKAHOST-TELEKOMUNIKASYON-L
    198802  UNALLOCATED  5.105.82.0/24           207279  MARKAHOST-TELEKOMUNIKASYON-L
    198802  UNALLOCATED  5.105.102.0/24          207279  MARKAHOST-TELEKOMUNIKASYON-L
      3507  UNALLOCATED  5.105.166.0/24          213035  AS-SERVERION Serverion B.V.,
    198802  UNALLOCATED  5.105.197.0/24          207279  MARKAHOST-TELEKOMUNIKASYON-L
     33492  UNALLOCATED  8.6.184.0/23             33650  COMCAST-33650, US
     33123  UNALLOCATED  8.10.69.0/24             11168  SCC, US
     12169  UNALLOCATED  8.15.207.0/24            32787  PROLEXIC-TECHNOLOGIES-DDOS-M
     53775  UNALLOCATED  8.20.88.0/24              7029  WINDSTREAM, US
     62828  UNALLOCATED  8.21.130.0/24             3356  LEVEL3, US

Complete listing at https://thyme.apnic.net/current/data-badAS

Prefixes from the Special Purpose Address Registry (Global)
-----------------------------------------------------------

Prefix                Origin AS  Description
192.88.99.0/24             6939  HURRICANE, US

Complete listing at https://thyme.apnic.net/current/data-spar

Advertised Unallocated Addresses
--------------------------------

Unassigned Network     ASN Information  AS Name
23.131.185.0/24      Origin:       174  COGENT-174, US
23.131.185.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.186.0/24      Origin:       174  COGENT-174, US
23.131.186.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.187.0/24      Origin:       174  COGENT-174, US
23.131.187.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.188.0/24      Origin:       174  COGENT-174, US
23.131.188.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.139.232.0/24      Origin:    211619  MAXKO, HR
23.139.232.0/24     Transit:     42864  GIGANET-HU GigaNet Internet Service Prov

Complete listing at https://thyme.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:14      /10:39      /11:103     /12:298     
/13:578     /14:1196    /15:2050    /16:13461   /17:8245    /18:13834   
/19:25155   /20:44224   /21:51231   /22:109545  /23:97693   /24:550516  
/25:742     /26:0       /27:0       /28:0       /29:0       /30:0       
/31:0       /32:0       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

   ASN  No of nets  Total ann.  Description
 12479        6274        7217  UNI2-AS, ES
  8151        5176       11234  Uninet S.A. de C.V., MX
 39891        3632        4833  ALJAWWALSTC-AS, SA
 11492        3452        4543  CABLEONE, US
  8551        3365        3893  BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo
  6327        3331        3522  SHAW, CA
  7155        3039        3969  VIASAT-SP-BACKBONE, US
 22773        2659        3594  ASN-CXA-ALL-CCI-22773-RDC, US
 30036        2167        2510  MEDIACOM-ENTERPRISE-BUSINESS, US
 10620        2056        3502  Telmex Colombia S.A., CO

Complete listing at https://thyme.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1806      2:1268      3:175       4:5         5:4498      6:128    
   7:6         8:1546      9:1        11:172      12:1548     13:385    
  14:2322     15:299      16:183      17:369      18:415      20:256    
  21:4        22:188      23:6255     24:2588     25:6        27:2449   
  29:19       31:2507     32:89       34:12       35:108      36:1923   
  37:4648     38:4458     39:820      40:151      41:3940     42:1220   
  43:2348     44:308      45:16552    46:4279     47:363      49:1754   
  50:1840     51:573      52:1589     54:391      55:859      56:8      
  57:113      58:1782     59:1153     60:989      61:2457     62:2655   
  63:1923     64:5684     65:2323     66:4969     67:3004     68:1377   
  69:4152     70:1249     71:674      72:2981     74:2629     75:1443   
  76:612      77:2439     78:1865     79:3175     80:2098     81:1737   
  82:1489     83:1284     84:1533     85:2995     86:762      87:1985   
  88:1240     89:3642     90:611      91:7719     92:2063     93:2630   
  94:3596     95:4011     96:1327     97:336      98:1154     99:745    
 100:73      101:1071    102:2680    103:31273   104:4653    105:484    
 106:943     107:2527    108:1031    109:4427    110:2084    111:3139   
 112:2034    113:1608    114:1652    115:2020    116:1925    117:2509   
 118:2358    119:2015    120:1799    121:1111    122:2631    123:2213   
 124:1614    125:2516    128:1301    129:1063    130:1015    131:1983   
 132:813     133:422     134:1898    135:304     136:877     137:949    
 138:2564    139:1577    140:1238    141:1454    142:1437    143:1504   
 144:1165    145:347     146:1943    147:1578    148:2350    149:2107   
 150:879     151:1158    152:1817    153:489     154:4471    155:1434   
 156:1773    157:1304    158:1056    159:2302    160:2552    161:1531   
 162:3519    163:1522    164:1624    165:1718    166:1037    167:1729   
 168:3893    169:944     170:4598    171:869     172:3558    173:2950   
 174:1072    175:1158    176:3699    177:4563    178:3586    179:2159   
 180:2572    181:3420    182:3372    183:1968    184:2359    185:20191  
 186:4711    187:3933    188:4115    189:3564    190:9155    191:1432   
 192:10934   193:8884    194:7316    195:5159    196:3066    197:2370   
 198:5949    199:6098    200:7986    201:5852    202:10666   203:10221  
 204:4597    205:3547    206:4169    207:3440    208:4078    209:4865   
 210:4435    211:2495    212:4126    213:3577    214:1083    215:59     
 216:6640    217:2703    218:1294    219:577     220:2019    221:971    
 222:885     223:2184   

End of report

From lists at packetflux.com  Fri Apr 21 18:03:48 2023
From: lists at packetflux.com (Forrest Christian (List Account))
Date: Fri, 21 Apr 2023 12:03:48 -0600
Subject: Reverse DNS for eyeballs?
In-Reply-To: <CACC_My_2M7hO4R+7OJLj4-i8MeMymRBRNnJe63jm1ZZ23qeVjw@mail.gmail.com>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
 <CAD6AjGTZK+VxzFtB9bWUcjqbofmKQ++rtCDdHB4nKJJ6NGx+Gw@mail.gmail.com>
 <CACC_My_2M7hO4R+7OJLj4-i8MeMymRBRNnJe63jm1ZZ23qeVjw@mail.gmail.com>
Message-ID: <CAKsZx=2Wvn7Vp5wWK7vZjvjdDjAkUcmt6NBTvze0B7e4=ZdK6A@mail.gmail.com>

We actually manually list our customer ranges in pbl, or at least used to.
 Probably something else that I need to check on.

On Fri, Apr 21, 2023, 8:04 AM Lukas Tribus <lukas at ltri.eu> wrote:

> Hello,
>
>
> without PTRs you will probably get your prefixes listed in things like
> Spamhouse PBL. So adding the correct PTR for a mailserver may not be
> enough, as services like that love to classify entire IP blocks. Of
> course Spamhaus provides the tools to fix this issue. But what if
> there are 4 - 5 other services like that? Do you want to go down that
> rabbit hole, everytime you turn up a mailserver in your prefix?
>
> I also think reverse DNS records are useful when you have discussions
> with content providers for all sorts of reasons like geolocation
> issues or "VPN" classifications.
>
> Of course whois/irr records are the proper tools for this. But if I
> have to discuss my IP ranges with some first level support desk at a
> large content provider, everything that stands out negatively will
> impact my chances of actually getting it done and how fast it will get
> done.
>
>
> Considering how subjective IP classifications are, I will not return
> NXDOMAIN for v4 addresses if there is even a small chance that it will
> make my life harder at some point in the future.
>
>
> Lukas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230421/6d9ea47b/attachment.html>

From saku at ytti.fi  Fri Apr 21 18:16:09 2023
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 21 Apr 2023 21:16:09 +0300
Subject: Reverse DNS for eyeballs?
In-Reply-To: <SA1PR15MB4856D2EE91F5BB0F385A4D85C9609@SA1PR15MB4856.namprd15.prod.outlook.com>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net> <ZEKsQLPHMKc3Y07h@shrubbery.net>
 <SA1PR15MB4856D2EE91F5BB0F385A4D85C9609@SA1PR15MB4856.namprd15.prod.outlook.com>
Message-ID: <CAAeewD-zhkhL7LNNKWuHy3mP0eWaBa4sUqtFVduL2rkQEW5WSQ@mail.gmail.com>

On Fri, 21 Apr 2023 at 20:44, Jason Healy via NANOG <nanog at nanog.org> wrote:


> This is not intended as snark: what do people recommend for IPv6?  I try to maintain forward/reverse for all my server/infrastructure equipment.  But clients?  They're making up temporary addresses all day long.  So far, I've given up on trying to keep track of those addresses, even though it's a network under my direct control.

Stateless generation at query time -
https://github.com/cmouse/pdns-v6-autorev/blob/master/rev.pl

I wrote some POCs quite bit long ago

http://p.ip.fi/L5PK - base36
http://p.ip.fi/CAtB - rfc2289

-- 
  ++ytti

From tom.kac at gmail.com  Fri Apr 21 19:16:50 2023
From: tom.kac at gmail.com (Tom Kacprzynski)
Date: Fri, 21 Apr 2023 14:16:50 -0500
Subject: CHI-NOG11 - Agenda - May 11th
Message-ID: <CAPFZH4BPsS3N89dxNLk7tnTeBT1+p8Gs+YkL1wiYTu3cKT_tow@mail.gmail.com>

We are pleased to announce that the Chicago Network Operators Group will
host their 11th annual conference (CHI-NOG 11) on May 11th, 2023 in
Chicago, IL. Stop by and see our great agenda.

Presentations

   - Design and Implementation of the Illinois Express Quantum Metropolitan
   Area Network by Joaquin Chung (University of Chicago)
   - Seeing the Light: How Optical Transceiver Analytics Can Illuminate
   Your Data by Javier Antich (Selector AI)
   - gRIBI ? an open interface for programming your RIB by Steve Ulrich
   (Arista)
   - Stand Up for Your Routes! Using the Resource Public Key Infrastructure
   (RPKI) by Brad Gorman (ARIN)
   - Blockchain in Networking by Mike McBride (Futurewei)
   - Peering Automation Then and Now by Matt Griswold (FullCtl)
   - A Small Data Approach to Flow Analysis by Shannon Weyrick (Netbox Labs)
   - Documentation, Automation, Verification, Oh my! by Dan Kelcher (IP
   Fabric)
   - WISP Network Practices and Technologies by Justin Wilson (J2
   Consulting)
   - Simplifying Network Observability Device Onboarding with Nautobot by
   Nate Gotz (Network to Code)


Detailed agenda can be found at https://chinog.org/chi-nog-11/agenda-11/

Registration is still open, but ending soon. For more details please see
https://chinog.org/chi-nog-11/registration/

Thank you

Tom Kacprzynski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230421/68daef0f/attachment.html>

From frnkblk at iname.com  Fri Apr 21 23:23:21 2023
From: frnkblk at iname.com (Frank Bulk)
Date: Fri, 21 Apr 2023 18:23:21 -0500
Subject: Looking to work through GeoIP issue with Square
Message-ID: <000001d974a8$4335d730$c9a18590$@iname.com>

My google-fu is failing me - I'm looking to find out which GeoIP service
Square uses, or a path to work through a GeoIP issue with them.  A client of
ours uses Square and unfortunately one of the blocks (23.247.204.0/22) we
received at ARIN was at one time associated with France. As you can imagine,
they've geo-fenced some of their financial services. 

The GeoIP issue was fixed on MaxMind many months ago, and another client
worked through this issue with AWS, but apparently Square uses yet another
data source.

If someone can help me on or pm me off-list, that would be great.

Thanks, 

Frank 
AS53347
AS18883


From mangawilly at gmail.com  Sat Apr 22 13:59:26 2023
From: mangawilly at gmail.com (Willy Manga)
Date: Sat, 22 Apr 2023 17:59:26 +0400
Subject: Reverse DNS for eyeballs?
In-Reply-To: <mailman.1.1682164801.29332.nanog@nanog.org>
References: <mailman.1.1682164801.29332.nanog@nanog.org>
Message-ID: <0c3d724e-7c33-9d8c-72f1-fad35dad7a1c@gmail.com>

.

On 22/04/2023 16:00, nanog-request at nanog.org wrote:
> [...]
> [..]  Really, reverse DNS these
> days is mostly only useful for:
> 
> - mail servers (where it shows a modicum of control and clue)
> - infrastructure/router IPs (so mtr/traceroute can show useful info)

- Peers in an Internet eXchange Point ( a subset of the previous bullet 
point)



-- 
Willy Manga
@ongolaboy
https://ongola.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230422/20863895/attachment.sig>

From streinerj at gmail.com  Sun Apr 23 03:45:31 2023
From: streinerj at gmail.com (Justin Streiner)
Date: Sat, 22 Apr 2023 23:45:31 -0400
Subject: Windstream/Kinetic OSP assistance/clie sought
Message-ID: <CAEmzKA3s-Ua4Drd9avO3YTz5JFpeTuNM-nWsb0meLkct2uMHWA@mail.gmail.com>

Some of my family recently moved to an area of North Carolina where
high-speed residential Internet connectivity options seem to be very
limited. Outside of the options below, the only thing they're able to get
is satellite Internet service, and the performance has been very poor

They moved into an area where the neighbors have Kinetic (Windstream's
Internet service) but my relatives have been told that there are no
facilities available for them. This is new construction, so perhaps it's
possible that their address hasn't been added into whatever systems
Windstream/Kinetic use for service pre-qualification?

Is there anyone I can talk to at Winstream to find out if it is indeed
possible to get service at their address, or if there is way I can get past
the gatekeepers?

Any guidance from someone in the know at Windstream would be greatly
appreciated.

Thank you
jms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230422/96fd016f/attachment.html>

From streinerj at gmail.com  Sun Apr 23 04:03:43 2023
From: streinerj at gmail.com (Justin Streiner)
Date: Sun, 23 Apr 2023 00:03:43 -0400
Subject: Windstream/Kinetic OSP assistance/clie sought
In-Reply-To: <2A7C5B93-60E3-42E0-AEC0-732C1422487A@hxcore.ol>
References: <CAEmzKA3s-Ua4Drd9avO3YTz5JFpeTuNM-nWsb0meLkct2uMHWA@mail.gmail.com>
 <2A7C5B93-60E3-42E0-AEC0-732C1422487A@hxcore.ol>
Message-ID: <CAEmzKA0foWvmr_YtUWmuYdUMc0Mhjx8i5PDP8dTkgeL11_xjew@mail.gmail.com>

Other people on their street do have Kinetic, and I believe Windstream laid
cable from the street to their house, but they are being told there are no
facilities to connect them to an OLT or some other type of termination
device.

Thank you
jms

On Sat, Apr 22, 2023, 23:58 Alex Ryu <moonhunt at gmail.com> wrote:

> It is new construction home, it may be HoA, so it is controlled by HoA
> which may have some deal with one provider for landline.
>
> So it may be dictated by HoA until it reach to certain level when that
> binding deal is expired.
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
>
> *From: *Justin Streiner <streinerj at gmail.com>
> *Sent: *Saturday, April 22, 2023 10:46 PM
> *To: *NANOG <nanog at nanog.org>
> *Subject: *Windstream/Kinetic OSP assistance/clie sought
>
>
>
> Some of my family recently moved to an area of North Carolina where
> high-speed residential Internet connectivity options seem to be very
> limited. Outside of the options below, the only thing they're able to get
> is satellite Internet service, and the performance has been very poor
>
>
>
> They moved into an area where the neighbors have Kinetic (Windstream's
> Internet service) but my relatives have been told that there are no
> facilities available for them. This is new construction, so perhaps it's
> possible that their address hasn't been added into whatever systems
> Windstream/Kinetic use for service pre-qualification?
>
>
>
> Is there anyone I can talk to at Winstream to find out if it is indeed
> possible to get service at their address, or if there is way I can get past
> the gatekeepers?
>
>
>
> Any guidance from someone in the know at Windstream would be greatly
> appreciated.
>
>
>
> Thank you
>
> jms
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230423/482781df/attachment.html>

From arnold at nipper.de  Sun Apr 23 15:13:26 2023
From: arnold at nipper.de (Arnold Nipper)
Date: Sun, 23 Apr 2023 17:13:26 +0200
Subject: Call for Presentations EPF 2023, Prage, Czech Republic // NANOG
Message-ID: <1f0cbf1b-6bd1-7aa0-6c94-3d492d5f288a@nipper.de>

Dear all,

this is the Call for Presentations for the European Peering Forum 2023.

AMS-IX, DE-CIX, LINX, NETNOD and guest IXP NIX.CZ, are happy to host the 
European Peering Forum (EPF) 2023 from Sunday the 10th to Wednesday 13th 
September 2023 in Prague, Czech Republic.

The event will welcome peering managers and coordinators from networks 
connected to the host and guest Internet exchanges.

Besides some interesting topical agenda, the three-day event 
accommodates room for attendees to meet on a one-to-one basis to discuss 
bilateral peering business opportunities.

The programme committee will be looking for presentations and related to 
peering and technical topics of interconnection. Your presentation 
should address:

* Interconnection Automation
* Regional Peering
* Interconnection / Peering Internet Governance and Regulatory Topics
* Economic and Product Trends
* Peering / Interconnection strategies
* Interesting findings about Peering / Interconnection
* 400GE and beyond
* Any other hot topic related to Interconnection / Peering


Submissions
===========

Presentations must be of a non-commercial nature. Product or marketing 
heavy talks are strongly discouraged.

Submissions of presentations should be made to the programme committee 
<epf-pc at peering-forum.eu>. Please include:

* Author's name and e-mail address
* Presentation title
* Abstract
* Slides (if available)
* Time requested (max. 30 minutes incl. Q&A)


Deadlines
=========

Please send in your presentation asap. We decide on a first come first 
serve basis. The latest date for submission is July 30th, 2023.

More information about the event and other activities around EPF16 may 
be found at

* https://peering-forum.eu/2023/

* https://www.facebook.com/groups/1486607564933665/


On behalf of EPF,

Best regards,

AMS-IX, DE-CIX, LINX and NETNOD
-- 
Keep calm, keep distance, keep connected!

Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230423/273b47c0/attachment.sig>

From bobin.public at gmail.com  Mon Apr 24 11:11:55 2023
From: bobin.public at gmail.com (Samuel Jackson)
Date: Mon, 24 Apr 2023 04:11:55 -0700
Subject: SoCal T-Mobile IPv4 sites inaccessible
Message-ID: <CAOAsu-RLE=JSoStPCFhyR8JmY+vkrAbbqxKrOPWs_xK1z68ZVw@mail.gmail.com>

 I posted this on the outages mailing-list too, and I am hoping to get more
eyeballs on this while also checking in to see if this is isolated to just
us. On T-Mobile, we do not seem to be able to get to ipv4 sites.
ipv4.google.com does not load, ipv6.google.com does. Even www.t-mobile.com
does not seem to be working.
I Tried this with LTE (phone) and their home-internet service.
Anyone else seeing this?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230424/6035f6a9/attachment.html>

From josh at imaginenetworksllc.com  Mon Apr 24 15:27:35 2023
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Mon, 24 Apr 2023 11:27:35 -0400
Subject: Windstream/Kinetic OSP assistance/clie sought
In-Reply-To: <CAEmzKA0foWvmr_YtUWmuYdUMc0Mhjx8i5PDP8dTkgeL11_xjew@mail.gmail.com>
References: <CAEmzKA3s-Ua4Drd9avO3YTz5JFpeTuNM-nWsb0meLkct2uMHWA@mail.gmail.com>
 <2A7C5B93-60E3-42E0-AEC0-732C1422487A@hxcore.ol>
 <CAEmzKA0foWvmr_YtUWmuYdUMc0Mhjx8i5PDP8dTkgeL11_xjew@mail.gmail.com>
Message-ID: <CAN9qwJ8f1O59owjyaeHSWW3S9rcvMe=Z=DgkqGojoDBnVM1n5A@mail.gmail.com>

Use broadbandmap.fcc.gov to confirm availability or not.  If Kinetic says
it's available there and you can't sign up, challenge the location.

On Sun, Apr 23, 2023 at 12:04?AM Justin Streiner <streinerj at gmail.com>
wrote:

> Other people on their street do have Kinetic, and I believe Windstream
> laid cable from the street to their house, but they are being told there
> are no facilities to connect them to an OLT or some other type of
> termination device.
>
> Thank you
> jms
>
> On Sat, Apr 22, 2023, 23:58 Alex Ryu <moonhunt at gmail.com> wrote:
>
>> It is new construction home, it may be HoA, so it is controlled by HoA
>> which may have some deal with one provider for landline.
>>
>> So it may be dictated by HoA until it reach to certain level when that
>> binding deal is expired.
>>
>>
>>
>>
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows
>>
>>
>>
>> *From: *Justin Streiner <streinerj at gmail.com>
>> *Sent: *Saturday, April 22, 2023 10:46 PM
>> *To: *NANOG <nanog at nanog.org>
>> *Subject: *Windstream/Kinetic OSP assistance/clie sought
>>
>>
>>
>> Some of my family recently moved to an area of North Carolina where
>> high-speed residential Internet connectivity options seem to be very
>> limited. Outside of the options below, the only thing they're able to get
>> is satellite Internet service, and the performance has been very poor
>>
>>
>>
>> They moved into an area where the neighbors have Kinetic (Windstream's
>> Internet service) but my relatives have been told that there are no
>> facilities available for them. This is new construction, so perhaps it's
>> possible that their address hasn't been added into whatever systems
>> Windstream/Kinetic use for service pre-qualification?
>>
>>
>>
>> Is there anyone I can talk to at Winstream to find out if it is indeed
>> possible to get service at their address, or if there is way I can get past
>> the gatekeepers?
>>
>>
>>
>> Any guidance from someone in the know at Windstream would be greatly
>> appreciated.
>>
>>
>>
>> Thank you
>>
>> jms
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230424/a43121d6/attachment.html>

From nanog at ve4.ca  Sun Apr 23 03:28:30 2023
From: nanog at ve4.ca (Glen A. Pearce)
Date: Sat, 22 Apr 2023 21:28:30 -0600
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
Message-ID: <eb55f074-6a38-7173-02ca-1279aae08f5a@ve4.ca>

Well, I eventually had a friend open the attachment on his Linux machine
and once he confirmed it was safe to open and found there was nothing
in it other than the list of IP addresses, user names and time stamps but
there were a whole bunch of addresses listed I opened the attachment in
Notepad.

All 43 IP addresses listed turned out to not be ones that are not and have
not been in use the entire time I've had the IP block.

So it's still mysterious why someone would have sent this as it appears to
not be malware but it's entirely junk information, so no reason to explain
why either the German Police or a scammer would have sent it.

Maybe the German Police used to have a server at that address for some
purpose and neglected to turn off the forward DNS when it was
decommissioned and Deutsche Telekom AG didn't remove the old
reverse DNS when they re-assigned the space to a new customer and
that new customer stood up a mail server to sent these.? Though for
what purpose I'm unsure.

It's as odd as the (automatically generated) abuse E-mail I recently got
from a Spanish ISP (Comvive Servidores SL) claiming to have received
a network attack from an address that is also not in use.? (Which was
one of the ones listed in this E-mail.)

Thanks to everyone that did reply with their input.

-- 
Glen A. Pearce
gap at ve4.ca
Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk.
Very Eager 4 Tees
http://www.ve4.ca
ARIN Handle VET-17


From niels=nanog at bakker.net  Mon Apr 24 16:24:17 2023
From: niels=nanog at bakker.net (Niels Bakker)
Date: Mon, 24 Apr 2023 18:24:17 +0200
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <eb55f074-6a38-7173-02ca-1279aae08f5a@ve4.ca>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
 <eb55f074-6a38-7173-02ca-1279aae08f5a@ve4.ca>
Message-ID: <ZEatMfN/gag7KB8/@jima.tpb.net>

* nanog at ve4.ca (Glen A. Pearce) [Mon 24 Apr 2023, 17:42 CEST]:
>Well, I eventually had a friend open the attachment on his Linux machine

Not necessarily a safe idea:
   https://www.welivesecurity.com/2023/04/20/linux-malware-strengthens-links-lazarus-3cx-supply-chain-attack/
(scroll down to "Operation DreamJob with a Linux payload", sadly no anchors)


	-- Niels.

From nanog at shankland.org  Mon Apr 24 17:37:30 2023
From: nanog at shankland.org (Jim Shankland)
Date: Mon, 24 Apr 2023 10:37:30 -0700
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <ZEatMfN/gag7KB8/@jima.tpb.net>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
 <eb55f074-6a38-7173-02ca-1279aae08f5a@ve4.ca> <ZEatMfN/gag7KB8/@jima.tpb.net>
Message-ID: <b108bced-9bb0-59ab-9c7e-82f908c6819a@shankland.org>

On 4/24/23 9:24 AM, Niels Bakker wrote:
> * nanog at ve4.ca (Glen A. Pearce) [Mon 24 Apr 2023, 17:42 CEST]:
>> Well, I eventually had a friend open the attachment on his Linux machine
>
> Not necessarily a safe idea:
> https://www.welivesecurity.com/2023/04/20/linux-malware-strengthens-links-lazarus-3cx-supply-chain-attack/
> (scroll down to "Operation DreamJob with a Linux payload", sadly no 
> anchors)
>
The key security concern here is "don't inspect/interpret bytes in an 
attachment with an application of the attacker's choosing". cat, or even 
emacs, seem pretty safe.

For me, that's easiest to do with Linux or MacOS (terminal). But sure, 
if "open on a Linux machine" still means "point and click", then you're 
absolutely correct.

Jim Shankland


From randy at psg.com  Tue Apr 25 21:10:38 2023
From: randy at psg.com (Randy Bush)
Date: Tue, 25 Apr 2023 14:10:38 -0700
Subject: Reverse DNS for eyeballs?
In-Reply-To: <cf5376dd-572a-0e30-76d0-6d9ed4bda360@geier.ne.tz>
References: <CAKsZx=1S-7UDYEXW=_-RbA6NAhPeqzqB7qggSB-Xrgtz59WufA@mail.gmail.com>
 <20230421123749.GB3279@cmadams.net>
 <cf5376dd-572a-0e30-76d0-6d9ed4bda360@geier.ne.tz>
Message-ID: <m2leifd5wx.wl-randy@psg.com>

> I would say the absence of reverse DNS tells useful info to receiving
> MTAs - to preferably not accept.

yep

From lyndon at orthanc.ca  Tue Apr 25 22:55:31 2023
From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM))
Date: Tue, 25 Apr 2023 15:55:31 -0700
Subject: BGP Books
Message-ID: <b967a1a10c5bf68b@orthanc.ca>

It has been a couple of decades since I've done any BGP in anger,
but it looks like I will be jumping into the deep end again, soon,
and I desperately need to get up to speed again.

There seem to be a lot of good guides out there from Cisco, Juniper,
and the like, but naturally they are very product oriented.  What
I'm looking for is more like the Stevens networking bibles (i.e.
"BGP Illustrated Vol I and II"). Something that covers more than
just the raw protocols, and includes things like RPKI.  (The world
sure has changed since the last time I was doing this!)

Any/all suggestions welcome.

Thanks!

--lyndon

From sghuter at nsrc.org  Tue Apr 25 23:20:37 2023
From: sghuter at nsrc.org (Steven G. Huter)
Date: Tue, 25 Apr 2023 16:20:37 -0700
Subject: BGP Books
In-Reply-To: <b967a1a10c5bf68b@orthanc.ca>
References: <b967a1a10c5bf68b@orthanc.ca>
Message-ID: <920124e6-2bdf-ac68-3801-8cceef20aaeb@nsrc.org>


On 4/25/23 3:55 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> It has been a couple of decades since I've done any BGP in anger,
> but it looks like I will be jumping into the deep end again, soon,
> and I desperately need to get up to speed again.
>
> There seem to be a lot of good guides out there from Cisco, Juniper,
> and the like, but naturally they are very product oriented.  What
> I'm looking for is more like the Stevens networking bibles (i.e.
> "BGP Illustrated Vol I and II"). Something that covers more than
> just the raw protocols, and includes things like RPKI.  (The world
> sure has changed since the last time I was doing this!)
>
> Any/all suggestions welcome.
>
https://learn.nsrc.org/bgp

Steve


From aaron1 at gvtc.com  Wed Apr 26 02:01:18 2023
From: aaron1 at gvtc.com (Aaron1)
Date: Tue, 25 Apr 2023 21:01:18 -0500
Subject: BGP Books
In-Reply-To: <b967a1a10c5bf68b@orthanc.ca>
References: <b967a1a10c5bf68b@orthanc.ca>
Message-ID: <D0B69F77-6D27-4103-8171-6000B092EEEB@gvtc.com>

Depending on how many years since you last looked at BGP, you may be shocked at how many address families BGP now carries? it?s very Multi-Protocol now.  MP-BGP

I?ll always remember how informative the Basam Halabi book was.  Also the Ivan Peplnjak MPLS VPN book.  Both have a couple editions.  Those are oldies but goodies.  More recently is MPLS in the SDN era.  But it seems the SR/SPRING will be the most recent topics to study, I think that?s were BGP-LU comes in.  I need to get a book and read too 

Aaron

> On Apr 25, 2023, at 5:56 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon at orthanc.ca> wrote:
> 
> ?It has been a couple of decades since I've done any BGP in anger,
> but it looks like I will be jumping into the deep end again, soon,
> and I desperately need to get up to speed again.
> 
> There seem to be a lot of good guides out there from Cisco, Juniper,
> and the like, but naturally they are very product oriented.  What
> I'm looking for is more like the Stevens networking bibles (i.e.
> "BGP Illustrated Vol I and II"). Something that covers more than
> just the raw protocols, and includes things like RPKI.  (The world
> sure has changed since the last time I was doing this!)
> 
> Any/all suggestions welcome.
> 
> Thanks!
> 
> --lyndon


From neel at neelc.org  Wed Apr 26 02:35:40 2023
From: neel at neelc.org (Neel Chauhan)
Date: Tue, 25 Apr 2023 19:35:40 -0700
Subject: IPv4 Subnet 23.151.232.0/24 blackholed?
Message-ID: <49ab349676565928f510b1ff9fce4905@neelc.org>

Hi,

I recently got the IPv4 allocation 23.151.232.0/24 from ARIN. I also had 
my hosting company ReliableSite announce it to the internet.

Right now, I can only access networks that peer with ReliableSite via 
internet exchanges, such as Google, CloudFlare, OVH, Hurricane Electric, 
et al.

It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT&T, et al.) are 
blackholing the IPv4 subnet 23.151.232.0/24. Could someone who works at 
a Tier 1 NOC please check and remove the blackhole if any exists?

Normally when ReliableSite announced my prior (then-leased) IPv4 space 
it gets propagated via BGP almost immediately. This time it's not going 
through at all.

Best,

Neel Chauhan

From ryan at rkhtech.org  Wed Apr 26 02:49:42 2023
From: ryan at rkhtech.org (Ryan Hamel)
Date: Wed, 26 Apr 2023 02:49:42 +0000
Subject: IPv4 Subnet 23.151.232.0/24 blackholed?
In-Reply-To: <49ab349676565928f510b1ff9fce4905@neelc.org>
References: <49ab349676565928f510b1ff9fce4905@neelc.org>
Message-ID: <emf809862f-0320-4912-9fe0-58a17504f878@4f5723eb.com>

Neel,

Carriers rebuild their prefixes lists once or twice in a 24 hour period. 
Considering that you just got the block today and is in ReliableSite's 
AS-SET, you just got to be patient.

Having announcements propagated immediately either sounds like it 
happened a day after you gave them the LOA, or they have unfiltered 
transit circuits, which is worrisome.

Ryan

------ Original Message ------
>From "Neel Chauhan" <neel at neelc.org>
To nanog at nanog.org
Date 4/25/2023 7:35:40 PM
Subject IPv4 Subnet 23.151.232.0/24 blackholed?

>Hi,
>
>I recently got the IPv4 allocation 23.151.232.0/24 from ARIN. I also had my hosting company ReliableSite announce it to the internet.
>
>Right now, I can only access networks that peer with ReliableSite via internet exchanges, such as Google, CloudFlare, OVH, Hurricane Electric, et al.
>
>It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT&T, et al.) are blackholing the IPv4 subnet 23.151.232.0/24. Could someone who works at a Tier 1 NOC please check and remove the blackhole if any exists?
>
>Normally when ReliableSite announced my prior (then-leased) IPv4 space it gets propagated via BGP almost immediately. This time it's not going through at all.
>
>Best,
>
>Neel Chauhan

From jlewis at lewis.org  Wed Apr 26 02:52:14 2023
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 25 Apr 2023 22:52:14 -0400 (EDT)
Subject: IPv4 Subnet 23.151.232.0/24 blackholed?
In-Reply-To: <49ab349676565928f510b1ff9fce4905@neelc.org>
References: <49ab349676565928f510b1ff9fce4905@neelc.org>
Message-ID: <e4b2d2e3-d37-985d-6939-c99fbd296d38@lewis.org>

You need to talk to ReliableSite and have them talk to their transits 
about accepting 23.151.232.0/24.

I see that you did create a route object...

route:          23.151.232.0/24
origin:         AS23470
descr:          Qeru Systems, LLC
mnt-by:         MAINT-AS23470
changed:        jcid at reliablesite.net 20230425  #01:09:36Z
source:         RADB

but I'd dump RADB and create this object in the authoratative IRR, in this 
case ARIN's rr.arin.net.  At least some "Tier 1's" no longer honor route 
objects from non-authoratative IRRs when building prefix-list filters for 
their customers BGP sessions.

I'm not receiving your route, and route-views doesn't see it either.

On Tue, 25 Apr 2023, Neel Chauhan wrote:

> Hi,
>
> I recently got the IPv4 allocation 23.151.232.0/24 from ARIN. I also had my 
> hosting company ReliableSite announce it to the internet.
>
> Right now, I can only access networks that peer with ReliableSite via 
> internet exchanges, such as Google, CloudFlare, OVH, Hurricane Electric, et 
> al.
>
> It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT&T, et al.) are blackholing 
> the IPv4 subnet 23.151.232.0/24. Could someone who works at a Tier 1 NOC 
> please check and remove the blackhole if any exists?
>
> Normally when ReliableSite announced my prior (then-leased) IPv4 space it 
> gets propagated via BGP almost immediately. This time it's not going through 
> at all.
>
> Best,
>
> Neel Chauhan
>
>

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  StackPath, Sr. Neteng       |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From ayang at august.tw  Wed Apr 26 02:54:06 2023
From: ayang at august.tw (August Yang)
Date: Tue, 25 Apr 2023 22:54:06 -0400
Subject: IPv4 Subnet 23.151.232.0/24 blackholed?
In-Reply-To: <emf809862f-0320-4912-9fe0-58a17504f878@4f5723eb.com>
References: <49ab349676565928f510b1ff9fce4905@neelc.org>
 <emf809862f-0320-4912-9fe0-58a17504f878@4f5723eb.com>
Message-ID: <96bd0a6a-927c-038b-c3ce-82afba895b16@august.tw>

The range has only been announced for 2 hours. Just wait longer for 
filters to refresh as Ryan advised.

On 2023-04-25 10:49 p.m., Ryan Hamel wrote:
> Neel,
>
> Carriers rebuild their prefixes lists once or twice in a 24 hour 
> period. Considering that you just got the block today and is in 
> ReliableSite's AS-SET, you just got to be patient.
>
> Having announcements propagated immediately either sounds like it 
> happened a day after you gave them the LOA, or they have unfiltered 
> transit circuits, which is worrisome.
>
> Ryan
>
> ------ Original Message ------
> From "Neel Chauhan" <neel at neelc.org>
> To nanog at nanog.org
> Date 4/25/2023 7:35:40 PM
> Subject IPv4 Subnet 23.151.232.0/24 blackholed?
>
>> Hi,
>>
>> I recently got the IPv4 allocation 23.151.232.0/24 from ARIN. I also 
>> had my hosting company ReliableSite announce it to the internet.
>>
>> Right now, I can only access networks that peer with ReliableSite via 
>> internet exchanges, such as Google, CloudFlare, OVH, Hurricane 
>> Electric, et al.
>>
>> It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT&T, et al.) are 
>> blackholing the IPv4 subnet 23.151.232.0/24. Could someone who works 
>> at a Tier 1 NOC please check and remove the blackhole if any exists?
>>
>> Normally when ReliableSite announced my prior (then-leased) IPv4 
>> space it gets propagated via BGP almost immediately. This time it's 
>> not going through at all.
>>
>> Best,
>>
>> Neel Chauhan
-- 
Best regards
August Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230425/811d13e7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3696 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230425/811d13e7/attachment.bin>

From jk at ip-clear.de  Wed Apr 26 10:37:11 2023
From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg_Kost?=)
Date: Wed, 26 Apr 2023 12:37:11 +0200
Subject: BGP Books
In-Reply-To: <b967a1a10c5bf68b@orthanc.ca>
References: <b967a1a10c5bf68b@orthanc.ca>
Message-ID: <D985A3A9-755F-46FF-92AF-A95821646F69@ip-clear.de>

Hello,

my two cents.

For a general overview:
Internet Routing with BGP, van Beijnum, Iljitsch on Amazon/Kindle, 2022

For deep dive:
Troubleshooting BGP: A Practical Guide to Understanding and Troubleshooting, Cisco Press, 2016, 978-1587144646

BR
J?rg

On 26 Apr 2023, at 0:55, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:

> It has been a couple of decades since I've done any BGP in anger,
> but it looks like I will be jumping into the deep end again, soon,
> and I desperately need to get up to speed again.
>
> There seem to be a lot of good guides out there from Cisco, Juniper,
> and the like, but naturally they are very product oriented.  What
> I'm looking for is more like the Stevens networking bibles (i.e.
> "BGP Illustrated Vol I and II"). Something that covers more than
> just the raw protocols, and includes things like RPKI.  (The world
> sure has changed since the last time I was doing this!)
>
> Any/all suggestions welcome.
>
> Thanks!
>
> --lyndon

From tgarrison at netviscom.com  Wed Apr 26 11:33:16 2023
From: tgarrison at netviscom.com (Travis Garrison)
Date: Wed, 26 Apr 2023 11:33:16 +0000
Subject: IPv4 Subnet 23.151.232.0/24 blackholed?
In-Reply-To: <96bd0a6a-927c-038b-c3ce-82afba895b16@august.tw>
References: <49ab349676565928f510b1ff9fce4905@neelc.org>
 <emf809862f-0320-4912-9fe0-58a17504f878@4f5723eb.com>
 <96bd0a6a-927c-038b-c3ce-82afba895b16@august.tw>
Message-ID: <CH0PR18MB4307ABB5B4B23594EDEC8E06AE659@CH0PR18MB4307.namprd18.prod.outlook.com>

We are able to see your range from Cogent and Hurricane Electric now. Just took time

Routes For: 23.151.232.0/24
Timestamp: 2023-04-26 11:27:07 UTC
  - Prefix: 23.151.232.0/24
    - RPKI State: Not Verified
    - AS Path: 6939 ? 23470 ? 23470 ? 23470 ? 23470
    - Next Hop: 184.105.58.113
    - Weight: 170
    - Local Preference: 100
    - MED: 0
    - Communities:
    - Originator:
    - Peer: 216.218.253.50
    - Age: 6 hours (Wed, 26 Apr 2023 05:01:41 UTC)

  - Prefix: 23.151.232.0/24
    - RPKI State: Not Verified
    - AS Path: 6939 ? 23470 ? 23470 ? 23470 ? 23470
    - Next Hop: 184.105.92.241
    - Weight: 170
    - Local Preference: 100
    - MED: 0
    - Communities:
    - Originator:
    - Peer: 100.78.0.6
    - Age: 6 hours (Wed, 26 Apr 2023 05:01:39 UTC)

  - Prefix: 23.151.232.0/24
    - RPKI State: Not Verified
    - AS Path: 174 ? 3257 ? 23470 ? 23470 ? 23470 ? 23470
    - Next Hop: 38.140.137.161
    - Weight: 170
    - Local Preference: 100
    - MED: 10020
    - Communities:
      - 174:21000
      - 174:22013
    - Originator:
    - Peer: 66.28.1.16
    - Age: 3 hours (Wed, 26 Apr 2023 08:57:05 UTC)

Thanks
Travis

From: NANOG <nanog-bounces+tgarrison=netviscom.com at nanog.org> On Behalf Of August Yang via NANOG
Sent: Tuesday, April 25, 2023 9:54 PM
To: Ryan Hamel <ryan at rkhtech.org>; Neel Chauhan <neel at neelc.org>; nanog at nanog.org
Subject: Re: IPv4 Subnet 23.151.232.0/24 blackholed?


The range has only been announced for 2 hours. Just wait longer for filters to refresh as Ryan advised.
On 2023-04-25 10:49 p.m., Ryan Hamel wrote:
Neel,

Carriers rebuild their prefixes lists once or twice in a 24 hour period. Considering that you just got the block today and is in ReliableSite's AS-SET, you just got to be patient.

Having announcements propagated immediately either sounds like it happened a day after you gave them the LOA, or they have unfiltered transit circuits, which is worrisome.

Ryan

------ Original Message ------
From "Neel Chauhan" <neel at neelc.org><mailto:neel at neelc.org>
To nanog at nanog.org<mailto:nanog at nanog.org>
Date 4/25/2023 7:35:40 PM
Subject IPv4 Subnet 23.151.232.0/24 blackholed?


Hi,

I recently got the IPv4 allocation 23.151.232.0/24 from ARIN. I also had my hosting company ReliableSite announce it to the internet.

Right now, I can only access networks that peer with ReliableSite via internet exchanges, such as Google, CloudFlare, OVH, Hurricane Electric, et al.

It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT&T, et al.) are blackholing the IPv4 subnet 23.151.232.0/24. Could someone who works at a Tier 1 NOC please check and remove the blackhole if any exists?

Normally when ReliableSite announced my prior (then-leased) IPv4 space it gets propagated via BGP almost immediately. This time it's not going through at all.

Best,

Neel Chauhan
--
Best regards
August Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230426/9358cdd1/attachment.html>

From mark at tinka.africa  Wed Apr 26 12:54:23 2023
From: mark at tinka.africa (Mark Tinka)
Date: Wed, 26 Apr 2023 14:54:23 +0200
Subject: IPv4 Subnet 23.151.232.0/24 blackholed?
In-Reply-To: <CH0PR18MB4307ABB5B4B23594EDEC8E06AE659@CH0PR18MB4307.namprd18.prod.outlook.com>
References: <49ab349676565928f510b1ff9fce4905@neelc.org>
 <emf809862f-0320-4912-9fe0-58a17504f878@4f5723eb.com>
 <96bd0a6a-927c-038b-c3ce-82afba895b16@august.tw>
 <CH0PR18MB4307ABB5B4B23594EDEC8E06AE659@CH0PR18MB4307.namprd18.prod.outlook.com>
Message-ID: <ac41d60c-2bac-3326-d63e-031321b4447b@tinka.africa>

You're welcome to use our looking glasses which over Europe and Africa:

https://as37100.net/

But so far, we are seeing this in AMS:

BGP routing table entry for 23.151.232.0/24, version 2411923092
Paths: (2 available, best #2, table default)
 ? Not advertised to any peer
 ? Refresh Epoch 1
 ? 37100 3257 23470 23470 23470 23470
 ??? 105.26.64.17 from 105.26.64.17 (105.16.0.131)
 ????? Origin IGP, metric 0, localpref 100, valid, external
 ????? Community: 37100:1 37100:13
 ????? path 211B5070 RPKI State not found
 ????? rx pathid: 0, tx pathid: 0
 ? Refresh Epoch 1
 ? 37100 3257 23470 23470 23470 23470
 ??? 105.26.64.1 from 105.26.64.1 (105.16.0.131)
 ????? Origin IGP, metric 0, localpref 100, valid, external, best
 ????? Community: 37100:1 37100:13
 ????? path 211B6A5C RPKI State not found
 ????? rx pathid: 0, tx pathid: 0x0

And in JNB:

BGP routing table entry for 23.151.232.0/24, version 1526622268
Paths: (2 available, best #2, table default)
 ? Not advertised to any peer
 ? Refresh Epoch 1
 ? 37100 3257 23470 23470 23470 23470
 ??? 105.22.32.1 from 105.22.32.1 (105.16.0.163)
 ????? Origin IGP, metric 0, localpref 100, valid, external
 ????? Community: 37100:1 37100:13
 ????? path 44E5427C RPKI State not found
 ????? rx pathid: 0, tx pathid: 0
 ? Refresh Epoch 1
 ? 37100 3257 23470 23470 23470 23470
 ??? 105.22.40.1 from 105.22.40.1 (105.16.0.162)
 ????? Origin IGP, metric 0, localpref 100, valid, external, best
 ????? Community: 37100:1 37100:13
 ????? path 44E60E94 RPKI State not found
 ????? rx pathid: 0, tx pathid: 0x0

Mark.

On 4/26/23 13:33, Travis Garrison wrote:
>
> We are able to see your range from Cogent and Hurricane Electric now. 
> Just took time
>
> Routes For: 23.151.232.0/24
>
> Timestamp: 2023-04-26 11:27:07 UTC
>
> ? - Prefix: 23.151.232.0/24
>
> ??? - RPKI State: Not Verified
>
> ??? - AS Path: 6939 ? 23470 ? 23470 ? 23470 ? 23470
>
> ??? - Next Hop: 184.105.58.113
>
> ??? - Weight: 170
>
> ??? - Local Preference: 100
>
> ?? ?- MED: 0
>
> ??? - Communities:
>
> ????- Originator:
>
> ????- Peer: 216.218.253.50
>
> ??? - Age: 6 hours (Wed, 26 Apr 2023 05:01:41 UTC)
>
> ? - Prefix: 23.151.232.0/24
>
> ??? - RPKI State: Not Verified
>
> ??? - AS Path: 6939 ? 23470 ? 23470 ? 23470 ? 23470
>
> ??? - Next Hop: 184.105.92.241
>
> ??? - Weight: 170
>
> ??? - Local Preference: 100
>
> ??? - MED: 0
>
> ??? - Communities:
>
> ????- Originator:
>
> ????- Peer: 100.78.0.6
>
> ??? - Age: 6 hours (Wed, 26 Apr 2023 05:01:39 UTC)
>
> ? - Prefix: 23.151.232.0/24
>
> ??? - RPKI State: Not Verified
>
> ??? - AS Path: 174 ? 3257 ? 23470 ? 23470 ? 23470 ? 23470
>
> ??? - Next Hop: 38.140.137.161
>
> ??? - Weight: 170
>
> ??? - Local Preference: 100
>
> ??? - MED: 10020
>
> ??? - Communities:
>
> ??????- 174:21000
>
> ????? - 174:22013
>
> ??? - Originator:
>
> ????- Peer: 66.28.1.16
>
> ??? - Age: 3 hours (Wed, 26 Apr 2023 08:57:05 UTC)
>
> Thanks
>
> Travis
>
> *From:* NANOG <nanog-bounces+tgarrison=netviscom.com at nanog.org> *On 
> Behalf Of *August Yang via NANOG
> *Sent:* Tuesday, April 25, 2023 9:54 PM
> *To:* Ryan Hamel <ryan at rkhtech.org>; Neel Chauhan <neel at neelc.org>; 
> nanog at nanog.org
> *Subject:* Re: IPv4 Subnet 23.151.232.0/24 blackholed?
>
> The range has only been announced for 2 hours. Just wait longer for 
> filters to refresh as Ryan advised.
>
> On 2023-04-25 10:49 p.m., Ryan Hamel wrote:
>
>     Neel,
>
>     Carriers rebuild their prefixes lists once or twice in a 24 hour
>     period. Considering that you just got the block today and is in
>     ReliableSite's AS-SET, you just got to be patient.
>
>     Having announcements propagated immediately either sounds like it
>     happened a day after you gave them the LOA, or they have
>     unfiltered transit circuits, which is worrisome.
>
>     Ryan
>
>     ------ Original Message ------
>     From "Neel Chauhan" <neel at neelc.org> <mailto:neel at neelc.org>
>     To nanog at nanog.org
>     Date 4/25/2023 7:35:40 PM
>     Subject IPv4 Subnet 23.151.232.0/24 blackholed?
>
>
>         Hi,
>
>         I recently got the IPv4 allocation 23.151.232.0/24 from ARIN.
>         I also had my hosting company ReliableSite announce it to the
>         internet.
>
>         Right now, I can only access networks that peer with
>         ReliableSite via internet exchanges, such as Google,
>         CloudFlare, OVH, Hurricane Electric, et al.
>
>         It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT&T, et al.)
>         are blackholing the IPv4 subnet 23.151.232.0/24. Could someone
>         who works at a Tier 1 NOC please check and remove the
>         blackhole if any exists?
>
>         Normally when ReliableSite announced my prior (then-leased)
>         IPv4 space it gets propagated via BGP almost immediately. This
>         time it's not going through at all.
>
>         Best,
>
>         Neel Chauhan
>
> -- 
> Best regards
> August Yang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230426/309c41a3/attachment.html>

From jlewis at lewis.org  Wed Apr 26 12:59:02 2023
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 26 Apr 2023 08:59:02 -0400 (EDT)
Subject: IPv4 Subnet 23.151.232.0/24 blackholed?
In-Reply-To: <CH0PR18MB4307ABB5B4B23594EDEC8E06AE659@CH0PR18MB4307.namprd18.prod.outlook.com>
References: <49ab349676565928f510b1ff9fce4905@neelc.org>
 <emf809862f-0320-4912-9fe0-58a17504f878@4f5723eb.com>
 <96bd0a6a-927c-038b-c3ce-82afba895b16@august.tw>
 <CH0PR18MB4307ABB5B4B23594EDEC8E06AE659@CH0PR18MB4307.namprd18.prod.outlook.com>
Message-ID: <57fdd93b-2ec2-1fe0-943-edcb9b4a34d4@lewis.org>

Now this is kind of interesting.  I see route-views can see the route 
now...

BGP routing table entry for 23.151.232.0/24, version 2814701286
Paths: (19 available, best #19, table default)
   Not advertised to any peer
   Refresh Epoch 1
   3333 1257 6453 23470 23470 23470 23470
     193.0.0.56 from 193.0.0.56 (193.0.0.56)
       Origin IGP, localpref 100, valid, external
       Community: 1257:50 1257:51 1257:3528 1257:4103
       path 7FE0DBA20378 RPKI State not found
       rx pathid: 0, tx pathid: 0
   Refresh Epoch 1
...

The only IRR route object I see for it is

route:          23.151.232.0/24
origin:         AS23470
descr:          Qeru Systems, LLC
mnt-by:         MAINT-AS23470
changed:        jcid at reliablesite.net 20230425  #01:09:36Z
source:         RADB
rpki-ov-state:  not_found # No ROAs found, or RPKI validation not enabled for source

and there appears to be no ROA.

According to https://lg.as6453.net/doc/cust-routing-policy.html, I would 
not have expected Tata to accept this route from RELIABLESITE (not based 
on the above route object), unless Tata is not using an IRR-based 
auto-generated prefix-list filter for RELIABLESITE, but rather a manually 
edited one.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  StackPath, Sr. Neteng       |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From jtodd at quad9.net  Wed Apr 26 14:54:55 2023
From: jtodd at quad9.net (John Todd)
Date: Wed, 26 Apr 2023 07:54:55 -0700
Subject: OARC 41- Call for Contributions
Message-ID: <7F3EA4F1-E81E-4D98-B062-B02E04ADC4BA@quad9.net>


OARC 41 will be a two-day hybrid meeting and the tentative dates are 
6th-7th September to be co-located with ICANN DNS Symposium in Asia.

  The Programme Committee is seeking contributions from the community.

  All DNS-related subjects and suggestions for discussion topics are 
welcome. For inspiration, we provide a non-exhaustive list of ideas:

  * Operations: Any operational gotchas, lessons learned from an outage, 
details/reasons for a recent outage (how to improve TTR, tooling)
  * Deployment: DNS config management and release process.Monitoring: 
Log ingestion pipeline, analytics infrastructure, anomaly detection
  * Scaling: DNS performance management and metrics. Increasing DNS 
Server Efficiency
  * Security/Privacy: DNSSEC signing and validation, key storage, 
rollovers, qname minimization, DoH/DoT

The presentations can be either a full-length presentation - 20 mins (+5 
mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A)

Workshop Milestones:

  2023-04-16 Submissions open via Indico
  2023-06-10 Deadline for submission (23:59 UTC)
  2023-06-27 Preliminary list of contributions published
  2023-07-11 Full agenda published
  2023-08-08 Deadline for slideset submission and Rehearsal
  2023-09-06 OARC 41 Workshop - Day1
  2023-09-07 OARC 41 Workshop - Day2

  The Registration page and details for presentation submission are 
published at: <https://www.dns-oarc.net/oarc41>

  To allow the Programme Committee to make objective assessments of 
submissions, so as to ensure the quality of the workshop, submissions 
SHOULD include slides. Draft slides are acceptable on submission. 
Example guidelines for presentation slides: 
https://www.grammarly.com/blog/presentation-tips/


  Additional information for speakers of OARC 41:

  * Your talk will be broadcast live and recorded for future reference
  * Your presentation slides will be available for delegates and others 
to download and refer to, before, during and after the meeting
  * Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC. 
It would be very useful to have your slides (even if draft) ready for 
this.

Note: DNS-OARC provides registration fee waivers for the workshop to 
support those who are part of underrepresented groups to speak at and/or 
attend DNS-OARC. More details will be provided when registration opens.

  If you have questions or concerns you can contact the Programme 
Committee:
    https://www.dns-oarc.net/oarc/programme via submissions at dns-oarc.net

  OARC depends on sponsorship to fund its workshops and associated 
social events. Please contact sponsor at dns-oarc.net if your organization 
is interested in becoming a sponsor.

  (Please note that OARC is run on a non-profit basis, and is not in a 
position to reimburse expenses or time for speakers at its meetings.)

  John Todd, for the DNS-OARC Programme Committee

--
John Todd - jtodd at quad9.net
General Manager - Quad9 Recursive Resolver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230426/f73a4aff/attachment.html>

From trini at konsulko.com  Tue Apr 25 18:13:10 2023
From: trini at konsulko.com (Tom Rini)
Date: Tue, 25 Apr 2023 14:13:10 -0400
Subject: Spectrum networks IPv6 access issue
Message-ID: <20230425181310.GL1134230@bill-the-cat>

Hey all,

I'm posting this here in hopes of getting the attention of someone that
can get this issue resolved, or at least an internal ticket filed. I've
tried the customer-facing tech support and not been able to get such a
thing done.

In short, from within Spectrum's US IPv6 network (verified in both North
Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is
unreachable and connections time out. This site is otherwise fine and
globally accessible via IPv6, tested on both Qwest and T-Mobile hosted
systems.  This is a regression from some time in early April this year.

-- 
Tom

From d at nielmarks.com  Wed Apr 26 16:15:45 2023
From: d at nielmarks.com (Daniel Marks)
Date: Wed, 26 Apr 2023 12:15:45 -0400
Subject: Spectrum networks IPv6 access issue
In-Reply-To: <20230425181310.GL1134230@bill-the-cat>
References: <20230425181310.GL1134230@bill-the-cat>
Message-ID: <7C257090-F16F-46A1-8183-C78EFF163D9F@nielmarks.com>

We?ve been having IPv6 issues for weeks in Texas on Spectrum, we have an Enterprise support ticket open on our IP transit circuits but I?ve seen no real movement.

Our issue is being tracked internally as INC000026440632, but I believe it?s specific to the DFW area.

Daniel Marks
d at nielmarks.com

> On Apr 26, 2023, at 11:52, Tom Rini <trini at konsulko.com> wrote:
> ?Hey all,
> 
> I'm posting this here in hopes of getting the attention of someone that
> can get this issue resolved, or at least an internal ticket filed. I've
> tried the customer-facing tech support and not been able to get such a
> thing done.
> 
> In short, from within Spectrum's US IPv6 network (verified in both North
> Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is
> unreachable and connections time out. This site is otherwise fine and
> globally accessible via IPv6, tested on both Qwest and T-Mobile hosted
> systems.  This is a regression from some time in early April this year.
> 
> -- 
> Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2329 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230426/5d0b6420/attachment.bin>

From matthew at corp.crocker.com  Wed Apr 26 17:59:06 2023
From: matthew at corp.crocker.com (Matthew Crocker)
Date: Wed, 26 Apr 2023 17:59:06 +0000
Subject: UltraDNS contact
Message-ID: <BL0PR14MB35540F6FD52923B741F8477B82659@BL0PR14MB3554.namprd14.prod.outlook.com>


Can anyone from UltraDNS contact me off list please?   I have some security issues I?d like to discuss with you.

Thanks

-Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230426/ac05cab2/attachment.html>

From saundeb1 at ohio.edu  Wed Apr 26 17:46:14 2023
From: saundeb1 at ohio.edu (Saunders, Brandon)
Date: Wed, 26 Apr 2023 17:46:14 +0000
Subject: [External] Spectrum networks IPv6 access issue
In-Reply-To: <20230425181310.GL1134230@bill-the-cat>
References: <20230425181310.GL1134230@bill-the-cat>
Message-ID: <DS7PR01MB78084C824BEE8108A604EEF6FA659@DS7PR01MB7808.prod.exchangelabs.com>

If it is helpful, I am on Spectrum in Ohio and I can reach that address from my IPv6 test system.  This is on a commercial account with a provider assigned network.  My system is at ip6echo.net.  You are welcome to ping and traceroute to it if that is helpful to you.  

A friend CANNOT get to that address from a Spectrum residential account also in my area.

Brandon



-----Original Message-----
From: NANOG <nanog-bounces+saundeb1=ohio.edu at nanog.org> On Behalf Of Tom Rini
Sent: Tuesday, April 25, 2023 2:13 PM
To: nanog at nanog.org
Subject: [External] Spectrum networks IPv6 access issue

Use caution with links and attachments.

Hey all,

I'm posting this here in hopes of getting the attention of someone that can get this issue resolved, or at least an internal ticket filed. I've tried the customer-facing tech support and not been able to get such a thing done.

In short, from within Spectrum's US IPv6 network (verified in both North Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is unreachable and connections time out. This site is otherwise fine and globally accessible via IPv6, tested on both Qwest and T-Mobile hosted systems.  This is a regression from some time in early April this year.

--
Tom

From nanog at ve4.ca  Thu Apr 27 01:53:13 2023
From: nanog at ve4.ca (Glen A. Pearce)
Date: Wed, 26 Apr 2023 19:53:13 -0600
Subject: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a
 phishing E-mail or real...)
In-Reply-To: <ZEatMfN/gag7KB8/@jima.tpb.net>
References: <353e8a6d-56f0-ac2f-4b80-d9d9f88ccaaa@ve4.ca>
 <eb55f074-6a38-7173-02ca-1279aae08f5a@ve4.ca> <ZEatMfN/gag7KB8/@jima.tpb.net>
Message-ID: <7d4bbd74-ea92-f00c-6d33-aabc6a9b27ae@ve4.ca>

On 24/04/2023 10:24 a.m., Niels Bakker wrote:
> * nanog at ve4.ca (Glen A. Pearce) [Mon 24 Apr 2023, 17:42 CEST]:
>> Well, I eventually had a friend open the attachment on his Linux machine
>
> Not necessarily a safe idea:
> https://www.welivesecurity.com/2023/04/20/linux-malware-strengthens-links-lazarus-3cx-supply-chain-attack/
> (scroll down to "Operation DreamJob with a Linux payload", sadly no 
> anchors)
>
>
> ????-- Niels.

Thanks for the heads up on that.? My situation (in this one case) was a 
little different
from the example in the article you sent as I had already verified it 
was a text file
(and not another type masquerading as a text file with funny 
characters).? I was just
concerned because I was wondering if someone had found a way to compromise
Windows Notepad (or at least some versions of it because Microsoft likes 
to keep
changing things).? I still kinda wonder now if there is some 
vulnerability in Microsoft
Notepad somewhere because of a "feature" someone decided to add along 
the way
that nobody needed and almost nobody known about....

The link you included might still save someone a lot of headaches one day.

I checked with my friend, what he did was use Linux on a virtual machine 
with a static
hard drive then started "Nano" at the command line and used that to open 
the file I
sent him.? He's a lot more expert than me so I tend to trust that he 
knows what he's
doing even if he doesn't fill me in on all the details.? I guess in this 
case he figured he
didn't need to fill me in on them until I asked.? Though I did pass on 
the article you
sent in case it's relevant to something he encounters in the future.

-- 
Glen A. Pearce
gap at ve4.ca
Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk.
Very Eager 4 Tees
http://www.ve4.ca
ARIN Handle VET-17


From jeffp at jeffp.us  Wed Apr 26 21:27:23 2023
From: jeffp at jeffp.us (Jeff P)
Date: Wed, 26 Apr 2023 14:27:23 -0700
Subject: [External] Spectrum networks IPv6 access issue
In-Reply-To: <DS7PR01MB78084C824BEE8108A604EEF6FA659@DS7PR01MB7808.prod.exchangelabs.com>
References: <20230425181310.GL1134230@bill-the-cat>
 <DS7PR01MB78084C824BEE8108A604EEF6FA659@DS7PR01MB7808.prod.exchangelabs.com>
Message-ID: <e905a94d-eadc-b26c-b27b-0dda7d3eace4@jeffp.us>

For what it's worth, on Spectrum Residential here in LAX and I can reach 
ip6echo.net and Google's public ipv6.google.com sites via residential 
service...? I have my own modems and routers, which may make the 
difference in my case... Spectrum does indicate that IPv6 my need to be 
enabled on their routers...

https://www.spectrum.net/support/internet/ipv6-faq

jeffp at jeffp-Linux:~$ ping -6 ip6echo.net
PING ip6echo.net(ip6echo.net (2600:5c01:f876:10::53)) 56 data bytes
64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=1 ttl=51 
time=76.1 ms
64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=2 ttl=51 
time=78.4 ms
64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=3 ttl=51 
time=76.5 ms

jeffp at jeffp-Linux:~$ ping -6 ipv6.google.com
PING ipv6.google.com(lax31s06-in-x0e.1e100.net 
(2607:f8b0:4007:811::200e)) 56 data bytes
64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e): 
icmp_seq=1 ttl=116 time=12.6 ms
64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e): 
icmp_seq=2 ttl=116 time=14.4 ms


I normally use the Google IPv6 site for such tests to avoid irritating 
private hosts, so a big thanks to Brandon for offering that alternative!

Jeffp

On 4/26/23 10:46, Saunders, Brandon wrote:
> If it is helpful, I am on Spectrum in Ohio and I can reach that address from my IPv6 test system.  This is on a commercial account with a provider assigned network.  My system is at ip6echo.net.  You are welcome to ping and traceroute to it if that is helpful to you.
>
> A friend CANNOT get to that address from a Spectrum residential account also in my area.
>
> Brandon
>
>
>
> -----Original Message-----
> From: NANOG<nanog-bounces+saundeb1=ohio.edu at nanog.org>  On Behalf Of Tom Rini
> Sent: Tuesday, April 25, 2023 2:13 PM
> To:nanog at nanog.org
> Subject: [External] Spectrum networks IPv6 access issue
>
> Use caution with links and attachments.
>
> Hey all,
>
> I'm posting this here in hopes of getting the attention of someone that can get this issue resolved, or at least an internal ticket filed. I've tried the customer-facing tech support and not been able to get such a thing done.
>
> In short, from within Spectrum's US IPv6 network (verified in both North Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is unreachable and connections time out. This site is otherwise fine and globally accessible via IPv6, tested on both Qwest and T-Mobile hosted systems.  This is a regression from some time in early April this year.
>
> --
> Tom

-- 
JeffP

"It is not for me to place expectations on someone and fail them for not meeting them. It's my goal to encourage others to raise their expectations of themselves, to educate them and help them gain the skills needed to meet their goals and encourage them to succeed in attaining them."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230426/1faf6013/attachment.html>

From 23020221154130 at stu.xmu.edu.cn  Thu Apr 27 05:46:49 2023
From: 23020221154130 at stu.xmu.edu.cn (=?UTF-8?B?5b6Q5oOg5LiJ?=)
Date: Thu, 27 Apr 2023 13:46:49 +0800 (GMT+08:00)
Subject: Questionnaire on building real network configuration dataset
Message-ID: <115a55ed.16f.187c13ffdef.Coremail.23020221154130@stu.xmu.edu.cn>

Dear NANOG community members,




We are post graduate students majoring in computer network and we are now conducting a research project aimed at setting up an open dataset of real network configurations for experiment needs. We think it will be a contributing work for network verification evaluations. As part of this effort, we are reaching out to the community to request your help in filling out a short questionnaire.




Your participation in this survey would be greatly appreciated and valuable for our research. It will take only about 2-3 minutes of your time and your responses will be kept strictly confidential. 




To participate in the survey, please click on the following link: https://docs.google.com/forms/d/1XPBxVH40UcQRMZf-H-ENj4AUZQDEw8xxQtllyylCl4E/edit




Please note that the survey will be open for one month, and we kindly ask you to complete it by the end of May. Thank you in advance for your participation and support of our research. 




Best regards,

Huisan

















-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/9be97f18/attachment.html>

From jhellenthal at dataix.net  Thu Apr 27 13:43:04 2023
From: jhellenthal at dataix.net (J. Hellenthal)
Date: Thu, 27 Apr 2023 13:43:04 +0000
Subject: Questionnaire on building real network configuration dataset
In-Reply-To: <115a55ed.16f.187c13ffdef.Coremail.23020221154130@stu.xmu.edu.cn>
References: <115a55ed.16f.187c13ffdef.Coremail.23020221154130@stu.xmu.edu.cn>
Message-ID: <ZEp76NFM0Xw2WXy_@DataIX.net>


It might be a better option for you to un-signin this survey...

Just a suggestion.

On Thu, Apr 27, 2023 at 01:46:49PM +0800, ??? wrote:
>    Dear NANOG community members,
> 
>    We are post graduate students majoring in computer network and we are now
>    conducting a research project aimed at setting up an open dataset of real
>    network configurations for experiment needs. We think it will be a
>    contributing work for network verification evaluations. As part of this
>    effort, we are reaching out to the community to request your help in
>    filling out a short questionnaire.
> 
>    Your participation in this survey would be greatly appreciated and
>    valuable for our research. It will take only about 2-3 minutes of your
>    time and your responses will be kept strictly confidential. 
> 
>    To participate in the survey, please click on the following
>    link: https://docs.google.com/forms/d/1XPBxVH40UcQRMZf-H-ENj4AUZQDEw8xxQtllyylCl4E/edit
> 
>    Please note that the survey will be open for one month, and we kindly ask
>    you to complete it by the end of May. Thank you in advance for your
>    participation and support of our research. 
> 
>    Best regards,
> 
>    Huisan

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 533 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/bd686b90/attachment.sig>

From boothf at boothlabs.me  Thu Apr 27 13:44:21 2023
From: boothf at boothlabs.me (boothf at boothlabs.me)
Date: Thu, 27 Apr 2023 09:44:21 -0400
Subject: [External] Spectrum networks IPv6 access issue
In-Reply-To: <e905a94d-eadc-b26c-b27b-0dda7d3eace4@jeffp.us>
References: <20230425181310.GL1134230@bill-the-cat>
 <DS7PR01MB78084C824BEE8108A604EEF6FA659@DS7PR01MB7808.prod.exchangelabs.com>
 <e905a94d-eadc-b26c-b27b-0dda7d3eace4@jeffp.us>
Message-ID: <D7CE615E-63F6-4AEF-8F06-41186DDE481C@boothlabs.me>

I?m in the northeast and I can confirm on a Spectrum Enterprise connection I have issues tracerouting to 2604:1380:4641:c500::1.

Gets to e0-33.core1.nyc7.he.net and then packets just disappear:

 Host                                                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                                                                   0.0%   108    1.0   1.7   0.8  26.3   3.3
 2. 2602:XXX:XXXX:X::X                                                                         0.0%   108    4.4   6.6   4.2  27.9   4.0
 3. 2602:XXX:XXXX:X::XXX                                                                       0.0%   108    3.1   3.0   3.0   3.5   0.0
 4. 2604:XXXX:X:X::X:XXXX                                                                      0.0%   108    5.2   4.8   3.3  37.1   5.0
 5. lag-15.srspny0101h.netops.charter.com                                                      0.0%   108    3.9  20.8   3.6 371.6  45.4
 6. lag-32.albynyyf02r.netops.charter.com                                                     44.4%   108    4.9   4.9   4.8   5.5   0.1
 7. lag-26.rcr01albynyyf.netops.charter.com                                                   80.4%   108    5.1   5.3   5.0   7.7   0.6
 8. lag-416.nycmny837aw-bcr00.netops.charter.com                                              57.9%   108   37.4  14.5  12.7  54.4   7.1
 9. lag-1.pr2.nyc20.netops.charter.com                                                         0.0%   108   49.8  17.1  12.3  65.7  11.0
10. e0-33.core1.nyc7.he.net                                                                    0.0%   108   12.9  13.2  12.8  19.8   0.7
11. (waiting for reply)

Trying from another network and I was able to get through:

 Host                                                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ca.tor.ix.caramelfox.net                                                                   0.0%    25   45.7  45.9  43.9  50.9   2.0
 2. (waiting for reply)
 3. (waiting for reply)
 4. ve955.core2.stl1.he.net                                                                   56.0%    25   62.0  63.9  62.0  67.6   2.0
 5. (waiting for reply)
 6. (waiting for reply)
 7. (waiting for reply)
 8. equinix-ix.dfw2.packet.net                                                                 0.0%    25   81.2  86.0  77.8 103.3   8.4
 9. (waiting for reply)
10. (waiting for reply)
11. dfw.source.kernel.org                                                                      0.0%    24   77.6  78.1  77.0  82.5   1.1


Maybe something in Hurricane Electric?s network potentially not getting these packets where they need to go?


> On Apr 26, 2023, at 5:27 PM, Jeff P <jeffp at jeffp.us> wrote:
> 
> For what it's worth, on Spectrum Residential here in LAX and I can reach ip6echo.net and Google's public ipv6.google.com sites via residential service...  I have my own modems and routers, which may make the difference in my case... Spectrum does indicate that IPv6 my need to be enabled on their routers... 
> 
> https://www.spectrum.net/support/internet/ipv6-faq
> 
> jeffp at jeffp-Linux:~$ ping -6 ip6echo.net 
> PING ip6echo.net(ip6echo.net (2600:5c01:f876:10::53)) 56 data bytes 
> 64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=1 ttl=51 time=76.1 ms 
> 64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=2 ttl=51 time=78.4 ms 
> 64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=3 ttl=51 time=76.5 ms
> 
> jeffp at jeffp-Linux:~$ ping -6 ipv6.google.com 
> PING ipv6.google.com(lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e)) 56 data bytes 
> 64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e): icmp_seq=1 ttl=116 time=12.6 ms 
> 64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e): icmp_seq=2 ttl=116 time=14.4 ms 
> 
> 
> I normally use the Google IPv6 site for such tests to avoid irritating private hosts, so a big thanks to Brandon for offering that alternative!
> 
> Jeffp
> 
> On 4/26/23 10:46, Saunders, Brandon wrote:
>> If it is helpful, I am on Spectrum in Ohio and I can reach that address from my IPv6 test system.  This is on a commercial account with a provider assigned network.  My system is at ip6echo.net.  You are welcome to ping and traceroute to it if that is helpful to you.  
>> 
>> A friend CANNOT get to that address from a Spectrum residential account also in my area.
>> 
>> Brandon
>> 
>> 
>> 
>> -----Original Message-----
>> From: NANOG <nanog-bounces+saundeb1=ohio.edu at nanog.org> <mailto:nanog-bounces+saundeb1=ohio.edu at nanog.org> On Behalf Of Tom Rini
>> Sent: Tuesday, April 25, 2023 2:13 PM
>> To: nanog at nanog.org <mailto:nanog at nanog.org>
>> Subject: [External] Spectrum networks IPv6 access issue
>> 
>> Use caution with links and attachments.
>> 
>> Hey all,
>> 
>> I'm posting this here in hopes of getting the attention of someone that can get this issue resolved, or at least an internal ticket filed. I've tried the customer-facing tech support and not been able to get such a thing done.
>> 
>> In short, from within Spectrum's US IPv6 network (verified in both North Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is unreachable and connections time out. This site is otherwise fine and globally accessible via IPv6, tested on both Qwest and T-Mobile hosted systems.  This is a regression from some time in early April this year.
>> 
>> --
>> Tom
> -- 
> JeffP
> 
> "It is not for me to place expectations on someone and fail them for not meeting them. It's my goal to encourage others to raise their expectations of themselves, to educate them and help them gain the skills needed to meet their goals and encourage them to succeed in attaining them."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/ef28d5be/attachment.html>

From matthew at corp.crocker.com  Thu Apr 27 13:46:04 2023
From: matthew at corp.crocker.com (Matthew Crocker)
Date: Thu, 27 Apr 2023 13:46:04 +0000
Subject: Dormant space on blacklists,  how can I resolve this?
Message-ID: <BL0PR14MB35548616BEB2EDADCB17F9C7826A9@BL0PR14MB3554.namprd14.prod.outlook.com>


Hello,

I run Crocker Communications (AS7849) and have ARIN allocations of 161.77.0.0/16 & 66.59.48.0/20.   The 66.58.48.0/20 space was used for our datacenter which shutdown a couple years ago.  The space has mostly been dormant for the past couple years.   I?m now starting to assign 66.59.[55-60].0/24 to a new group of residential FTTH customers.   The customers are getting access denied messages from Akamai based websites.

What can I do to get Akamai to unblock the 66.59.48.0/20 space.
Is there a website I can look to research the reputation of the subnets?  They haven?t been used in years so I would expect them to be pretty clean.

Thanks

-Matt


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/e21d9b72/attachment.html>

From chuckchurch at gmail.com  Thu Apr 27 13:51:36 2023
From: chuckchurch at gmail.com (Chuck Church)
Date: Thu, 27 Apr 2023 09:51:36 -0400
Subject: Standard DC rack rail distance, front to back question
Message-ID: <008601d9790f$62611460$27233d20$@gmail.com>

Hey all.  Question about standard 4 post racks.  We bought some that are
adjustable.  Unfortunately, the posts are very flimsy, as these are some
fancy cabinets with spacing on the sides for vertical patch panels, etc.  We
found that 2 post mounting of most Cisco devices (namely Cat 9500 1RU
switches) are sagging quite bad.   We're used to the new server type rails
that extend to support most reasonable distances front rails to back for 4
post mounting.  However, for a Cisco ASA1001, there aren't rails, but rather
front and back 'ears' you use to hit both front and back posts.  These would
appear to not have any adjustability, the front to back post distance would
seem to need to match the ears, I assume they don't adjust placement on the
router much.  Is there a 'standard' distance between front and back rails
that devices usually adhere to?  Googling didn't find an answer readily.
These are 19" wide cabinets by the way.  

 

Thanks,

 

Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/151a30f7/attachment.html>

From lists at mtin.net  Thu Apr 27 14:00:39 2023
From: lists at mtin.net (Justin Wilson (Lists))
Date: Thu, 27 Apr 2023 10:00:39 -0400
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <008601d9790f$62611460$27233d20$@gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
Message-ID: <21AEFAD7-0045-4F93-A28D-3C02581E0F16@mtin.net>

I have not seen a standard on cabinets.  I have gear in a wide variety of racks.  Some of are real shallow.  Some are deep.  I use these to generically solve the sagging issue.


https://www.amazon.com/dp/B00XXDJASY?ref=nb_sb_ss_w_as-reorder-t1_k1_1_11&amp=&crid=EFCM0EZP8BMA&amp=&sprefix=navpoint+ra?
NavePoint Universal 1U Rack Mount 4-Post Shelf Rail for Dell Compaq IBM HP APC - 33.5 Inches deep
amazon.com





Justin Wilson
j2sw at mtin.net

?
https://j2sw.com (AS399332)
https://blog.j2sw.com - Podcast and Blog

> On Apr 27, 2023, at 9:51 AM, Chuck Church <chuckchurch at gmail.com> wrote:
> 
> Hey all.  Question about standard 4 post racks.  We bought some that are adjustable.  Unfortunately, the posts are very flimsy, as these are some fancy cabinets with spacing on the sides for vertical patch panels, etc.  We found that 2 post mounting of most Cisco devices (namely Cat 9500 1RU switches) are sagging quite bad.   We?re used to the new server type rails that extend to support most reasonable distances front rails to back for 4 post mounting.  However, for a Cisco ASA1001, there aren?t rails, but rather front and back ?ears? you use to hit both front and back posts.  These would appear to not have any adjustability, the front to back post distance would seem to need to match the ears, I assume they don?t adjust placement on the router much.  Is there a ?standard? distance between front and back rails that devices usually adhere to?  Googling didn?t find an answer readily.  These are 19? wide cabinets by the way.  
>  
> Thanks,
>  
> Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/0f5788d0/attachment.html>

From mel at beckman.org  Thu Apr 27 14:03:23 2023
From: mel at beckman.org (Mel Beckman)
Date: Thu, 27 Apr 2023 14:03:23 +0000
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <008601d9790f$62611460$27233d20$@gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
Message-ID: <43378B52-24C5-4167-8061-3C8DF8EE7A8B@beckman.org>

We use shelves rather than hanging all the weight of racked gear on the ears. That rarely works well, but a 4-post shelf for every half-dozen or so devices works wonderfully. These shelves are usually quite adjustable.

 -mel beckman

On Apr 27, 2023, at 6:54 AM, Chuck Church <chuckchurch at gmail.com> wrote:

?
Hey all.  Question about standard 4 post racks.  We bought some that are adjustable.  Unfortunately, the posts are very flimsy, as these are some fancy cabinets with spacing on the sides for vertical patch panels, etc.  We found that 2 post mounting of most Cisco devices (namely Cat 9500 1RU switches) are sagging quite bad.   We?re used to the new server type rails that extend to support most reasonable distances front rails to back for 4 post mounting.  However, for a Cisco ASA1001, there aren?t rails, but rather front and back ?ears? you use to hit both front and back posts.  These would appear to not have any adjustability, the front to back post distance would seem to need to match the ears, I assume they don?t adjust placement on the router much.  Is there a ?standard? distance between front and back rails that devices usually adhere to?  Googling didn?t find an answer readily.  These are 19? wide cabinets by the way.

Thanks,

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/bdb23990/attachment.html>

From chris at marget.com  Thu Apr 27 14:04:37 2023
From: chris at marget.com (Chris Marget)
Date: Thu, 27 Apr 2023 10:04:37 -0400
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <008601d9790f$62611460$27233d20$@gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
Message-ID: <CAAG5dDBCjNBUAkcDM5EVbPEnJwwnRwKXh7iXLb9haUmP-K3__Q@mail.gmail.com>

On Thu, Apr 27, 2023 at 9:53?AM Chuck Church <chuckchurch at gmail.com> wrote:

> for a Cisco ASA1001, there aren?t rails, but rather front and back ?ears?
> you use to hit both front and back posts.
>

Front *and* back ears? I'm not sure what an ASA 1001 is (ASR?) but my
experience with these boxes is that they have a single pair of ears which
can be mounted front OR back.

The heavier / deeper 1RU devices do tend to sag alarmingly.


>  Is there a ?standard? distance between front and back rails that devices
> usually adhere to?
>

If you're thinking of setting the front/back distance to accommodate a
specific device, table 2 might be of some interest:
https://i.dell.com/sites/doccontent/business/solutions/engineering-docs/en/Documents/rail-rack-matrix.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/5a68bcdf/attachment.html>

From Roland.Dobbins at netscout.com  Thu Apr 27 14:05:08 2023
From: Roland.Dobbins at netscout.com (Dobbins, Roland)
Date: Thu, 27 Apr 2023 14:05:08 +0000
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <008601d9790f$62611460$27233d20$@gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
Message-ID: <2D1BDBBB-64C6-4458-8410-B4CFD5ED08EB@netscout.com>



On 27 Apr 2023, at 20:51, Chuck Church <chuckchurch at gmail.com<mailto:chuckchurch at gmail.com>> wrote:

  Is there a ?standard? distance between front and back rails that devices usually adhere to?

There isn?t a standard for rack depth, AFAIK, but one typically sees anywhere from 27in/69cm ? 50in/127cm, in my experience.  42in/106.7cm & 48in/122cm are quite common depth dimensions.

Others here may have more specific information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/654e8e9c/attachment.html>

From bellman at nsc.liu.se  Thu Apr 27 14:39:40 2023
From: bellman at nsc.liu.se (Thomas Bellman)
Date: Thu, 27 Apr 2023 16:39:40 +0200
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <2D1BDBBB-64C6-4458-8410-B4CFD5ED08EB@netscout.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <2D1BDBBB-64C6-4458-8410-B4CFD5ED08EB@netscout.com>
Message-ID: <61dff7ba-66ac-93aa-3744-9badde05dbc0@nsc.liu.se>

On 2023-04-27 16:05, Dobbins, Roland via NANOG wrote:

> There isn?t a standard for rack depth, AFAIK, but one typically sees
> anywhere from 27in/69cm ? 50in/127cm, in my experience.  42in/106.7cm
> & 48in/122cm are quite common depth dimensions.

You are talking about the depth of the entire *cabinet*, right?
I.e, how much floor space it occupies.  Because the OP asked about
the distance between the front and rear mounting *posts*, not the
full cabinet depth.  (127 cm between the posts would require the
cabinet to be 150-160 cm deep at least, and I have never seen racks
that deep.  Last time I checked, the deepest racks from e.g. Rittal
were 120 cm.)


	/Bellman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/71dee425/attachment.sig>

From manager at monmouth.com  Thu Apr 27 15:17:27 2023
From: manager at monmouth.com (Mark Stevens)
Date: Thu, 27 Apr 2023 11:17:27 -0400
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <CAAG5dDBCjNBUAkcDM5EVbPEnJwwnRwKXh7iXLb9haUmP-K3__Q@mail.gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <CAAG5dDBCjNBUAkcDM5EVbPEnJwwnRwKXh7iXLb9haUmP-K3__Q@mail.gmail.com>
Message-ID: <cf0e856a-edb4-9094-60ce-20a64b92feef@monmouth.com>

Lucky you with a 19" data rack. All I have are 23" telco racks but I 
will say, the 23" extension ears from Cisco are serious and my router 
chassis' don't sag.

Mark

On 4/27/2023 10:04 AM, Chris Marget wrote:
>
> On Thu, Apr 27, 2023 at 9:53?AM Chuck Church <chuckchurch at gmail.com> 
> wrote:
>
>     for a Cisco ASA1001, there aren?t rails, but rather front and back
>     ?ears? you use to hit both front and back posts.
>
>
> Front *and* back ears? I'm not sure what an ASA 1001 is (ASR?) but my 
> experience with these boxes is that they have?a single pair of ears 
> which can be mounted front OR back.
>
> The heavier / deeper 1RU devices do tend to sag alarmingly.
>
>     ?Is there a ?standard? distance between front and back rails that
>     devices usually adhere to?
>
>
> If you're thinking of setting the front/back distance to accommodate?a 
> specific?device, table 2 might be of some interest:
> https://i.dell.com/sites/doccontent/business/solutions/engineering-docs/en/Documents/rail-rack-matrix.pdf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/cf878a13/attachment.html>

From tgarrison at netviscom.com  Thu Apr 27 15:35:14 2023
From: tgarrison at netviscom.com (Travis Garrison)
Date: Thu, 27 Apr 2023 15:35:14 +0000
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <008601d9790f$62611460$27233d20$@gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
Message-ID: <CH0PR18MB4307EB84FB0A1600609AD753AE6A9@CH0PR18MB4307.namprd18.prod.outlook.com>

We have used these with great luck. Might be able to find some 1U rails instead of the standard 2U.

https://www.amazon.com/APC-SU032A-4-Post-Rackmount-Rails/dp/B00007L3MX

Thanks
Travis

From: NANOG <nanog-bounces+tgarrison=netviscom.com at nanog.org> On Behalf Of Chuck Church
Sent: Thursday, April 27, 2023 8:52 AM
To: nanog at nanog.org
Subject: Standard DC rack rail distance, front to back question

Hey all.  Question about standard 4 post racks.  We bought some that are adjustable.  Unfortunately, the posts are very flimsy, as these are some fancy cabinets with spacing on the sides for vertical patch panels, etc.  We found that 2 post mounting of most Cisco devices (namely Cat 9500 1RU switches) are sagging quite bad.   We're used to the new server type rails that extend to support most reasonable distances front rails to back for 4 post mounting.  However, for a Cisco ASA1001, there aren't rails, but rather front and back 'ears' you use to hit both front and back posts.  These would appear to not have any adjustability, the front to back post distance would seem to need to match the ears, I assume they don't adjust placement on the router much.  Is there a 'standard' distance between front and back rails that devices usually adhere to?  Googling didn't find an answer readily.  These are 19" wide cabinets by the way.

Thanks,

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/7efb0317/attachment.html>

From chuckchurch at gmail.com  Thu Apr 27 15:36:02 2023
From: chuckchurch at gmail.com (Chuck Church)
Date: Thu, 27 Apr 2023 11:36:02 -0400
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <cf0e856a-edb4-9094-60ce-20a64b92feef@monmouth.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <CAAG5dDBCjNBUAkcDM5EVbPEnJwwnRwKXh7iXLb9haUmP-K3__Q@mail.gmail.com>
 <cf0e856a-edb4-9094-60ce-20a64b92feef@monmouth.com>
Message-ID: <00e001d9791d$f9607140$ec2153c0$@gmail.com>

Hey all, sorry I did mean to say ASR1001 (an X model to be exact).  The 4 post mounting they show in a hardware mounting doc uses front and back ears, which I?ve never done:
https://www.cisco.com/c/en/us/td/docs/routers/asr1000/install/guide/asr1routers/asr-1000-series-hig/asr-hig-1001.html#task_1205646
see figure 16 slightly down from there.  

I do see some generic rails from TrippLite that probably would work, as well as shelves.   I was hoping a standard depth that most vendors honored for 4 post existed, but it doesn?t seem likely.  We?ll have a variety of PaloAlto, Cisco, Checkpoint, and others co-habiting.

 

Chuck

 

From: NANOG <nanog-bounces+chuckchurch=gmail.com at nanog.org> On Behalf Of Mark Stevens
Sent: Thursday, April 27, 2023 11:17 AM
To: nanog at nanog.org
Subject: Re: Standard DC rack rail distance, front to back question

 

Lucky you with a 19" data rack. All I have are 23" telco racks but I will say, the 23" extension ears from Cisco are serious and my router chassis' don't sag.

Mark

On 4/27/2023 10:04 AM, Chris Marget wrote:

 

On Thu, Apr 27, 2023 at 9:53?AM Chuck Church <chuckchurch at gmail.com <mailto:chuckchurch at gmail.com> > wrote:

for a Cisco ASA1001, there aren?t rails, but rather front and back ?ears? you use to hit both front and back posts.

 

Front *and* back ears? I'm not sure what an ASA 1001 is (ASR?) but my experience with these boxes is that they have a single pair of ears which can be mounted front OR back.

The heavier / deeper 1RU devices do tend to sag alarmingly.

 

 Is there a ?standard? distance between front and back rails that devices usually adhere to?

 

If you're thinking of setting the front/back distance to accommodate a specific device, table 2 might be of some interest:

https://i.dell.com/sites/doccontent/business/solutions/engineering-docs/en/Documents/rail-rack-matrix.pdf

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/64dd9352/attachment.html>

From jared at puck.nether.net  Thu Apr 27 16:29:17 2023
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 27 Apr 2023 12:29:17 -0400
Subject: Dormant space on blacklists,  how can I resolve this?
In-Reply-To: <BL0PR14MB35548616BEB2EDADCB17F9C7826A9@BL0PR14MB3554.namprd14.prod.outlook.com>
References: <BL0PR14MB35548616BEB2EDADCB17F9C7826A9@BL0PR14MB3554.namprd14.prod.outlook.com>
Message-ID: <A58F651D-EF5A-433C-A8AF-4C43A0AFEB55@puck.nether.net>

I?ll help you off-list.  

- Jared

> On Apr 27, 2023, at 9:46 AM, Matthew Crocker <matthew at corp.crocker.com> wrote:
> 
> 
> Hello,
>  
> I run Crocker Communications (AS7849) and have ARIN allocations of 161.77.0.0/16 & 66.59.48.0/20.   The 66.58.48.0/20 space was used for our datacenter which shutdown a couple years ago.  The space has mostly been dormant for the past couple years.   I?m now starting to assign 66.59.[55-60].0/24 to a new group of residential FTTH customers.   The customers are getting access denied messages from Akamai based websites.
>  
> What can I do to get Akamai to unblock the 66.59.48.0/20 space.
> Is there a website I can look to research the reputation of the subnets?  They haven?t been used in years so I would expect them to be pretty clean.
>  
> Thanks
>  
> -Matt


From news at nanog.org  Thu Apr 27 17:13:57 2023
From: news at nanog.org (Nanog News)
Date: Thu, 27 Apr 2023 13:13:57 -0400
Subject: Upcoming Event: ABQNOG + New ISOC Course
Message-ID: <CAHf5Ly0dYsFxANrxEoxaX=OiqRU4d710_UgMoPv6xzBhx+Rr-w@mail.gmail.com>

*Register Now for ABQNOG! *

ABQNOG will take place next Thursday 4, May 2023 in Albuquerque, NM.

ABQNOG allows industry professionals to network with others in the region
and learn more about the latest technology trends.

*REGISTER NOW* <https://www.nanog.org/events/abqnog-01/>
*New ISOC Course: Fundamentals of Designing and Deploying Computer Networks*

*Enroll in this New ISOC Moderated Course with an Instructor! *

*This course will feature:*

   - Fundamentals of Networking
   - Ethernet
   - WIFI Technologies
   - Planning, Design, and Deployment of Simple LANs
   - How to Connect a LAN to the Internet


*MORE INFO
<https://nanog.org/events/fundamentals-of-designing-and-deploying-computer-networks/>*
*Join the Women in Tech Affinity Group! *
*Have You Checked out our Online Community Discussion Threads? *

The NANOG Affinity Groups are part of the Community Forum and allow our
members to connect over shared interests.

Did you know NANOG has a Women in Tech (WIT) Affinity group? Connect with
other females in the tech industry and find mentorship and support while
sharing your experiences.
*MORE INFO  <https://community.nanog.org/c/women-in-tech/33>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/158382a5/attachment.html>

From warren at kumari.net  Thu Apr 27 18:13:11 2023
From: warren at kumari.net (Warren Kumari)
Date: Thu, 27 Apr 2023 11:13:11 -0700
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <43378B52-24C5-4167-8061-3C8DF8EE7A8B@beckman.org>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <43378B52-24C5-4167-8061-3C8DF8EE7A8B@beckman.org>
Message-ID: <CAHw9_i+sg9stF2VUF95rbS72=jBEseSjYD64+M0dYEN8jZj2Rg@mail.gmail.com>

A bunch of devices (eg Juniper MX240) come with a "small mounting shelf" ?
see Figure1, Figure 2 at
https://www.juniper.net/documentation/us/en/hardware/mx240/topics/topic-map/mx240-installing-the-router.html#id-installing-the-mx240-router-mounting-hardware-for-a-rack-or-cabinet

Their theory is that these get mounted on the "back" of the front rail, and
it supports the weight of the chassis. I generally just put these on the
font of the rear rail, and rest the back of the router on that. Seems to
work well - the chassis is narrow enough to slide if the cabinet is very
shallow, and the shelf is usually wide enough to deal with deeper
cabinets...

The other option is "Universal Rails" (AKA "those funny sort of L bracket
half shelf thingies") ? e.g:
https://www.cablesandkits.com/racks-cabinets/rack-mount-shelves-and-rails/rackmount-rails/ck-rckmntrls/pro-18146

W


On Thu, Apr 27, 2023 at 10:03 AM, Mel Beckman <mel at beckman.org> wrote:

> We use shelves rather than hanging all the weight of racked gear on the
> ears. That rarely works well, but a 4-post shelf for every half-dozen or so
> devices works wonderfully. These shelves are usually quite adjustable.
>
>  -mel beckman
>
> On Apr 27, 2023, at 6:54 AM, Chuck Church <chuckchurch at gmail.com> wrote:
>
> ?
>
> Hey all.  Question about standard 4 post racks.  We bought some that are
> adjustable.  Unfortunately, the posts are very flimsy, as these are some
> fancy cabinets with spacing on the sides for vertical patch panels, etc.
> We found that 2 post mounting of most Cisco devices (namely Cat 9500 1RU
> switches) are sagging quite bad.   We?re used to the new server type rails
> that extend to support most reasonable distances front rails to back for 4
> post mounting.  However, for a Cisco ASA1001, there aren?t rails, but
> rather front and back ?ears? you use to hit both front and back posts.
> These would appear to not have any adjustability, the front to back post
> distance would seem to need to match the ears, I assume they don?t adjust
> placement on the router much.  Is there a ?standard? distance between front
> and back rails that devices usually adhere to?  Googling didn?t find an
> answer readily.  These are 19? wide cabinets by the way.
>
>
>
> Thanks,
>
>
>
> Chuck
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/c654403d/attachment.html>

From randy at psg.com  Thu Apr 27 18:21:43 2023
From: randy at psg.com (Randy Bush)
Date: Thu, 27 Apr 2023 11:21:43 -0700
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <CAHw9_i+sg9stF2VUF95rbS72=jBEseSjYD64+M0dYEN8jZj2Rg@mail.gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <43378B52-24C5-4167-8061-3C8DF8EE7A8B@beckman.org>
 <CAHw9_i+sg9stF2VUF95rbS72=jBEseSjYD64+M0dYEN8jZj2Rg@mail.gmail.com>
Message-ID: <m21qk5b2yw.wl-randy@psg.com>

> "small mounting shelf"

we use mounting shelves for all sorts of recalcitrant devices

randy

From warren at kumari.net  Thu Apr 27 18:31:28 2023
From: warren at kumari.net (Warren Kumari)
Date: Thu, 27 Apr 2023 11:31:28 -0700
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <m21qk5b2yw.wl-randy@psg.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <43378B52-24C5-4167-8061-3C8DF8EE7A8B@beckman.org>
 <CAHw9_i+sg9stF2VUF95rbS72=jBEseSjYD64+M0dYEN8jZj2Rg@mail.gmail.com>
 <m21qk5b2yw.wl-randy@psg.com>
Message-ID: <CAHw9_iKo54M+WzfZY6pT8D4wEVwXBJ3y=rTmWaY1Vrx4Jv7qdw@mail.gmail.com>

On Thu, Apr 27, 2023 at 2:21 PM, Randy Bush <randy at psg.com> wrote:

> "small mounting shelf"
>
> we use mounting shelves for all sorts of recalcitrant devices
>


Yah, and for recalcitrant screws [0] ,  one of these:
https://amzn.to/41Z0YQq . It's super annoying, and somewhat terrifying to
be banging on a rack containing a bunch of spinning rust, but all too often
it's necessary?

W
[0]: You know, the ones that someone decided to put in with an electric
drill with the clutch set to "drill", or the ones where someone put a 10/32
screw into an M6 hole, or?



> randy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/64fc4d45/attachment.html>

From randy at psg.com  Thu Apr 27 18:36:54 2023
From: randy at psg.com (Randy Bush)
Date: Thu, 27 Apr 2023 11:36:54 -0700
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <CAHw9_iKo54M+WzfZY6pT8D4wEVwXBJ3y=rTmWaY1Vrx4Jv7qdw@mail.gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <43378B52-24C5-4167-8061-3C8DF8EE7A8B@beckman.org>
 <CAHw9_i+sg9stF2VUF95rbS72=jBEseSjYD64+M0dYEN8jZj2Rg@mail.gmail.com>
 <m21qk5b2yw.wl-randy@psg.com>
 <CAHw9_iKo54M+WzfZY6pT8D4wEVwXBJ3y=rTmWaY1Vrx4Jv7qdw@mail.gmail.com>
Message-ID: <m2zg6t9np5.wl-randy@psg.com>

> It's super annoying, and somewhat terrifying to be banging on a rack
> containing a bunch of spinning rust, but all too often it's necessary

we just moved a rack's content from the westin to komo plaza [0] and
only had one questionable drive.  terrifying is the right word.

randy

[0] - we may be the first rat off the sad westin ship

From athompson at merlin.mb.ca  Thu Apr 27 18:38:35 2023
From: athompson at merlin.mb.ca (Adam Thompson)
Date: Thu, 27 Apr 2023 18:38:35 +0000
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <00e001d9791d$f9607140$ec2153c0$@gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <CAAG5dDBCjNBUAkcDM5EVbPEnJwwnRwKXh7iXLb9haUmP-K3__Q@mail.gmail.com>
 <cf0e856a-edb4-9094-60ce-20a64b92feef@monmouth.com>
 <00e001d9791d$f9607140$ec2153c0$@gmail.com>
Message-ID: <YQBPR0101MB89256EDDD9DF2AB589D710079B6A9@YQBPR0101MB8925.CANPRD01.PROD.OUTLOOK.COM>

Fascinating.  I?ve never had an ASR-1001 come with two sets of ears, and I also note that the text of the instruction manual doesn?t reference the rear set at all.  I?ve never seen rear ears on any Cisco gear of my own, nor on anything the local ILEC has installed either.  I think the diagram is in error here.
However, the ?optional? step 1 is a pretty solid hint (i.e. pretty much a clue-by-four upside the head, here!) that you really should use a shelf.  As in you REALLY SHOULD USE A SHELF of some kind.

It doesn?t even have to be a full shelf ? any rail kit that relies on an ?L?-shaped profile instead of interlocking sliding bits should support an ASR-1001 just fine,  e.g. Tripp-Lite?s 4POSTRAILKIT1U.  RackSolutions? Universal Fixed Server Rack Rails<https://www.rack-solutions.ca/rack-rails.html> shows an example of a slightly different design that some prefer ? it all works about the same way.

The other thing I?ve done is used a shallow cantilever shelf to support the rear end of equipment that only comes with ears, if it?s deep enough ? something like StarTech?s CABSHELFV1U; the trick is finding a shelf that simultaneously doesn?t have the structural fold at the rear in the way AND doesn?t interfere with the device immediately below.  You?d think there?re only 2 geometries of product to worry about, but there are actually more b/c there?s no standard ? so test-fit first, or examine photos really carefully.  This is usually more of a hack than a permanent, supportable solution, but sometimes it can work very well and very cheaply.

Or, just make sure you?re installing the ASR immediately above something that does have proper 4-post mounting rails.  This is probably the single most common way to safely & securely mount ?eared? devices in a 4-post rack that I?ve seen ? that Dell PowerEdge server in the rack suddenly starts doing double-duty as a shelf!  (Or the UPS, or the KVM, or the ethernet switch, or?)

-Adam

Adam Thompson
Consultant, Infrastructure Services
[cid:image002.png at 01D9790D.8F568C90]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca<https://www.merlin.mb.ca/>
[cid:image003.png at 01D9790B.395F2C40]Chat with me on Teams<https://teams.microsoft.com/l/chat/0/0?users=athompson at merlin.mb.ca>


From: NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> On Behalf Of Chuck Church
Sent: Thursday, April 27, 2023 10:36 AM
To: 'Mark Stevens' <manager at monmouth.com>; nanog at nanog.org
Subject: RE: Standard DC rack rail distance, front to back question

Hey all, sorry I did mean to say ASR1001 (an X model to be exact).  The 4 post mounting they show in a hardware mounting doc uses front and back ears, which I?ve never done:
https://www.cisco.com/c/en/us/td/docs/routers/asr1000/install/guide/asr1routers/asr-1000-series-hig/asr-hig-1001.html#task_1205646
see figure 16 slightly down from there.

I do see some generic rails from TrippLite that probably would work, as well as shelves.   I was hoping a standard depth that most vendors honored for 4 post existed, but it doesn?t seem likely.  We?ll have a variety of PaloAlto, Cisco, Checkpoint, and others co-habiting.

Chuck

From: NANOG <nanog-bounces+chuckchurch=gmail.com at nanog.org<mailto:nanog-bounces+chuckchurch=gmail.com at nanog.org>> On Behalf Of Mark Stevens
Sent: Thursday, April 27, 2023 11:17 AM
To: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: Re: Standard DC rack rail distance, front to back question

Lucky you with a 19" data rack. All I have are 23" telco racks but I will say, the 23" extension ears from Cisco are serious and my router chassis' don't sag.

Mark

On 4/27/2023 10:04 AM, Chris Marget wrote:

On Thu, Apr 27, 2023 at 9:53?AM Chuck Church <chuckchurch at gmail.com<mailto:chuckchurch at gmail.com>> wrote:
for a Cisco ASA1001, there aren?t rails, but rather front and back ?ears? you use to hit both front and back posts.

Front *and* back ears? I'm not sure what an ASA 1001 is (ASR?) but my experience with these boxes is that they have a single pair of ears which can be mounted front OR back.

The heavier / deeper 1RU devices do tend to sag alarmingly.

 Is there a ?standard? distance between front and back rails that devices usually adhere to?

If you're thinking of setting the front/back distance to accommodate a specific device, table 2 might be of some interest:
https://i.dell.com/sites/doccontent/business/solutions/engineering-docs/en/Documents/rail-rack-matrix.pdf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/2be9d979/attachment.html>

From warren at kumari.net  Thu Apr 27 19:06:14 2023
From: warren at kumari.net (Warren Kumari)
Date: Thu, 27 Apr 2023 12:06:14 -0700
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <YQBPR0101MB89256EDDD9DF2AB589D710079B6A9@YQBPR0101MB8925.CANPRD01.PROD.OUTLOOK.COM>
References: <008601d9790f$62611460$27233d20$@gmail.com>
 <CAAG5dDBCjNBUAkcDM5EVbPEnJwwnRwKXh7iXLb9haUmP-K3__Q@mail.gmail.com>
 <cf0e856a-edb4-9094-60ce-20a64b92feef@monmouth.com>
 <00e001d9791d$f9607140$ec2153c0$@gmail.com>
 <YQBPR0101MB89256EDDD9DF2AB589D710079B6A9@YQBPR0101MB8925.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <CAHw9_iK_HMbt16Pm29HnMtNGGvfWFN=EFAga3As8iKiH2qBFHw@mail.gmail.com>

On Thu, Apr 27, 2023 at 2:38 PM, Adam Thompson <athompson at merlin.mb.ca>
wrote:

> Fascinating.  I?ve never had an ASR-1001 come with two sets of ears, and I
> also note that the text of the instruction manual doesn?t reference the
> rear set at all.  I?ve never seen rear ears on any Cisco gear of my own,
> nor on anything the local ILEC has installed either.  I think the diagram
> is in error here.
>
> However, the ?optional? step 1 is a pretty solid hint (i.e. pretty much a
> clue-by-four upside the head, here!) that you really should use a shelf.
> As in you REALLY SHOULD USE A SHELF of some kind.
>


Hah! Your mention of clue-by-fours while we are talking about drooping
routers reminds me of one of my more useful tools. I have a bunch of bits
of 2x4 which I've cut to around 1.75",  3.5", 7".

These are really really helpful when trying to mount a piece of
equipment under something which is either not screwed in, or is drooping at
the back.
You can use these as spacers when replacing a bit of gear which is
supporting other bits of gear, or, with a small shim/flat screwdriver as a
way to jack up a devices which is drooping at the back (and so slide in
another device). There are much more elegant solutions (like a
machinist jack), but a few off-cuts of 2x4 are cheap, light, and
non-marring.

This thread feels somewhat like "old NANOG" - people discussing actual
issues that they run into, and then sharing tips and tricks to help with
those issues. I miss this?

W


>
> It doesn?t even have to be a full shelf ? any rail kit that relies on an
> ?L?-shaped profile instead of interlocking sliding bits should support an
> ASR-1001 just fine,  e.g. Tripp-Lite?s 4POSTRAILKIT1U.  RackSolutions? Universal
> Fixed Server Rack Rails <https://www.rack-solutions.ca/rack-rails.html>
> shows an example of a slightly different design that some prefer ? it all
> works about the same way.
>
>
>
> The other thing I?ve done is used a shallow cantilever shelf to support
> the rear end of equipment that only comes with ears, if it?s deep enough ?
> something like StarTech?s CABSHELFV1U; the trick is finding a shelf that
> simultaneously doesn?t have the structural fold at the rear in the way AND
> doesn?t interfere with the device immediately below.  You?d think there?re
> only 2 geometries of product to worry about, but there are actually more
> b/c there?s no standard ? so test-fit first, or examine photos really
> carefully.  This is usually more of a hack than a permanent, supportable
> solution, but sometimes it can work very well and very cheaply.
>
>
>
> Or, just make sure you?re installing the ASR immediately above something
> that does have proper 4-post mounting rails.  This is probably the single
> most common way to safely & securely mount ?eared? devices in a 4-post rack
> that I?ve seen ? that Dell PowerEdge server in the rack suddenly starts
> doing double-duty as a shelf!  (Or the UPS, or the KVM, or the ethernet
> switch, or?)
>
>
>
> -Adam
>
>
>
> *Adam Thompson*
>
> Consultant, Infrastructure Services
>
>
>
> 100 - 135 Innovation Drive
>
> Winnipeg, MB R3T 6A8
>
> (204) 977-6824 or 1-800-430-6404 (MB only)
>
> https://www.merlin.mb.ca
>
> Chat with me on Teams
> <https://teams.microsoft.com/l/chat/0/0?users=athompson at merlin.mb.ca>
>
>
>
>
>
> *From:* NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> *On Behalf
> Of *Chuck Church
> *Sent:* Thursday, April 27, 2023 10:36 AM
> *To:* 'Mark Stevens' <manager at monmouth.com>; nanog at nanog.org
> *Subject:* RE: Standard DC rack rail distance, front to back question
>
>
>
> Hey all, sorry I did mean to say ASR1001 (an X model to be exact).  The 4
> post mounting they show in a hardware mounting doc uses front and back
> ears, which I?ve never done:
> https://www.cisco.com/c/en/us/td/docs/routers/asr1000/install/guide/
> asr1routers/asr-1000-series-hig/asr-hig-1001.html#task_1205646
> see figure 16 slightly down from there.
>
> I do see some generic rails from TrippLite that probably would work, as
> well as shelves.   I was hoping a standard depth that most vendors honored
> for 4 post existed, but it doesn?t seem likely.  We?ll have a variety of
> PaloAlto, Cisco, Checkpoint, and others co-habiting.
>
>
>
> Chuck
>
>
>
> *From:* NANOG <nanog-bounces+chuckchurch=gmail.com at nanog.org> *On Behalf
> Of *Mark Stevens
> *Sent:* Thursday, April 27, 2023 11:17 AM
> *To:* nanog at nanog.org
> *Subject:* Re: Standard DC rack rail distance, front to back question
>
>
>
> Lucky you with a 19" data rack. All I have are 23" telco racks but I will
> say, the 23" extension ears from Cisco are serious and my router chassis'
> don't sag.
>
> Mark
>
> On 4/27/2023 10:04 AM, Chris Marget wrote:
>
>
>
> On Thu, Apr 27, 2023 at 9:53?AM Chuck Church <chuckchurch at gmail.com>
> wrote:
>
> for a Cisco ASA1001, there aren?t rails, but rather front and back ?ears?
> you use to hit both front and back posts.
>
>
>
> Front *and* back ears? I'm not sure what an ASA 1001 is (ASR?) but my
> experience with these boxes is that they have a single pair of ears which
> can be mounted front OR back.
>
> The heavier / deeper 1RU devices do tend to sag alarmingly.
>
>
>
>  Is there a ?standard? distance between front and back rails that devices
> usually adhere to?
>
>
>
> If you're thinking of setting the front/back distance to accommodate a
> specific device, table 2 might be of some interest:
>
> https://i.dell.com/sites/doccontent/business/solutions/engineering-docs/
> en/Documents/rail-rack-matrix.pdf
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/6c59c0fd/attachment.html>

From merlyn at geeks.org  Thu Apr 27 21:05:58 2023
From: merlyn at geeks.org (Doug McIntyre)
Date: Thu, 27 Apr 2023 16:05:58 -0500
Subject: Standard DC rack rail distance, front to back question
In-Reply-To: <008601d9790f$62611460$27233d20$@gmail.com>
References: <008601d9790f$62611460$27233d20$@gmail.com>
Message-ID: <ZErjtnODfuUcR81y@geeks.org>

On Thu, Apr 27, 2023 at 09:51:36AM -0400, Chuck Church wrote:
> Hey all.  Question about standard 4 post racks.  We bought some that are
> adjustable.  Unfortunately, the posts are very flimsy, as these are some
> fancy cabinets with spacing on the sides for vertical patch panels, etc.  We
> found that 2 post mounting of most Cisco devices (namely Cat 9500 1RU
> switches) are sagging quite bad.

A perpetual problem with Cisco all the way back to their 2501 routers.
Sometimes they seem to come out with a better design, only to
revert back to the worst design the next generation of gear.

> Is there a 'standard' distance between front and back rails
> that devices usually adhere to?

I've got about 5 different "standard" depths in my datacenter. The
most common I have is 29.5" because that is the depth of a whole bunch of
fixed (ie. not adjustable) shelves I have are.

I've seen 32" and 36" in use for newer setups, as the eqiupment keeps getting deeper,
and deeper. Most equipment today will adjust for different depths quite
readily, and stick out past the back rails (so those 1050mm or 1200mm deep cabinets really
don't give you lots of empty space when the gear inside requires all that depth, then
power cables take up the rest).

So, ultimately the depth doesn't matter much as the rails will adjust to what you have
within reason now-a-days.

Gone are the days where equipment (ie. Sun, DEC) only fit in that one
rack that Sun paired with that specific Sun line. And when you bought different
Sun gear, you needed to buy a different rack to hold that.




From sean at donelan.com  Thu Apr 27 21:11:24 2023
From: sean at donelan.com (Sean Donelan)
Date: Thu, 27 Apr 2023 17:11:24 -0400 (EDT)
Subject: NWS service assessment on 2021 Hurricane Ida
Message-ID: <nr9n8721-8p71-5n9p-6399-9638p793877q@qbaryna.pbz>

Just published, buried in the after-action report on 2021 Hurricane 
Ida

Commodity internet access is now part of life-safety.


National Weather Service
Service Assessment
August-September 2021 Hurricane Ida
April 2023

https://www.weather.gov/media/publications/assessments/Hurricane_Ida_Service_Assessment.pdf
[...]
The Assessment Team found commodity internet access as important to the 
completion of the NWS mission as the AWIPS Wide Area Network (WAN) is to 
disseminating life-saving warnings. The lack of reliable, consistent 
internet access, to include sufficient bandwidth, would have led
to mission failure during Ida if not for extraordinary measures taken by 
staff at WFO New Orleans/Baton Rouge and the LMRFC. WFO New Orleans/Baton 
Rouge and the LMRFC sent people to telework from a forecaster?s home, 
where they had reliable commodity internet, to provide IDSS.

[...]

From warren at kumari.net  Thu Apr 27 22:34:47 2023
From: warren at kumari.net (Warren Kumari)
Date: Thu, 27 Apr 2023 15:34:47 -0700
Subject: BGP Books
In-Reply-To: <920124e6-2bdf-ac68-3801-8cceef20aaeb@nsrc.org>
References: <b967a1a10c5bf68b@orthanc.ca>
 <920124e6-2bdf-ac68-3801-8cceef20aaeb@nsrc.org>
Message-ID: <CAHw9_iJhZPysSpSiOPv0atVxU4g8UdWUdwoTXfLp95HQahvUaQ@mail.gmail.com>

On Tue, Apr 25, 2023 at 7:20 PM, Steven G. Huter <sghuter at nsrc.org> wrote:

> On 4/25/23 3:55 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
>
> It has been a couple of decades since I've done any BGP in anger, but it
> looks like I will be jumping into the deep end again, soon, and I
> desperately need to get up to speed again.
>
> There seem to be a lot of good guides out there from Cisco, Juniper, and
> the like, but naturally they are very product oriented. What I'm looking
> for is more like the Stevens networking bibles (i.e.
> "BGP Illustrated Vol I and II"). Something that covers more than just the
> raw protocols, and includes things like RPKI. (The world sure has changed
> since the last time I was doing this!)
>
> Any/all suggestions welcome.
>
> https://learn.nsrc.org/bgp
>


Yes, this. Much of it (all of it?) is presented by Philip Smith, and he's a
sufficiently entertaining speaker that it's worth watching even if you are
already a bgp "expert".

As for books ? I used to buy a copy of "BGP4: Inter-Domain Routing in the
Internet" by John W Stewart for all of my new hires ?
https://amzn.to/3VdqdfK . It's really short and sweet, and covers just the
stuff that you need to know. It is old at this point (1998!), but still
well worth the read.

W


> Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/f748d8d3/attachment.html>

From Brandon at huize.asia  Thu Apr 27 23:03:34 2023
From: Brandon at huize.asia (Brandon Zhi)
Date: Fri, 28 Apr 2023 07:03:34 +0800
Subject: Looking for sales from comcast
Message-ID: <CAAyZddGaRQyo66bSz-Vascs7LpEkL5EoKDeArswyw8AkQ=UkOg@mail.gmail.com>

Hello guys,

Our company is looking for a way to get IP Transit from comcast, can
someone give me the email of their sales team?

Also, does anyone know about whether AT-Tand T-Mobile provide IP Transit or
not?


Best wishes,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230428/005e931a/attachment.html>

From tj at pcguys.us  Fri Apr 28 00:10:25 2023
From: tj at pcguys.us (TJ Trout)
Date: Thu, 27 Apr 2023 17:10:25 -0700
Subject: Dormant space on blacklists, how can I resolve this?
In-Reply-To: <BL0PR14MB35548616BEB2EDADCB17F9C7826A9@BL0PR14MB3554.namprd14.prod.outlook.com>
References: <BL0PR14MB35548616BEB2EDADCB17F9C7826A9@BL0PR14MB3554.namprd14.prod.outlook.com>
Message-ID: <CAP5r2csAMtYpvUCU=aZf42phypzc9h+r7bSMVArfjTeKnT0xkg@mail.gmail.com>

https://thebrotherswisp.com/index.php/geo-and-vpn/

On Thu, Apr 27, 2023 at 6:51?AM Matthew Crocker <matthew at corp.crocker.com>
wrote:

>
> Hello,
>
>
>
> I run Crocker Communications (AS7849) and have ARIN allocations of
> 161.77.0.0/16 & 66.59.48.0/20.   The 66.58.48.0/20 space was used for our
> datacenter which shutdown a couple years ago.  The space has mostly been
> dormant for the past couple years.   I?m now starting to assign
> 66.59.[55-60].0/24 to a new group of residential FTTH customers.   The
> customers are getting access denied messages from Akamai based websites.
>
>
>
> What can I do to get Akamai to unblock the 66.59.48.0/20 space.
>
> Is there a website I can look to research the reputation of the subnets?
> They haven?t been used in years so I would expect them to be pretty clean.
>
>
>
> Thanks
>
>
>
> -Matt
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/c156f3c4/attachment.html>

From bjackson at napshome.net  Fri Apr 28 01:31:01 2023
From: bjackson at napshome.net (Brandon Jackson)
Date: Thu, 27 Apr 2023 21:31:01 -0400
Subject: [External] Spectrum networks IPv6 access issue
In-Reply-To: <D7CE615E-63F6-4AEF-8F06-41186DDE481C@boothlabs.me>
References: <20230425181310.GL1134230@bill-the-cat>
 <DS7PR01MB78084C824BEE8108A604EEF6FA659@DS7PR01MB7808.prod.exchangelabs.com>
 <e905a94d-eadc-b26c-b27b-0dda7d3eace4@jeffp.us>
 <D7CE615E-63F6-4AEF-8F06-41186DDE481C@boothlabs.me>
Message-ID: <CAAjaUeQ0L2_wfX+QZOiDmjA1-=7t0fmwFBQ-x+KvDobg_fxCiA@mail.gmail.com>

Just adding another data point of a failure from Spectrum IPv6 to that host
in question.

>From here in Milledgeville Georgia that host seems to be unreachable, can I
get to hurricane electrics network and seems to die with them.


Apologies for this output but I'm just using an app that I already had on
my phone. Didn't have a PC available..

#1
- RTT [ms]: 7.8
- Probe Send Time: 21:26:22
- IP Address: 2600:6c5a:47f:xxxx:9e53:22ff:fe95:d858
- TTL: 64
- AS Number: AS20115
- AS Name: CHARTER-20115
- Country Name: United States
- Country Code: US
- Time Zone: America/New_York
- Region: GA
- City: Milledgeville
- Latitude: 33.08
- Longitude: -83.24

#2
- Probe Send Time: 21:26:23

#3
- RTT [ms]: 16.5
- Probe Send Time: 21:26:26
- IP Address: 2001:506:100:548f::4
- Hostname: lag-22-10.dtr01mdvlga.netops.charter.com
- TTL: 62
- Country Name: United States
- Country Code: US
- Time Zone: America/New_York
- Region: GA
- City: Columbus
- Latitude: 32.47
- Longitude: -84.98

#4
- Probe Send Time: 21:26:26

#5
- RTT [ms]: 21.1
- Probe Send Time: 21:26:29
- IP Address: 2001:506:100:5507::4
- Hostname: lag-20.rcr01sghlgaao.netops.charter.com
- TTL: 59
- Country Name: United States
- Country Code: US
- Time Zone: America/New_York
- Region: GA
- City: Sugar Hill
- Latitude: 34.11
- Longitude: -84.00

#6
- Probe Send Time: 21:26:29

#7
- Probe Send Time: 21:26:32

#8
- Probe Send Time: 21:26:35

#9
- RTT [ms]: 35.3
- Probe Send Time: 21:26:38
- IP Address: 2001:470:0:42a::2
- Hostname: e0-35.core2.bna1.he.net
- TTL: 56
- AS Number: AS6939
- AS Name: HURRICANE
- Country Name: United States
- Country Code: US
- Time Zone: America/Chicago

#10
- Probe Send Time: 21:26:38

#11
- Probe Send Time: 21:26:41

#12
- Probe Send Time: 21:26:44

#13
- Probe Send Time: 21:26:47

#14
- Probe Send Time: 21:26:50

#15
- Probe Send Time: 21:26:53

#16
- Probe Send Time: 21:26:56

#17
- Probe Send Time: 21:27:00

#18
- Probe Send Time: 21:27:03


On Thu, Apr 27, 2023, 09:48 Francis via NANOG <nanog at nanog.org> wrote:

> I?m in the northeast and I can confirm on a Spectrum Enterprise connection
> I have issues tracerouting to 2604:1380:4641:c500::1.
>
> Gets to e0-33.core1.nyc7.he.net and then packets just disappear:
>
>  Host
>                     Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. _gateway
>                     0.0%   108    1.0   1.7   0.8  26.3   3.3
>  2. 2602:XXX:XXXX:X::X
>                     0.0%   108    4.4   6.6   4.2  27.9   4.0
>  3. 2602:XXX:XXXX:X::XXX
>                     0.0%   108    3.1   3.0   3.0   3.5   0.0
>  4. 2604:XXXX:X:X::X:XXXX
>                      0.0%   108    5.2   4.8   3.3  37.1   5.0
>  5. lag-15.srspny0101h.netops.charter.com
>                      0.0%   108    3.9  20.8   3.6 371.6  45.4
>  6. lag-32.albynyyf02r.netops.charter.com
>                     44.4%   108    4.9   4.9   4.8   5.5   0.1
>  7. lag-26.rcr01albynyyf.netops.charter.com
>                     80.4%   108    5.1   5.3   5.0   7.7   0.6
>  8. lag-416.nycmny837aw-bcr00.netops.charter.com
>                      57.9%   108   37.4  14.5  12.7  54.4   7.1
>  9. lag-1.pr2.nyc20.netops.charter.com
>                       0.0%   108   49.8  17.1  12.3  65.7  11.0
> 10. e0-33.core1.nyc7.he.net
>                      0.0%   108   12.9  13.2  12.8  19.8   0.7
> 11. (waiting for reply)
>
> Trying from another network and I was able to get through:
>
>  Host
>                     Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. ca.tor.ix.caramelfox.net
>                       0.0%    25   45.7  45.9  43.9  50.9   2.0
>  2. (waiting for reply)
>  3. (waiting for reply)
>  4. ve955.core2.stl1.he.net
>                     56.0%    25   62.0  63.9  62.0  67.6   2.0
>  5. (waiting for reply)
>  6. (waiting for reply)
>  7. (waiting for reply)
>  8. equinix-ix.dfw2.packet.net
>                       0.0%    25   81.2  86.0  77.8 103.3   8.4
>  9. (waiting for reply)
> 10. (waiting for reply)
> 11. dfw.source.kernel.org
>                      0.0%    24   77.6  78.1  77.0  82.5   1.1
>
>
> Maybe something in Hurricane Electric?s network potentially not getting
> these packets where they need to go?
>
>
> On Apr 26, 2023, at 5:27 PM, Jeff P <jeffp at jeffp.us> wrote:
>
> For what it's worth, on Spectrum Residential here in LAX and I can reach
> ip6echo.net and Google's public ipv6.google.com sites via residential
> service...  I have my own modems and routers, which may make the difference
> in my case... Spectrum does indicate that IPv6 my need to be enabled on
> their routers...
>
> https://www.spectrum.net/support/internet/ipv6-faq
>
> jeffp at jeffp-Linux:~$ ping -6 ip6echo.net
> PING ip6echo.net(ip6echo.net (2600:5c01:f876:10::53)) 56 data bytes
> 64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=1 ttl=51
> time=76.1 ms
> 64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=2 ttl=51
> time=78.4 ms
> 64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=3 ttl=51
> time=76.5 ms
>
> jeffp at jeffp-Linux:~$ ping -6 ipv6.google.com
> PING ipv6.google.com(lax31s06-in-x0e.1e100.net
> (2607:f8b0:4007:811::200e)) 56 data bytes
> 64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e):
> icmp_seq=1 ttl=116 time=12.6 ms
> 64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e):
> icmp_seq=2 ttl=116 time=14.4 ms
>
>
> I normally use the Google IPv6 site for such tests to avoid irritating
> private hosts, so a big thanks to Brandon for offering that alternative!
>
> Jeffp
> On 4/26/23 10:46, Saunders, Brandon wrote:
>
> If it is helpful, I am on Spectrum in Ohio and I can reach that address from my IPv6 test system.  This is on a commercial account with a provider assigned network.  My system is at ip6echo.net.  You are welcome to ping and traceroute to it if that is helpful to you.
>
> A friend CANNOT get to that address from a Spectrum residential account also in my area.
>
> Brandon
>
>
>
> -----Original Message-----
> From: NANOG <nanog-bounces+saundeb1=ohio.edu at nanog.org> <nanog-bounces+saundeb1=ohio.edu at nanog.org> On Behalf Of Tom Rini
> Sent: Tuesday, April 25, 2023 2:13 PM
> To: nanog at nanog.org
> Subject: [External] Spectrum networks IPv6 access issue
>
> Use caution with links and attachments.
>
> Hey all,
>
> I'm posting this here in hopes of getting the attention of someone that can get this issue resolved, or at least an internal ticket filed. I've tried the customer-facing tech support and not been able to get such a thing done.
>
> In short, from within Spectrum's US IPv6 network (verified in both North Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is unreachable and connections time out. This site is otherwise fine and globally accessible via IPv6, tested on both Qwest and T-Mobile hosted systems.  This is a regression from some time in early April this year.
>
> --
> Tom
>
> --
> JeffP
>
> "It is not for me to place expectations on someone and fail them for not meeting them. It's my goal to encourage others to raise their expectations of themselves, to educate them and help them gain the skills needed to meet their goals and encourage them to succeed in attaining them."
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230427/003dbcc4/attachment.html>

From peter.potvin at accuristechnologies.ca  Fri Apr 28 08:56:17 2023
From: peter.potvin at accuristechnologies.ca (Peter Potvin)
Date: Fri, 28 Apr 2023 04:56:17 -0400
Subject: Facebook IP Geolocation
Message-ID: <CAC0MiJpGDkE0BRzq0c0ERVw37pJhkqM1A9J2krr5e75HJ47sBg@mail.gmail.com>

Hey all,

Recently a customer reached out to us regarding an IP of ours in Canada
that Facebook is somehow placing within China, despite our geolocation in
other databases showing up correctly as they're ingesting our geofeeds as
we had requested.

Does anyone know which geolocation databases Facebook uses, and if possible
a contact at Meta we can reach out to so that this can be investigated
further?

Thanks in advance!

Regards,
Peter Potvin | Executive Director
------------------------------------------------------------------------------
*Accuris Technologies Ltd.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230428/4ea44d24/attachment.html>

From tj at pcguys.us  Fri Apr 28 10:21:16 2023
From: tj at pcguys.us (TJ Trout)
Date: Fri, 28 Apr 2023 03:21:16 -0700
Subject: Facebook IP Geolocation
In-Reply-To: <CAC0MiJpGDkE0BRzq0c0ERVw37pJhkqM1A9J2krr5e75HJ47sBg@mail.gmail.com>
References: <CAC0MiJpGDkE0BRzq0c0ERVw37pJhkqM1A9J2krr5e75HJ47sBg@mail.gmail.com>
Message-ID: <CAP5r2cuf1MYnLpAcGk6LSduTzeWNKzsQyQh-mydP7jmkWYx9gA@mail.gmail.com>

Have you checked these?

https://thebrotherswisp.com/index.php/geo-and-vpn/

On Fri, Apr 28, 2023, 1:58 AM Peter Potvin via NANOG <nanog at nanog.org>
wrote:

> Hey all,
>
> Recently a customer reached out to us regarding an IP of ours in Canada
> that Facebook is somehow placing within China, despite our geolocation in
> other databases showing up correctly as they're ingesting our geofeeds as
> we had requested.
>
> Does anyone know which geolocation databases Facebook uses, and if
> possible a contact at Meta we can reach out to so that this can be
> investigated further?
>
> Thanks in advance!
>
> Regards,
> Peter Potvin | Executive Director
>
> ------------------------------------------------------------------------------
> *Accuris Technologies Ltd.*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230428/0ed68f4e/attachment.html>

From jhellenthal at dataix.net  Fri Apr 28 14:06:11 2023
From: jhellenthal at dataix.net (J. Hellenthal)
Date: Fri, 28 Apr 2023 14:06:11 +0000
Subject: [External] Spectrum networks IPv6 access issue
In-Reply-To: <CAAjaUeQ0L2_wfX+QZOiDmjA1-=7t0fmwFBQ-x+KvDobg_fxCiA@mail.gmail.com>
References: <20230425181310.GL1134230@bill-the-cat>
 <DS7PR01MB78084C824BEE8108A604EEF6FA659@DS7PR01MB7808.prod.exchangelabs.com>
 <e905a94d-eadc-b26c-b27b-0dda7d3eace4@jeffp.us>
 <D7CE615E-63F6-4AEF-8F06-41186DDE481C@boothlabs.me>
 <CAAjaUeQ0L2_wfX+QZOiDmjA1-=7t0fmwFBQ-x+KvDobg_fxCiA@mail.gmail.com>
Message-ID: <ZEvS03H2x7t7SMBg@DataIX.net>

you have permission to traverse this host but not talk to it.

On Thu, Apr 27, 2023 at 09:31:01PM -0400, Brandon Jackson wrote:
>    Just adding another data point of a failure from Spectrum IPv6 to that
>    host in question.
>    From here in Milledgeville Georgia that host seems to be unreachable, can
>    I get to hurricane electrics network and seems to die with them.
>    Apologies for this output but I'm just using an app that I already had on
>    my phone. Didn't have a PC available..
>    #1
>    - RTT [ms]: 7.8
>    - Probe Send Time: 21:26:22
>    - IP Address: 2600:6c5a:47f:xxxx:9e53:22ff:fe95:d858
>    - TTL: 64
>    - AS Number: AS20115
>    - AS Name: CHARTER-20115
>    - Country Name: United States
>    - Country Code: US
>    - Time Zone: America/New_York
>    - Region: GA
>    - City: Milledgeville
>    - Latitude: 33.08
>    - Longitude: -83.24
>    #2
>    - Probe Send Time: 21:26:23
>    #3
>    - RTT [ms]: 16.5
>    - Probe Send Time: 21:26:26
>    - IP Address: 2001:506:100:548f::4
>    - Hostname: lag-22-10.dtr01mdvlga.netops.charter.com
>    - TTL: 62
>    - Country Name: United States
>    - Country Code: US
>    - Time Zone: America/New_York
>    - Region: GA
>    - City: Columbus
>    - Latitude: 32.47
>    - Longitude: -84.98
>    #4
>    - Probe Send Time: 21:26:26
>    #5
>    - RTT [ms]: 21.1
>    - Probe Send Time: 21:26:29
>    - IP Address: 2001:506:100:5507::4
>    - Hostname: lag-20.rcr01sghlgaao.netops.charter.com
>    - TTL: 59
>    - Country Name: United States
>    - Country Code: US
>    - Time Zone: America/New_York
>    - Region: GA
>    - City: Sugar Hill
>    - Latitude: 34.11
>    - Longitude: -84.00
>    #6
>    - Probe Send Time: 21:26:29
>    #7
>    - Probe Send Time: 21:26:32
>    #8
>    - Probe Send Time: 21:26:35
>    #9
>    - RTT [ms]: 35.3
>    - Probe Send Time: 21:26:38
>    - IP Address: 2001:470:0:42a::2
>    - Hostname: e0-35.core2.bna1.he.net
>    - TTL: 56
>    - AS Number: AS6939
>    - AS Name: HURRICANE
>    - Country Name: United States
>    - Country Code: US
>    - Time Zone: America/Chicago
>    #10
>    - Probe Send Time: 21:26:38
>    #11
>    - Probe Send Time: 21:26:41
>    #12
>    - Probe Send Time: 21:26:44
>    #13
>    - Probe Send Time: 21:26:47
>    #14
>    - Probe Send Time: 21:26:50
>    #15
>    - Probe Send Time: 21:26:53
>    #16
>    - Probe Send Time: 21:26:56
>    #17
>    - Probe Send Time: 21:27:00
>    #18
>    - Probe Send Time: 21:27:03
>    On Thu, Apr 27, 2023, 09:48 Francis via NANOG <nanog at nanog.org> wrote:
> 
>      I?m in the northeast and I can confirm on a Spectrum Enterprise
>      connection I have issues tracerouting to?2604:1380:4641:c500::1.
>      Gets to?e0-33.core1.nyc7.he.net and then packets just disappear:
>      ?Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? Loss% ? Snt ? Last ? Avg ?Best ?Wrst StDev
>      ?1. _gateway ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 0.0% ? 108 ? ?1.0 ? 1.7 ? 0.8 ?26.3 ? 3.3
>      ?2. 2602:XXX:XXXX:X::X ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 0.0% ? 108 ? ?4.4 ? 6.6 ? 4.2 ?27.9 ? 4.0
>      ?3. 2602:XXX:XXXX:X::XXX ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 0.0% ? 108 ? ?3.1 ? 3.0 ? 3.0 ? 3.5 ? 0.0
>      ?4. 2604:XXXX:X:X::X:XXXX ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? ?0.0% ? 108 ? ?5.2 ? 4.8 ? 3.3 ?37.1 ? 5.0
>      ?5. lag-15.srspny0101h.netops.charter.com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? ?0.0% ? 108 ? ?3.9 ?20.8 ? 3.6 371.6 ?45.4
>      ?6. lag-32.albynyyf02r.netops.charter.com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 44.4% ? 108 ? ?4.9 ? 4.9 ? 4.8 ? 5.5 ? 0.1
>      ?7. lag-26.rcr01albynyyf.netops.charter.com ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 80.4% ? 108 ? ?5.1 ? 5.3 ? 5.0 ? 7.7 ? 0.6
>      ?8. lag-416.nycmny837aw-bcr00.netops.charter.com ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ?57.9% ? 108 ? 37.4 ?14.5 ?12.7 ?54.4 ? 7.1
>      ?9. lag-1.pr2.nyc20.netops.charter.com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 0.0% ? 108 ? 49.8 ?17.1 ?12.3 ?65.7 ?11.0
>      10. e0-33.core1.nyc7.he.net ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? ?0.0% ? 108 ? 12.9 ?13.2 ?12.8 ?19.8 ? 0.7
>      11. (waiting for reply)
>      Trying from another network and I was able to get through:
>      ?Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? Loss% ? Snt ? Last ? Avg ?Best ?Wrst StDev
>      ?1. ca.tor.ix.caramelfox.net ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 0.0% ? ?25 ? 45.7 ?45.9 ?43.9 ?50.9 ? 2.0
>      ?2. (waiting for reply)
>      ?3. (waiting for reply)
>      ?4. ve955.core2.stl1.he.net ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 56.0% ? ?25 ? 62.0 ?63.9 ?62.0 ?67.6 ? 2.0
>      ?5. (waiting for reply)
>      ?6. (waiting for reply)
>      ?7. (waiting for reply)
>      ?8. equinix-ix.dfw2.packet.net ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? 0.0% ? ?25 ? 81.2 ?86.0 ?77.8 103.3 ? 8.4
>      ?9. (waiting for reply)
>      10. (waiting for reply)
>      11. dfw.source.kernel.org ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>      ? ? ? ? ? ? ? ? ? ? ? ?0.0% ? ?24 ? 77.6 ?78.1 ?77.0 ?82.5 ? 1.1
>      Maybe something in Hurricane Electric?s network potentially not getting
>      these packets where they need to go?
> 
>        On Apr 26, 2023, at 5:27 PM, Jeff P <jeffp at jeffp.us> wrote:
> 
>        For what it's worth, on Spectrum Residential here in LAX and I can
>        reach ip6echo.net and Google's public ipv6.google.com sites via
>        residential service...? I have my own modems and routers, which may
>        make the difference in my case... Spectrum does indicate that IPv6 my
>        need to be enabled on their routers...
> 
>        https://www.spectrum.net/support/internet/ipv6-faq
> 
>        jeffp at jeffp-Linux:~$ ping -6 ip6echo.net
>        PING ip6echo.net(ip6echo.net (2600:5c01:f876:10::53)) 56 data bytes
>        64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=1 ttl=51
>        time=76.1 ms
>        64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=2 ttl=51
>        time=78.4 ms
>        64 bytes from ip6echo.net (2600:5c01:f876:10::53): icmp_seq=3 ttl=51
>        time=76.5 ms
> 
>        jeffp at jeffp-Linux:~$ ping -6 ipv6.google.com
>        PING ipv6.google.com(lax31s06-in-x0e.1e100.net
>        (2607:f8b0:4007:811::200e)) 56 data bytes
>        64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e):
>        icmp_seq=1 ttl=116 time=12.6 ms
>        64 bytes from lax31s06-in-x0e.1e100.net (2607:f8b0:4007:811::200e):
>        icmp_seq=2 ttl=116 time=14.4 ms
> 
>        I normally use the Google IPv6 site for such tests to avoid irritating
>        private hosts, so a big thanks to Brandon for offering that
>        alternative!
> 
>        Jeffp
> 
>        On 4/26/23 10:46, Saunders, Brandon wrote:
> 
>  If it is helpful, I am on Spectrum in Ohio and I can reach that address from my IPv6 test system.  This is on a commercial account with a provider assigned network.  My system is at ip6echo.net.  You are welcome to ping and traceroute to it if that is helpful to you. 
> 
>  A friend CANNOT get to that address from a Spectrum residential account also in my area.
> 
>  Brandon
> 
> 
> 
>  -----Original Message-----
>  From: NANOG <nanog-bounces+saundeb1=ohio.edu at nanog.org> On Behalf Of Tom Rini
>  Sent: Tuesday, April 25, 2023 2:13 PM
>  To: nanog at nanog.org
>  Subject: [External] Spectrum networks IPv6 access issue
> 
>  Use caution with links and attachments.
> 
>  Hey all,
> 
>  I'm posting this here in hopes of getting the attention of someone that can get this issue resolved, or at least an internal ticket filed. I've tried the customer-facing tech support and not been able to get such a thing done.
> 
>  In short, from within Spectrum's US IPv6 network (verified in both North Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is unreachable and connections time out. This site is otherwise fine and globally accessible via IPv6, tested on both Qwest and T-Mobile hosted systems.  This is a regression from some time in early April this year.
> 
>  --
>  Tom
> 
>  --
>  JeffP
> 
>  "It is not for me to place expectations on someone and fail them for not meeting them. It's my goal to encourage others to raise their expectations of themselves, to educate them and help them gain the skills needed to meet their goals and encourage them to succeed in attaining them."

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 533 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230428/f84df891/attachment.sig>

From sthomas at lart.net  Fri Apr 28 15:35:36 2023
From: sthomas at lart.net (Sam Thomas)
Date: Fri, 28 Apr 2023 10:35:36 -0500
Subject: Spectrum networks IPv6 access issue
In-Reply-To: <20230425181310.GL1134230@bill-the-cat>
References: <20230425181310.GL1134230@bill-the-cat>
Message-ID: <CAJ_saMGmHJXfENV2bzrvC43yDHzW4xBH-FbMjD7YQhtSv7gx1Q@mail.gmail.com>

Actual data from a Spectrum residential customer in DFW.

First, IPv4:

<ns:~> trace dfw.source.kernel.org
traceroute to dfw.source.kernel.org (139.178.84.217), 64 hops max, 40
byte packets
 1  my.router  0.389 ms  0.350 ms  0.292 ms
 2  142-254-130-077.inf.spectrum.com (142.254.130.77)  8.423 ms  8.408
ms  8.080 ms
 3  lag-63.artrtx2801h.netops.charter.com (24.28.88.17)  27.167 ms
25.065 ms  21.977 ms
 4  lag-22.artntxaf01r.netops.charter.com (24.175.49.233)  10.718 ms
10.083 ms  15.886 ms
 5  lag-23.mcr11crtntxjt.netops.charter.com (24.175.36.224)  13.386 ms
 11.560 ms  11.297 ms
 6  lag-21.rcr01dllatx37.netops.charter.com (24.175.49.0)  11.339 ms
    lag-28.rcr01dllatx37.netops.charter.com (24.175.33.246)  11.904 ms
 128.186 ms
 7  lag-414.dllstx976iw-bcr00.netops.charter.com (66.109.6.52)  12.603 ms
    lag-14.dllstx976iw-bcr00.netops.charter.com (66.109.6.88)  12.172 ms
    lag-414.dllstx976iw-bcr00.netops.charter.com (66.109.6.52)  12.299 ms
 8  lag-302.pr3.dfw10.netops.charter.com (209.18.43.77)  21.570 ms
    lag-0.pr3.dfw10.netops.charter.com (66.109.5.121)  11.763 ms
    lag-302.pr3.dfw10.netops.charter.com (209.18.43.77)  12.182 ms
 9  dls-b23-link.ip.twelve99.net (62.115.156.208)  11.515 ms *  11.706 ms
10  packethost-ic-369414.ip.twelve99-cust.net (213.248.72.3)  11.870
ms  30.246 ms  18.199 ms
11  * * *
12  * * *
13  dfw.source.kernel.org (139.178.84.217)  12.021 ms  12.076 ms  11.922 ms

ping dfw.source.kernel.org
PING dfw.source.kernel.org (139.178.84.217): 56 data bytes
64 bytes from 139.178.84.217: icmp_seq=0 ttl=50 time=11.590 ms
64 bytes from 139.178.84.217: icmp_seq=1 ttl=50 time=11.785 ms

IPv6:

<ns:~> trace6 dfw.source.kernel.org
traceroute6 to dfw.source.kernel.org (2604:1380:4641:c500::1) from
2603:8080:REDACTED, 64 hops max, 20 byte packets
 1  2603-8080-REDACTED.res6.spectrum.com  0.404 ms  0.340 ms  0.322 ms
 2  2603-90c5-0003-000e-0000-0000-0000-0001.inf6.spectrum.com  10.308
ms  7.901 ms  9.902 ms
 3  lag-63.artrtx2801h.netops.charter.com  17.008 ms  10.523 ms  11.077 ms
 4  lag-22.artntxaf01r.netops.charter.com  14.638 ms * *
 5  lag-23.mcr11crtntxjt.netops.charter.com  11.090 ms  11.612 ms  12.234 ms
 6  * * *
 7  lag-414.dllstx976iw-bcr00.netops.charter.com  12.572 ms *
    lag-24.dllstx976iw-bcr00.netops.charter.com  12.160 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  *^C

ping6 dfw.source.kernel.org
PING6(56=40+8+8 bytes) 2603:8080:REDACTED --> 2604:1380:4641:c500::1
^C
--- dfw.source.kernel.org ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

I have a Linode VM in Dallas that I also can't get to via IPv6.
Traffic appears to take the same path for IPv4.

On Wed, Apr 26, 2023 at 10:50?AM Tom Rini <trini at konsulko.com> wrote:
>
> Hey all,
>
> I'm posting this here in hopes of getting the attention of someone that
> can get this issue resolved, or at least an internal ticket filed. I've
> tried the customer-facing tech support and not been able to get such a
> thing done.
>
> In short, from within Spectrum's US IPv6 network (verified in both North
> Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is
> unreachable and connections time out. This site is otherwise fine and
> globally accessible via IPv6, tested on both Qwest and T-Mobile hosted
> systems.  This is a regression from some time in early April this year.
>
> --
> Tom

From cscora at apnic.net  Fri Apr 28 18:03:41 2023
From: cscora at apnic.net (Routing Table Analysis Role Account)
Date: Sat, 29 Apr 2023 04:03:41 +1000 (AEST)
Subject: Weekly Global IPv4 Routing Table Report
Message-ID: <20230428180341.3FA3DC0C12@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the 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 bgp-stats at lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

IPv4 Routing Table Report   04:00 +10GMT Sat 29 Apr, 2023

  BGP Table (Global) as seen in Japan.

Report Website:     https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              920274
    Prefixes after maximum aggregation (per Origin AS):          349049
    Deaggregation factor:                                          2.64
    Unique aggregates announced (without unneeded subnets):      449049
Total ASes present in the Internet Routing Table:                 74365
    Prefixes per ASN:                                             12.38
Origin-only ASes present in the Internet Routing Table:           63787
Origin ASes announcing only one prefix:                           26221
Transit ASes present in the Internet Routing Table:               10578
Transit-only ASes present in the Internet Routing Table:            435
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      55
    Max AS path prepend of ASN (265020)                              50
Prefixes from unregistered ASNs in the Routing Table:              1078
    Number of instances of unregistered ASNs:                      1078
Number of 32-bit ASNs allocated by the RIRs:                      41758
Number of 32-bit ASNs visible in the Routing Table:               34510
Prefixes from 32-bit ASNs in the Routing Table:                  170749
Number of bogon 32-bit ASNs visible in the Routing Table:            13
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            635
Number of addresses announced to Internet:                   3060323968
    Equivalent to 182 /8s, 104 /16s and 214 /24s
    Percentage of available address space announced:               82.7
    Percentage of allocated address space announced:               82.7
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               99.6
Total number of prefixes smaller than registry allocations:      307168

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   243681
    Total APNIC prefixes after maximum aggregation:               69357
    APNIC Deaggregation factor:                                    3.51
Prefixes being announced from the APNIC address blocks:          237917
    Unique aggregates announced from the APNIC address blocks:    97908
APNIC Region origin ASes present in the Internet Routing Table:   13396
    APNIC Prefixes per ASN:                                       17.76
APNIC Region origin ASes announcing only one prefix:               3929
APNIC Region transit ASes present in the Internet Routing Table:   1802
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8699
Number of APNIC addresses announced to Internet:              773438208
    Equivalent to 46 /8s, 25 /16s and 187 /24s
APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
                       203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
                       222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    269219
    Total ARIN prefixes after maximum aggregation:               122319
    ARIN Deaggregation factor:                                     2.20
Prefixes being announced from the ARIN address blocks:           271854
    Unique aggregates announced from the ARIN address blocks:    131001
ARIN Region origin ASes present in the Internet Routing Table:    19089
    ARIN Prefixes per ASN:                                        14.24
ARIN Region origin ASes announcing only one prefix:                6963
ARIN Region transit ASes present in the Internet Routing Table:    1964
Average ARIN Region AS path length visible:                         3.7
    Max ARIN Region AS path length visible:                          24
Number of ARIN region 32-bit ASNs visible in the Routing Table:    4790
Number of ARIN addresses announced to Internet:              1283916288
    Equivalent to 76 /8s, 135 /16s and 2 /24s
ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 62464-63487, 64198-64296, 393216-401308
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  47/8,  48/8,  50/8,  52/8,  53/8,
                        54/8,  55/8,  56/8,  57/8,  63/8,  64/8,  65/8,
                        66/8,  67/8,  68/8,  69/8,  70/8,  71/8,  72/8,
                        73/8,  74/8,  75/8,  76/8,  96/8,  97/8,  98/8,
                        99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8,
                       130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8,
                       138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8,
                       147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8,
                       158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8,
                       166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8,
                       174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8,
                       206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8,
                      

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                    259353
    Total RIPE prefixes after maximum aggregation:               122220
    RIPE Deaggregation factor:                                     2.12
Prefixes being announced from the RIPE address blocks:           255356
    Unique aggregates announced from the RIPE address blocks:    158069
RIPE Region origin ASes present in the Internet Routing Table:    28321
    RIPE Prefixes per ASN:                                         9.02
RIPE Region origin ASes announcing only one prefix:               12059
RIPE Region transit ASes present in the Internet Routing Table:    3972
Average RIPE Region AS path length visible:                         4.2
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:   11156
Number of RIPE addresses announced to Internet:               717996416
    Equivalent to 42 /8s, 203 /16s and 193 /24s
RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       59392-61439, 61952-62463, 64396-64495
                       196608-213403
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                  117852
    Total LACNIC prefixes after maximum aggregation:              28563
    LACNIC Deaggregation factor:                                   4.13
Prefixes being announced from the LACNIC address blocks:         117112
    Unique aggregates announced from the LACNIC address blocks:   49293
LACNIC Region origin ASes present in the Internet Routing Table:  10991
    LACNIC Prefixes per ASN:                                      10.66
LACNIC Region origin ASes announcing only one prefix:              2654
LACNIC Region transit ASes present in the Internet Routing Table:  2306
Average LACNIC Region AS path length visible:                       5.0
    Max LACNIC Region AS path length visible:                        55
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  8779
Number of LACNIC addresses announced to Internet:             176720384
    Equivalent to 10 /8s, 136 /16s and 138 /24s
LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 64099-64197, 262144-273820 + ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  29091
    Total AfriNIC prefixes after maximum aggregation:              5811
    AfriNIC Deaggregation factor:                                  5.01
Prefixes being announced from the AfriNIC address blocks:         37400
    Unique aggregates announced from the AfriNIC address blocks:  12252
AfriNIC Region origin ASes present in the Internet Routing Table:  1739
    AfriNIC Prefixes per ASN:                                     21.51
AfriNIC Region origin ASes announcing only one prefix:              616
AfriNIC Region transit ASes present in the Internet Routing Table:  333
Average AfriNIC Region AS path length visible:                      4.9
    Max AfriNIC Region AS path length visible:                       30
Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1086
Number of AfriNIC addresses announced to Internet:            107835136
    Equivalent to 6 /8s, 109 /16s and 111 /24s
AfriNIC AS Blocks      36864-37887, 327680-329727 & ERX transfers
AfriNIC Address Blocks  41/8,  45/8, 102/8, 105/8, 154/8, 196/8, 197/8,
                      

APNIC Region per AS prefix count summary
----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  9808        9483       8706      40  CHINAMOBILE-CN China Mobile Communicati
  7545        5730        787     693  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4863       4192      75  ERX-CERNET-BKB China Education and Rese
 45899        4054       1877      47  VNPT-AS-VN VNPT Corp, VN
  7713        3547       1043      65  TELKOMNET-AS-AP PT Telekomunikasi Indon
  7552        3227       1331      21  VIETEL-AS-AP Viettel Group, VN
  9498        2942        489     234  BBIL-AP BHARTI Airtel Ltd., IN
  4766        2537      11251     591  KIXS-AS-KR Korea Telecom, KR
 24560        2386        837     442  AIRTELBROADBAND-AS-AP Bharti Airtel Ltd
 45090        2184       1438      79  TENCENT-NET-AP Shenzhen Tencent Compute

Complete listing at https://thyme.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 16509        8232      10772    2936  AMAZON-02, US
 11492        4545        301     593  CABLEONE, US
  7155        3975        281      51  VIASAT-SP-BACKBONE, US
 22773        3588       3057     284  ASN-CXA-ALL-CCI-22773-RDC, US
  6327        3523       1320      64  SHAW, CA
 16625        3171       1584    2361  AKAMAI-AS, US
   749        3071      53111    2323  DNIC-AS-00749, US
396982        2635       3590     366  GOOGLE-CLOUD-PLATFORM, US
  7018        2516      24151    1575  ATT-INTERNET4, US
 30036        2501        361     449  MEDIACOM-ENTERPRISE-BUSINESS, US

Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 12479        7270       1706     140  UNI2-AS, ES
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 20940        4080       3399     164  AKAMAI-ASN1, NL
  8551        3889        370      37  BEZEQ-INTERNATIONAL-AS Bezeqint Interne
 12389        2951       2292     909  ROSTELECOM-AS, RU
  9009        2668        249    1400  M247, RO
 34984        2276        359     613  TELLCOM-AS, TR
  6849        2018        307      18  UKRTELNET, UA
 58224        1852        950     544  TCI, IR
 13188        1607        100      18  TRIOLAN, UA

Complete listing at https://thyme.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11251       3343     591  Uninet S.A. de C.V., MX
 10620        3479        505     906  Telmex Colombia S.A., CO
 13999        2334        358     617  Mega Cable, S.A. de C.V., MX
 11830        2263        369      64  Instituto Costarricense de Electricidad
 28573        1333       2324     240  Claro NXT Telecomunicacoes Ltda, BR
  6503        1299        339     514  Axtel, S.A.B. de C.V., MX
  3816        1293        760     170  COLOMBIA TELECOMUNICACIONES S.A. ESP, C
  6147        1132        370      22  Telefonica del Peru S.A.A., PE
 11664        1099        180     444  Techtel LMDS Comunicaciones Interactiva
 26615        1035       2498      45  TIM SA, BR

Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
 24863        1585        393      19  LINKdotNET-AS, EG
 24835        1553        533      30  RAYA-AS, EG
 36992        1338       1518     275  ETISALAT-MISR, EG
 36903        1242        550      99  MT-MPLS, MA
 29571        1024         67      46  ORANGE-COTE-IVOIRE, CI
 36935         875        520      42  Vodafone-, EG
  6713         550       1861      34  IAM-AS, MA
 15399         529         54      48  WANANCHI-, KE
 37342         491         32       1  MOVITEL, MZ
 24757         489         73       5  EthioNet-AS, ET

Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

   ASN  No of nets  /20 equiv  MaxAgg  Description
  8151       11251       3343     591  Uninet S.A. de C.V., MX
  9808        9483       8706      40  CHINAMOBILE-CN China Mobile Communicati
 16509        8232      10772    2936  AMAZON-02, US
 12479        7270       1706     140  UNI2-AS, ES
  7545        5730        787     693  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4863       4192      75  ERX-CERNET-BKB China Education and Rese
 39891        4833        286      59  ALJAWWALSTC-AS, SA
 11492        4545        301     593  CABLEONE, US
 20940        4080       3399     164  AKAMAI-ASN1, NL
 45899        4054       1877      47  VNPT-AS-VN VNPT Corp, VN

Complete listing at https://thyme.apnic.net/current/data-ASnet

Global Per AS Maximum Aggregation summary
-----------------------------------------

   ASN  No of nets  Net Savings  Description
  9808        9483         9443  CHINAMOBILE-CN China Mobile Communications Grou
 12479        7270         7130  UNI2-AS, ES
 16509        8232         5296  AMAZON-02, US
  7545        5730         5037  TPG-INTERNET-AP TPG Telecom Limited, AU
  4538        4863         4788  ERX-CERNET-BKB China Education and Research Net
 39891        4833         4774  ALJAWWALSTC-AS, SA
 45899        4054         4007  VNPT-AS-VN VNPT Corp, VN
 11492        4545         3952  CABLEONE, US
  7155        3975         3924  VIASAT-SP-BACKBONE, US
 20940        4080         3916  AKAMAI-ASN1, NL

Complete listing at https://thyme.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

    Bad AS  Designation  Net Originated      Transit AS  Transit AS Name
      3507  UNALLOCATED  5.105.166.0/24          213035  AS-SERVERION Serverion B.V.,
     33492  UNALLOCATED  8.6.184.0/23             33650  COMCAST-33650, US
     33123  UNALLOCATED  8.10.69.0/24             11168  SCC, US
     12169  UNALLOCATED  8.15.207.0/24            32787  PROLEXIC-TECHNOLOGIES-DDOS-M
     53775  UNALLOCATED  8.20.88.0/24              7029  WINDSTREAM, US
     62828  UNALLOCATED  8.21.130.0/24             3356  LEVEL3, US
    393266  UNALLOCATED  8.23.52.0/24             46887  LIGHTOWER, US
    396894  UNALLOCATED  8.28.201.0/24            46887  LIGHTOWER, US
    394936  UNALLOCATED  8.33.224.0/24            22442  HOU-PHONOSCOPE, US
     54338  UNALLOCATED  8.33.241.0/24             6461  ZAYO-6461, US

Complete listing at https://thyme.apnic.net/current/data-badAS

Prefixes from the Special Purpose Address Registry (Global)
-----------------------------------------------------------

Prefix                Origin AS  Description
192.88.99.0/24             6939  HURRICANE, US

Complete listing at https://thyme.apnic.net/current/data-spar

Advertised Unallocated Addresses
--------------------------------

Unassigned Network     ASN Information  AS Name
23.131.185.0/24      Origin:       174  COGENT-174, US
23.131.185.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.186.0/24      Origin:       174  COGENT-174, US
23.131.186.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.187.0/24      Origin:       174  COGENT-174, US
23.131.187.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.131.188.0/24      Origin:       174  COGENT-174, US
23.131.188.0/24     Transit:      2516  KDDI KDDI CORPORATION, JP
23.139.232.0/24      Origin:    211619  MAXKO, HR
23.139.232.0/24     Transit:     42864  GIGANET-HU GigaNet Internet Service Prov

Complete listing at https://thyme.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:14      /10:39      /11:103     /12:298     
/13:578     /14:1195    /15:2046    /16:13453   /17:8234    /18:14280   
/19:25215   /20:44283   /21:51252   /22:109692  /23:97666   /24:551168  
/25:742     /26:0       /27:0       /28:0       /29:0       /30:0       
/31:0       /32:0       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

   ASN  No of nets  Total ann.  Description
 12479        6330        7270  UNI2-AS, ES
  8151        5196       11251  Uninet S.A. de C.V., MX
 39891        3632        4833  ALJAWWALSTC-AS, SA
 11492        3454        4545  CABLEONE, US
  8551        3361        3889  BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo
  6327        3332        3523  SHAW, CA
  7155        3042        3975  VIASAT-SP-BACKBONE, US
 22773        2652        3588  ASN-CXA-ALL-CCI-22773-RDC, US
 30036        2158        2501  MEDIACOM-ENTERPRISE-BUSINESS, US
 10620        2034        3479  Telmex Colombia S.A., CO

Complete listing at https://thyme.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1821      2:1290      3:175       4:5         5:4516      6:128    
   7:6         8:1548      9:1        11:172      12:1535     13:380    
  14:2340     15:299      16:182      17:371      18:417      20:256    
  21:4        22:188      23:6246     24:2594     25:6        27:2459   
  29:19       31:2493     32:81       34:12       35:109      36:1939   
  37:4658     38:4467     39:822      40:151      41:3932     42:1231   
  43:2345     44:307      45:16532    46:4291     47:363      49:1758   
  50:1844     51:573      52:1592     54:390      55:858      56:8      
  57:112      58:1780     59:1152     60:990      61:2453     62:2663   
  63:1925     64:5669     65:2331     66:4995     67:3007     68:1352   
  69:4130     70:1235     71:671      72:2983     74:2612     75:1447   
  76:615      77:2441     78:1815     79:3173     80:2109     81:1762   
  82:1488     83:1278     84:1531     85:2985     86:764      87:2011   
  88:1169     89:3668     90:613      91:7740     92:2064     93:2627   
  94:3604     95:3999     96:1321     97:335      98:1153     99:746    
 100:73      101:1077    102:2629    103:31289   104:4628    105:488    
 106:948     107:2524    108:1030    109:4421    110:2090    111:3137   
 112:2036    113:1645    114:1651    115:2016    116:1923    117:2534   
 118:2381    119:2017    120:1794    121:1112    122:2593    123:2216   
 124:1614    125:2500    128:1377    129:1064    130:1020    131:1996   
 132:814     133:422     134:1904    135:303     136:878     137:944    
 138:2556    139:1574    140:1250    141:1464    142:1443    143:1501   
 144:1164    145:348     146:1942    147:1574    148:2353    149:2208   
 150:876     151:1158    152:1817    153:490     154:4443    155:1436   
 156:1784    157:1305    158:1064    159:2306    160:2544    161:1531   
 162:3516    163:1522    164:1617    165:1715    166:1040    167:1725   
 168:3857    169:943     170:4585    171:874     172:3547    173:2937   
 174:1072    175:1177    176:3693    177:4599    178:3592    179:2152   
 180:2573    181:3434    182:3380    183:1975    184:2371    185:20183  
 186:4747    187:3967    188:4109    189:3562    190:9155    191:1438   
 192:10947   193:8876    194:7336    195:5161    196:3063    197:2356   
 198:5944    199:6103    200:8039    201:5875    202:10671   203:10238  
 204:4587    205:3672    206:4354    207:3458    208:4072    209:4860   
 210:4427    211:2498    212:4137    213:3586    214:1090    215:59     
 216:6636    217:2682    218:1294    219:577     220:2015    221:972    
 222:890     223:2185   

End of report

From jefftant.ietf at gmail.com  Fri Apr 28 20:10:13 2023
From: jefftant.ietf at gmail.com (Jeff Tantsura)
Date: Fri, 28 Apr 2023 13:10:13 -0700
Subject: BGP Books
In-Reply-To: <CAHw9_iJhZPysSpSiOPv0atVxU4g8UdWUdwoTXfLp95HQahvUaQ@mail.gmail.com>
References: <CAHw9_iJhZPysSpSiOPv0atVxU4g8UdWUdwoTXfLp95HQahvUaQ@mail.gmail.com>
Message-ID: <3EFFD1AA-E9E7-436B-9E5C-72D4F99EC74E@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230428/0a1840b2/attachment.html>

From peter.potvin at accuristechnologies.ca  Sat Apr 29 00:19:15 2023
From: peter.potvin at accuristechnologies.ca (Peter Potvin)
Date: Fri, 28 Apr 2023 20:19:15 -0400
Subject: Facebook IP Geolocation
In-Reply-To: <CAP5r2cuf1MYnLpAcGk6LSduTzeWNKzsQyQh-mydP7jmkWYx9gA@mail.gmail.com>
References: <CAC0MiJpGDkE0BRzq0c0ERVw37pJhkqM1A9J2krr5e75HJ47sBg@mail.gmail.com>
 <CAP5r2cuf1MYnLpAcGk6LSduTzeWNKzsQyQh-mydP7jmkWYx9gA@mail.gmail.com>
Message-ID: <CAC0MiJoxtpJSg=0HXPcUUnAUE8bn0NhT8yv4S0A6trmfPwVjSg@mail.gmail.com>

Hey there TJ,

I have, and unfortunately the databases listed there are reporting the
location correctly. It seems to be an issue specifically with Facebook from
what I'm able to diagnose. I've been reached out to by someone from their
network team regarding this so will update this thread when/if it gets
resolved.

Regards,
Peter Potvin | Executive Director
------------------------------------------------------------------------------
*Accuris Technologies Ltd.*
56A Mill St E, Unit #470, Acton, ON L7J 1H3 Canada
Email: peter.potvin at accuristechnologies.ca
Office: +1 (877) 352-6105
Network Operations Center: +1 (877) 321-1662


On Fri, Apr 28, 2023 at 6:21?AM TJ Trout <tj at pcguys.us> wrote:

> Have you checked these?
>
> https://thebrotherswisp.com/index.php/geo-and-vpn/
>
> On Fri, Apr 28, 2023, 1:58 AM Peter Potvin via NANOG <nanog at nanog.org>
> wrote:
>
>> Hey all,
>>
>> Recently a customer reached out to us regarding an IP of ours in Canada
>> that Facebook is somehow placing within China, despite our geolocation in
>> other databases showing up correctly as they're ingesting our geofeeds as
>> we had requested.
>>
>> Does anyone know which geolocation databases Facebook uses, and if
>> possible a contact at Meta we can reach out to so that this can be
>> investigated further?
>>
>> Thanks in advance!
>>
>> Regards,
>> Peter Potvin | Executive Director
>>
>> ------------------------------------------------------------------------------
>> *Accuris Technologies Ltd.*
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230428/e20bd29e/attachment.html>

From jason at leschnik.me  Sat Apr 29 07:34:58 2023
From: jason at leschnik.me (Jason Leschnik)
Date: Sat, 29 Apr 2023 17:34:58 +1000
Subject: BGP Books
In-Reply-To: <3EFFD1AA-E9E7-436B-9E5C-72D4F99EC74E@gmail.com>
References: <CAHw9_iJhZPysSpSiOPv0atVxU4g8UdWUdwoTXfLp95HQahvUaQ@mail.gmail.com>
 <3EFFD1AA-E9E7-436B-9E5C-72D4F99EC74E@gmail.com>
Message-ID: <CADFTyzQcP0nMsqMVTo5W4qp6AotdhQ839ndtbhHJ+-vF=aR8Tg@mail.gmail.com>

> ?between 0x2 nerds?

Get in my Podcatcher! Where is the RSS feed!?

On Sat, 29 Apr 2023 at 06:12, Jeff Tantsura <jefftant.ietf at gmail.com> wrote:

> If you are looking for BGP in DC (either unicast and/or VPN) we (Jeff
> Doyle and I) have published a significant number of podcasts on ?between
> 0x2 nerds?(from basic BGP to EVPN to BGP security to HW) -
> https://youtube.com/playlist?list=PLMYH1xDLIabuZCr1Yeoo39enogPA2yJB7
>
> Cheers,
> Jeff
>
> On Apr 27, 2023, at 15:37, Warren Kumari <warren at kumari.net> wrote:
>
> ?
>
>
>
>
> On Tue, Apr 25, 2023 at 7:20 PM, Steven G. Huter <sghuter at nsrc.org> wrote:
>
>> On 4/25/23 3:55 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
>>
>> It has been a couple of decades since I've done any BGP in anger, but it
>> looks like I will be jumping into the deep end again, soon, and I
>> desperately need to get up to speed again.
>>
>> There seem to be a lot of good guides out there from Cisco, Juniper, and
>> the like, but naturally they are very product oriented. What I'm looking
>> for is more like the Stevens networking bibles (i.e.
>> "BGP Illustrated Vol I and II"). Something that covers more than just the
>> raw protocols, and includes things like RPKI. (The world sure has changed
>> since the last time I was doing this!)
>>
>> Any/all suggestions welcome.
>>
>> https://learn.nsrc.org/bgp
>>
>
>
> Yes, this. Much of it (all of it?) is presented by Philip Smith, and he's
> a sufficiently entertaining speaker that it's worth watching even if you
> are already a bgp "expert".
>
> As for books ? I used to buy a copy of "BGP4: Inter-Domain Routing in the
> Internet" by John W Stewart for all of my new hires ?
> https://amzn.to/3VdqdfK . It's really short and sweet, and covers
> just the stuff that you need to know. It is old at this point (1998!), but
> still well worth the read.
>
> W
>
>
>> Steve
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230429/5c88081b/attachment.html>