Re: Any info on AT Wireless Outage?

[Javier J]

Where did you see this? Erik Prince was on the PBD podcast saying he has a
70% chance in his head it was China. I tend to learn towards human error
from my experience in the IT biz.

- J

On Wed, Feb 28, 2024 at 10:58 AM  wrote:

> I read it as “someone pushed an ACL that wasn’t properly reviewed and it
> really screwed things up."
>
> On Feb 27, 2024, at 21:41, Mark Seiden  wrote:
>
> aside from the official pablum that was released about an “incorrect
> process used”
> (which says exactly nothing) does anyone actually know anything accurate
> and
> more specific about the root cause?
>
> (and why it took 11 hours to recover?)
>
> On Feb 22, 2024, at 11:15 AM, John Councilman 
> wrote:
>
> From what I've read, they lost their database of SIM cards.  I could be
> wrong of course.
>
> On Thu, Feb 22, 2024 at 2:02 PM Dorn Hetzel  wrote:
>
>> As widespread as it seemed to be, it feels like it would be quite a trick
>> if it were a single piece of hardware.  Firmware load that ended badly, I
>> wonder?
>>
>>
>> On Thu, Feb 22, 2024 at 1:51 PM Leato, Gary via NANOG 
>> wrote:
>>
>>> Do you have the ability to expand on this at all? Do you mean a hardware
>>> failure of some kind IE router, optitcs, etc?
>>>
>>>
>>>
>>> *From:* NANOG  *On
>>> Behalf Of *R. Leigh Hennig
>>> *Sent:* Thursday, February 22, 2024 8:17 AM
>>> *To:* Robert DeVita 
>>> *Cc:* nanog@nanog.org
>>> *Subject:* Re: Any info on AT Wireless Outage?
>>>
>>>
>>>
>>> Word around the campfire is that it’s a Cisco issue.
>>>
>>>
>>>
>>> On Feb 22, 2024, at 8:03 AM, Robert DeVita 
>>> wrote:
>>>
>>>
>>>
>>> Reports have it starting at 4:30 a.m.. SOS on all phones..
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Robert DeVita**​**​**​**​*
>>>
>>> *CEO and Founder*
>>>
>>> t: (469) 581-2160 <(469)%20581-2160>
>>>
>>>  |
>>>
>>> m: (469) 441-8864 <(469)%20441-8864>
>>>
>>> e: radev...@mejeticks.com
>>>
>>>  |
>>>
>>> w: mejeticks.com <https://www.mejeticks.com/>
>>>
>>> a:
>>>
>>> 2323 N Akard Street
>>>
>>> ,
>>>
>>> Dallas
>>>
>>> ,
>>>
>>> 75201
>>>
>>> <https://www.linkedin.com/company/mejeticks/>
>>>
>>> <https://twitter.com/mejeticks>
>>>
>>> <https://www.facebook.com/mejeticks>
>>>
>>> <https://linktr.ee/mejeticks>
>>>
>>>
>>>
>>>
>>> The risk of trading futures and options can be substantial. All
>>> information, publications, and material used and distributed by Advance
>>> Trading Inc. shall be construed as a solicitation. ATI does not maintain an
>>> independent research department as defined in CFTC Regulation 1.71.
>>> Information obtained from third-party sources is believed to be reliable,
>>> but its accuracy is not guaranteed by Advance Trading Inc. Past performance
>>> is not necessarily indicative of future results.
>>>
>>
>
>

Re: Password Reset

[J. Hellenthal via NANOG]

You'll have to do your own workNANOG Info Pagemailman.nanog.org--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jan 2, 2024, at 13:25, Luiz Rosas  wrote:Hello, I'm trying to reset a password for username "guga0071", but the email address that is attached to this account I no longer have access to. Can you please update my account with the new email address "lrosas0...@gmail.com" and provide me with a link to reset my password.RegardsLuiz Rosas

Re: Ford.com network admin

[J. Hellenthal via NANOG]

FONDFound On Network Dead 浪--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Oct 30, 2023, at 12:13, Dennis Burgess  wrote:







That is what is not working.  If I go to the link from this specific prefix, it does not work, and I get the error I sent Becki. 
  
 

From: Brandon Jackson  
Sent: Monday, October 30, 2023 12:01 PM
To: Kain, Becki (.) 
Cc: Dennis Burgess ; NANOG list 
Subject: Re: Ford.com network admin

 


I get that too if I just go direct to
https://login ford.com, but if I use the link from the homepage while it still goes to the same domain it appends a bunch of stuff to the end of that link and does work.


On Mon, Oct 30, 2023, 12:11 Kain, Becki (.) via NANOG <nanog@nanog.org> wrote:




From inside of Ford, I get this:
 
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
 


From: NANOG ford@nanog.org>
On Behalf Of Dennis Burgess
Sent: Monday, October 30, 2023 12:01 PM
To: nanog@nanog.org
Subject: Ford.com network admin


 


WARNING: This message originated outside of Ford Motor Company. Use caution when opening attachments, clicking links, or responding.

 

I have a specific subnet of users that are getting denied access to even get to the login page at

https://login.ford.com.  Looking for someone to contact me offlist about this issue please
 



Dennis Burgess


Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, Enterprise Wireless Engineer

Hurricane Electric: IPv6 Sage Level

Cambium: ePMP


 

Author of "Learn RouterOS- Second Edition”


Link Technologies, Inc -- Mikrotik & WISP Support Services


Office: 314-735-0270  Website:
http://www.linktechs.net


Create your own Tickets via 
https://hd.linktechs.net 

Create Wireless Coverage’s with 
www.towercoverage.com


Need MikroTik Cloud Management: 
https://cloud.linktechs.net 

Remote Winbox Service: 
http://rwb.linktechs.net 
 

Re: Charter DNS servers returning invalid IP addresses

[Jason J. Gullickson via NANOG]

This is very interesting.

I did some poking-around and found other Squarespace customers with 
similar issues (in their case it was Google complaining that their sites 
were suspicious and therefore couldn't serve Google ads).  The leading 
theory is that the "canned" Squarespace sites are using an old version 
of some library or other piece of code that some software identifies as 
malware or otherwise dubious.


If I can figure out exactly what these services are upset about maybe I 
can take that to Squarespace and get them to fix it, but I'm not sure 
how far I'll get with what I know so far.



- Jason

On 2023-10-27 6:44 am, John Levine wrote:

It appears that J. Hellenthal via NANOG  said:

-=-=-=-=-=-

Maybe the site "has/had" a shopping cart infection at one point that 
has been found and eradicated at one point ?


Virustotal reported it four days ago, which suggests that whatever was
wrong with it is still wrong with it,

The usual (correct) response to "whitelist us because your malware
report is wrong" is "no, because it's not."

R's,
John

Re: OSP Management

[Stonebraker, Jack J]

3GIS here.  Great product.

JJ Stonebraker  |  Associate Director
The University of Texas System | Office of Telecommunication Services
(512) 232-0888  | j...@ots.utsystem.edu


From: NANOG  on behalf of Tim 
Burke 
Sent: Tuesday, October 31, 2023 10:26 AM
To: Mike Hammett ; michael.bro...@adams12.org 

Cc: NANOG 
Subject: Re: OSP Management

We're on OSPInsight here. Don't have much exposure to it, but it seems to do 
the trick well.

From: NANOG  on behalf of michael brooks - 
ESC 
Sent: Tuesday, October 31, 2023 8:26 AM
To: Mike Hammett 
Cc: NANOG 
Subject: OSP Management

On that note, what do you all use for managing OSP? We have been attempting to 
stand up PatchManager for quite some time, and find it a good product, but the 
billions of options can be overwhelming




michael brooks
Sr. Network Engineer
Adams 12 Five Star Schools
michael.bro...@adams12.org<mailto:michael.bro...@adams12.org>

"flying is learning how to throw yourself at the ground and miss"



On Fri, Oct 27, 2023 at 5:54 AM Mike Hammett 
mailto:na...@ics-il.net>> wrote:
 Always fun managing OSP.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com<https://urldefense.com/v3/__http://www.ics-il.com__;!!IR39LLzvxw!KJhHvAXNK_qlGRpKRzdjwrbUiToB9DdWW4qx_WhglUoygnqlGcLjg10kbR_UYNPg2VzXcAk2sSV0HIqI_JfB$>

Midwest-IX
http://www.midwest-ix.com<https://urldefense.com/v3/__http://www.midwest-ix.com__;!!IR39LLzvxw!KJhHvAXNK_qlGRpKRzdjwrbUiToB9DdWW4qx_WhglUoygnqlGcLjg10kbR_UYNPg2VzXcAk2sSV0HDRh8w21$>


This is a staff email account managed by Adams 12 Five Star Schools.  This 
email and any files transmitted with it are confidential and intended solely 
for the use of the individual or entity to whom they are addressed. If you have 
received this email in error please notify the sender.

Re: Charter DNS servers returning invalid IP addresses

[Jason J. Gullickson via NANOG]

That does help Greg.

I've heard from a few other folks on the list that the domain is 
considered suspicious by a few different providers like this.  It's a 
turnkey Squarespace gallery/ecommerce site so I'm not sure why it would 
be classified as a threat, but perhaps a previous domain holder was 
doing something that could have been and these reports are just 
outdated?


- Jason

On 2023-10-25 1:41 pm, Greg Dickinson wrote:

If it helps troubleshooting, when I click the domain in the email 
Mimecast tells me:


"We checked the website you are trying to access for malicious and 
spear-phishing content and found it likely to be unsafe."


Greg Dickinson, CCNA

Network Engineer

From: NANOG  On 
Behalf Of Mark Andrews

Sent: Wednesday, October 25, 2023 1:27 PM
To: Jason J. Gullickson 
Cc: nanog@nanog.org
Subject: Re: Charter DNS servers returning invalid IP addresses

This Message originates from outside Bryant Bank.   Please use caution 
when opening this correspondence, attachments or hyperlinks (URLs).  If 
you have questions, please contact IT Support.  Thank you.


It's being filtered. Only Charter can tell you why.

--

Mark Andrews

On 26 Oct 2023, at 05:07, Jason J. Gullickson via NANOG 
 wrote:


I've been working for a week or so to solve a problem with DNS 
resolution for Charter customers for our domain bonesinjars.com [1].  
I've reached-out to Charter directly but since I'm not a customer I 
couldn't get any help from them.  I was directed by a friend to this 
list in hopes that there may be able to reach a Charter/Spectrum 
engineer who might be able to explain and/or resolve this one.


A dig against Google's DNS servers correctly returns 4 A records:

dig bonesinjars.com [1] 8.8.8.8 [2]

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com [1] 
8.8.8.8 [2]

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com [1].   IN  A

;; ANSWER SECTION:
bonesinjars.com [1].60  IN  A   198.49.23.145 [3]
bonesinjars.com [1].60  IN  A   198.185.159.145 
[4]

bonesinjars.com [1].60  IN  A   198.49.23.144 [5]
bonesinjars.com [1].60  IN  A   198.185.159.144 
[6]


;; Query time: 1039 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7] (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 108

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8 [2].   IN  A

;; Query time: 35 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7] (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 36

Verizon, AT, Comcast and all other DNS servers we tested return the 
same 4 A records.  However the same dig against a Charter DNS 
(24.196.64.53 [8]) returns only 127.0.0.54 [9]


dig bonesinjars.com [1] 24.196.64.53 [8]

; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com [1] 24.196.64.53 [8]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com [1].INA

;; ANSWER SECTION:
bonesinjars.com [1].60INA127.0.0.54 [9]

;; Query time: 55 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7]
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 60

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;24.196.64.53 [8].INA

;; ANSWER SECTION:
24.196.64.53 [8].86400INA24.196.64.53 [8]

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7]
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 57

Any help understanding and addressing this is greatly appreciated!

Jason


NOTICE: This electronic mail message and any files transmitted with it 
are intended exclusively for the individual or entity to which it is 
addressed. The message, together with any attachment, may contain 
confidential and/or privileged information. Any unauthorized review, 
use, print, save, copy, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete copies.  Thank 
you.



Links:
--
[1] 
https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2z-wCDx1wrGIgQ

Charter DNS servers returning invalid IP addresses

[Jason J. Gullickson via NANOG]

I've been working for a week or so to solve a problem with DNS 
resolution for Charter customers for our domain bonesinjars.com.  I've 
reached-out to Charter directly but since I'm not a customer I couldn't 
get any help from them.  I was directed by a friend to this list in 
hopes that there may be able to reach a Charter/Spectrum engineer who 
might be able to explain and/or resolve this one.


A dig against Google's DNS servers correctly returns 4 A records:

dig bonesinjars.com 8.8.8.8

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com.   IN  A

;; ANSWER SECTION:
bonesinjars.com.60  IN  A   198.49.23.145
bonesinjars.com.60  IN  A   198.185.159.145
bonesinjars.com.60  IN  A   198.49.23.144
bonesinjars.com.60  IN  A   198.185.159.144

;; Query time: 1039 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 108

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8.   IN  A

;; Query time: 35 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 36

Verizon, AT, Comcast and all other DNS servers we tested return the 
same 4 A records.  However the same dig against a Charter DNS 
(24.196.64.53) returns only 127.0.0.54:


dig bonesinjars.com 24.196.64.53

; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com 24.196.64.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com.INA

;; ANSWER SECTION:
bonesinjars.com.60INA127.0.0.54

;; Query time: 55 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 60

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;24.196.64.53.INA

;; ANSWER SECTION:
24.196.64.53.86400INA24.196.64.53

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 57

Any help understanding and addressing this is greatly appreciated!

Jason

Re: TACACS+ server recommendations?

[J. Hellenthal via NANOG]

Just going to drop this in here ...Privileged Access Management Solutions for Enhanced Cybersecurity | PAM Systems | Fudo Securityfudosecurity.comIf you are looking for something a little more upbeat --  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Sep 22, 2023, at 16:00, Mike Lewinski via NANOG  wrote:We are using Okta's RADIUS service for 2fa to network gear currently, but looking to switch to tacacs+ for many reasons. Would prefer to implement tacacs+ with two-factor if possible.tac_plus-ng from https://www.pro-bono-publico.de/projects/tac_plus-ng.html has LDAP and PAM backends, among others, so I believe you can implement 2FA through them. I haven't implemented this yet but it's on my to-do list (and I'm also warily watching passkey developments and wondering how much effort I should put into something that likely won't be best practice in another year or two).I see Marc Huber is also promoting/supporting tacacs+ extension for SSH public key authhttps://github.com/MarcJHuber/event-driven-servers/wiki/TACACS_PLUS---SSH-Public-Key-Authentication

Re: it's mailman time again

[J. Hellenthal via NANOG]

You didn't lose your /. account because of a mailing list config.You lost it due to the bad practices or knowledge at the time.\o/--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Sep 2, 2023, at 17:08, Richard Porter  wrote:







Pouring kerosine on fire? *flame me back if warranted*


Voice networks have no POTS left in them? *mostly?* ….





Get Outlook for iOS


From: NANOG  on behalf of Randy Bush 
Sent: Saturday, September 2, 2023 4:30:07 PM
To: Jim Popovitch via NANOG 
Subject: Re: it's mailman time again
 


> Mail in transit is mostly TLS transport these days,

yep.  mostly.  opsec folk are not fond of 'mostly.'

> BUT mail in storage and idle state isn't always secured.  I'm sure
> that most any of us could find a public s3 bucket with an mbox file on
> it if we cared to look.

sigh

randy

Re: Questionnaire on building real network configuration dataset

[J. Hellenthal via NANOG]

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.


signature.asc
Description: PGP signature

Re: Land Mobile Radio (LMR) for Information Technology (IT) Professionals

[J. Hellenthal via NANOG]

CISA always 6 pages long and full of catchy words.

Is there anything beyond this that really adds any real substantial value ?

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 17, 2023, at 11:59, Sean Donelan  wrote:
> 
> 
> IT professionals are often tasked with planning, provisioning, implementing, 
> and managing LMR networks with the assumption that all computer networks are 
> basically the same and have the same general requirements. However, in some 
> cases this assumption has resulted in LMR networks being inadequately 
> provisioned, resourced, and managed or maintained. While each system is a 
> network, significant differences between the two must be considered to 
> address the infrastructure, planning, and lifecycle needs of typical IT 
> networks versus the unique requirements of LMR networks.
> 
> https://www.cisa.gov/news-events/news/safecom-and-ncswic-develop-land-mobile-radio-lmr-information-technology-it-professionals

Re: intuit DNS

[J. Hellenthal via NANOG]

Ruhroh someone took the ai out again

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Feb 12, 2023, at 02:01, Saku Ytti  wrote:
> 
> ╰─ dig NS intuit.com|grep ^intuit|ruby -nae 'puts $F[-1]'|while read dns;do
> echo $dns:;dig smartlinks.intuit.com @$dns|grep CNAME
> done
> a7-66.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a11-64.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a24-67.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a1-182.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a6-66.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> a18-64.akam.net.:
> smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
> dns1.p01.nsone.net.:
> dns2.p01.nsone.net.:
> dns3.p01.nsone.net.:
> dns4.p01.nsone.net.:
> ╭─ ytti@ytti   ~ 
>    0|0|0|1 ↵  09:58:40 
> 
> 
>> On Sat, 11 Feb 2023 at 23:01, Daniel Sterling  
>> wrote:
>> 
>> Someone at Intuit please look into why your DNS for this A record
>> hasn't been consistently resolving, this has been going on for several
>> days if not weeks
>> 
>> https://dnschecker.org/#A/smartlinks.intuit.com
>> 
>> -- Dan
> 
> 
> 
> -- 
>  ++ytti

RE: Smaller than a /24 for BGP?

[Chris J. Ruschmann]

How do you plan on getting rid of all the filters that don’t accept anything 
less than a /24?

In all seriousness If I have these, I’d imagine everyone else does too.



From: NANOG  On Behalf Of Justin 
Wilson (Lists)
Sent: Tuesday, January 24, 2023 9:19 AM
To: nanog@nanog.org
Subject: Smaller than a /24 for BGP?

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Have there been talks about the best practices to accept things smaller than a 
/24? I qm seeing more and more scenarios where folks need to participate in BGP 
but they do not need a full /24 of space.  Seems wasteful.  I know this would 
bloat the routing table immensely.  I know of several folks who could split 
their /24 into /25s across a few regions and still have plenty of IP space.



Justin Wilson
j...@j2sw.com<mailto:j...@j2sw.com>

—
https://blog.j2sw.com - Podcast and Blog
https://www.fd-ix.com

RE: Starlink routing

[Chris J. Ruschmann]

Don’t quote me on this, but I wouldn’t say they are doing anything different 
than you or I can do and have access to on the routing layer. It's probably 
just Nokia and Arista and whatever those systems provide. Stuff like Tunneling, 
ECMP, BFD and VxLan... Think spatially coordinated Zerotier and not based on 
latency. They also have a pretty good team of experts that have experience with 
large scale networking and automation they've plucked from various places.

How the Satellites talk to the end users is where all the magic is. But my 
understanding is that it's all custom developed networking as code that handles 
all the frequency coordination and hand offs with the ground.

-Original Message-
From: NANOG  On Behalf Of Michael 
Thomas
Sent: Sunday, January 22, 2023 1:43 PM
To: nanog@nanog.org
Subject: Starlink routing

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.



I read in the Economist that the gen of starlink satellites will have the 
ability to route messages between each satellite. Would conventional routing 
protocols be up to such a challenge? Or would it have to be custom made for 
that problem? And since a lot of companies and countries are getting on that 
action, it seems like fertile ground for (bad) wheel reinvention?

Mike

Re: Large RTT or Why doesn't my ping traffic get discarded?

[J. Hellenthal via NANOG]

As well if this persists you may consider disabling hardware rx/tx checksumming 
to see if it clears up your results. Some net cards can get glitchy causing 
this exact behavior.

GL

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 21, 2022, at 13:58, William Herrin  wrote:
> 
> On Wed, Dec 21, 2022 at 9:10 AM Jason Iannone  
> wrote:
>> Here's a question I haven't bothered to ask until now. Can someone please 
>> help me understand why I receive a ping reply after almost 5 seconds?
>> 
>> 64 bytes from 4.2.2.2: icmp_seq=398 ttl=54 time=4915.096 ms
>> 64 bytes from 4.2.2.2: icmp_seq=399 ttl=54 time=4310.575 ms
>> 64 bytes from 4.2.2.2: icmp_seq=400 ttl=54 time=4196.075 ms
>> 64 bytes from 4.2.2.2: icmp_seq=401 ttl=54 time=4287.048 ms
>> 64 bytes from 4.2.2.2: icmp_seq=403 ttl=54 time=2280.466 ms
>> 64 bytes from 4.2.2.2: icmp_seq=404 ttl=54 time=1279.348 ms
>> 64 bytes from 4.2.2.2: icmp_seq=405 ttl=54 time=276.669 ms
> 
> Hi Jason,
> 
> This usually means a problem on the Linux machine originating the
> packet. It has lost the ARP for the next hop or something similar so
> the outbound ICMP packet is queued. The glitch repairs itself,
> briefly, releasing the queued packets. Then it comes right back.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> For hire. https://bill.herrin.us/resume/

Re: Nov 16th (Overnight Traffic Pattern)

[J Crowe]

That was most likely due to Call of Duty Warzone 2.0 going live that day.

On Tue, Dec 6, 2022 at 2:34 PM Nicholas Warren 
wrote:

> I noticed something strange looking at our traffic pattern (eyeball
> network). Our usage normally drops very low between 4am and 6pm (central).
> But, on the 16th of November it never dropped.
>
>
>
> Was there a larger pattern or did a full moon only shine above our
> network?
>
>
>
> Nich Warren
>

Re: Sites blocking ISP Addresses

[J. Hellenthal via NANOG]

Formal snail mail is your only option.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 30, 2022, at 12:26, James Dexter  wrote:
> 
> 
> Dear list, 
> We have address ranges that are being blocked by sites like Ticketmaster. 
> Customer support is able to assist, and unable to receive a response from 
> legal or hostmaster emails. What are the recommendations for requesting a 
> removal from the blocked list at these sites? 
> 

Re: ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[J. Hellenthal via NANOG]

Nothing like a good ole April fools please fill my empty repo with your code. Happy 旅 genocide day everyone.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Nov 24, 2022, at 14:12, Matthew Petach  wrote:Whoa!Is it the start of April already?  I must have overslept last night, I could have sworn we just barely made it to Thanksgiving!MattOn Tue, Nov 22, 2022 at 6:48 AM AQ Glass <elemen...@gmail.com> wrote:anybody interested in this project?@oracle can own the .ticket tld; NS * ticket. -> virtualhost 96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with gov.xxx.ticket signup and further instructions//https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19codedevs can commit tohttps://github.com/element9v/takebackdarpathx-eOn Thu, Nov 17, 2022, 3:50 PM AQ Glass <elemen...@gmail.com> wrote:https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19#routetonull discuss#takebackdarpa-e

Re: ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[J. Hellenthal via NANOG]

That's a hard no!--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Nov 22, 2022, at 08:47, AQ Glass  wrote:anybody interested in this project?@oracle can own the .ticket tld; NS * ticket. -> virtualhost 96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with gov.xxx.ticket signup and further instructions//https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19codedevs can commit tohttps://github.com/element9v/takebackdarpathx-eOn Thu, Nov 17, 2022, 3:50 PM AQ Glass <elemen...@gmail.com> wrote:https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19#routetonull discuss#takebackdarpa-e

Re: Router ID on IPv6-Only

[J. Hellenthal via NANOG]

Right!

Personally it just needs to be unique. Relying on a Id to be unique when 
ascociated to an IP address that may be used on a failover system seems really 
poor to me.

Assign a random ID and plug it into your IPAM!. If at anything assign a router 
ID to a rack location and associate every bit of information  about that 
location in whatever you're tracking management can provide.

Personally I prefer date originated generated numbers that allow me to filter 
upon such and spill out the results to tell me where its at what rack its in, 
slot number etc...

But then again this is from a failover system perspective...


BOL

> On Sep 8, 2022, at 10:13, Randy Bush  wrote:
> 
>> During some IPv6 numbering discussions at work today, someone had a
>> question that I hadn't really considered before. How to choose 32-bit
>> router IDs for IPv6-only routers.
> 
> arbitrary 32 bit number unique in the autonomous system.  even in an
> ipv4 world it does not need to match any configured interface address.
> 
> randy


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: U.S. Court PACER system overloaded by public interest

[J. Hellenthal via NANOG]

> and linked to 
> https://file///Users/Shared/Internet%20Downloads/gov.uscourts.flsd.617854.102.1_1.pdf
>  . (It's still there as I write this.)

Doubt that link is going to work for anyone 浪

Re: Zayo/as6461 will now drop invalid prefixes from our peers.

[J. Hellenthal via NANOG]

Week or so ?

Care to clarify to be a "little bit more exact" on the start date at least ...

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Aug 18, 2022, at 12:58, Rob Robertson  wrote:
> 
> 
> The Zayo/as6461 network will  shortly start dropping all RPKI-invalid route 
> announcements that we receive from our peers.  This should be rolled
> out over our network in the next week or so.
> While we will still continue to accept existing invalid route announcements 
> from our customers for now, we will be working with our customers to reduce  
> and/or eliminate invalid announcements.
> Thank you,
> ;rob
> 
> Rob Robertson
> Network Architect | Zayo Group
> 

Re: Tool for virtual networks

[J. Hellenthal via NANOG]

I couldn't have replied better--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jul 18, 2022, at 10:38, Tom Beecher  wrote:But in the mean time (and generally) this should really only be used in a dedicated VM.  And the *primary* audience is my networks class--even though I shared with the broader networking community, in case others might find it useful or have feedback (thank you!).It's a cardinal rule that anything built with a set of assumptions about the environment it operates in will inevitably be run in a different environment somewhere, someday. :) On Fri, Jul 15, 2022 at 11:09 AM Casey Deccio <ca...@deccio.net> wrote:> On Jul 15, 2022, at 8:25 AM, J. Hellenthal <jhellent...@dataix.net> wrote:
> 
> For a quick cursory overview of this project, I would urge you to add an adendum or change the following line in the installation documentation...
> 
> "%sudo   ALL=(ALL:ALL) NOPASSWD: ALL"
> 
> This is technically influencing bad behavior with sudo for those that are not aware of the security impacts of such decisions.
> 
> I'm not one to provide a negative remark usually without suggesting a result that provides a positive impact that can be built upon. So with that said and along the lines of that id suggest adjusting the documentation to contain something of the sorts of a guided only per user or separate group other than "%sudo"... maybe "%cougarnet" and add instructions for creating the group and adding users to that group.
> 
> Beyond that... nice project and thank you for your contribution to networking. This may be beyond the scope of just this one mailing list and wish you the best.

Thanks so much for the feedback.  As noted, this is still a work-in-progress.  Now that I'm mostly past the proof-of-concept phase of development, and one of my near-term to-do items is to improve least privilege in the code.  I think it does fairly well in other places, but the sudo access is still too liberal.  At the moment, the plan is to enumerate the commands used with sudo in the code and apply them to a group of which a user must be a part.  For example:

%cougarnet   ALL=(ALL:ALL) NOPASSWD: /usr/bin/ip, /usr/sbin/sysctl

But in the mean time (and generally) this should really only be used in a dedicated VM.  And the *primary* audience is my networks class--even though I shared with the broader networking community, in case others might find it useful or have feedback (thank you!).

Cheers,
Casey

Re: Tool for virtual networks

[J. Hellenthal via NANOG]

For a quick cursory overview of this project, I would urge you to add an 
adendum or change the following line in the installation documentation...

"%sudo   ALL=(ALL:ALL) NOPASSWD: ALL"

This is technically influencing bad behavior with sudo for those that are not 
aware of the security impacts of such decisions.

I'm not one to provide a negative remark usually without suggesting a result 
that provides a positive impact that can be built upon. So with that said and 
along the lines of that id suggest adjusting the documentation to contain 
something of the sorts of a guided only per user or separate group other than 
"%sudo"... maybe "%cougarnet" and add instructions for creating the group and 
adding users to that group.

Beyond that... nice project and thank you for your contribution to networking. 
This may be beyond the scope of just this one mailing list and wish you the 
best.

Regards,

> On Jul 14, 2022, at 17:01, Casey Deccio  wrote:
> 
> Dear colleagues,
> 
> I've been developing a tool for building and experimenting with virtual 
> networks, primarily for use with teaching network protocols.  It's an active 
> work-in-progress, but I thought it might be time to reach out to NANOG in 
> case anyone else might find it useful and/or might have feedback to offer.  
> Here is the code:
> 
> https://github.com/cdeccio/cougarnet
> 
> It includes layer-2 switches, VLANs and trunking, and routers, all using 
> Linux processes in their own namespaces as network "nodes".  It was inspired 
> by mininet (https://mininet.org) but it was developed from scratch to meet 
> different needs.
> 
> The README has additional information.  If you install and run the code, 
> *please* do it in a *virtual machine*.  At this point, it requires superuser 
> capabilities to run things like "ip link", "ip addr", and "sysctl", among 
> other things, using sudo.  Much on the to-do list, but it meets my immediate 
> needs.  Just wanted to share in the mean time.
> 
> Cheers,
> Casey


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: cf is down?

[J. Hellenthal via NANOG]

Huh ?

Although the https://www.cryptopp.com/wiki/Ed25519 lib exploit could have 
something to do with this. Butt eh!


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Jun 21, 2022, at 11:55, Doug Barton  wrote:
> 
> Was someone scanning the Internet for vulnerabilities?
> 
> 
> On 6/21/22 12:20 AM, Eric Kuhnke wrote:
>> Massive spike in consumer facing services reported as broken by 
>> downdetector, almost all are likely cf customers. See downdetector homepage.

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

To what extent and to whom will you authorize to do that? 100 random college 
students? X number of new security firms? At some point it will break.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 17:04, b...@theworld.com wrote:
> 
> 
> It seems to me there's vulnerability testing and there's vulnerability
> testing and just lumping them all together motivates disparate
> opinions.
> 
> For example it's one thing to perhaps see if home routers
> login/passwords are admin/admin or similar, or if systems seem to be
> vuln to easily exploitable bugs and reporting such problems to someone
> in charge versus, say, hammering at some network to see when/if DDoS
> mitigation kicks in.
> 
> For example I've gotten email in the past that some of my servers were
> running ntp in a way which makes them vuln to being used for DDoS
> amplification and, I believe, fixed that. I didn't mind.
> 
> Anyhow, you all probably get my point without further hypotheticals or
> examples.
> 
> Scanning for known vulns and reporting can be ok, testing to
> destruction? Not so much.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re:

[J. Hellenthal via NANOG]

It's not about what you use as aposed more of where it's used from.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 13:47, Josh Luthman  wrote:
> 
> 
> I use Cogent: https://www.cogentco.com/en/looking-glass and HE which is 
> easier to remember: https://lg.he.net/
> 
>> On Mon, Jun 20, 2022 at 9:56 AM Glenn Kelley  
>> wrote:
>> Good Monday Morning Everyone. 
>> 
>> Quick Question: 
>> 
>> What is everyone's favorite software for running a looking glass. 
>> 
>> A friend asked me this over the weekend - and while there are others 
>> available on the internet to use - it would be helpful for them to run one 
>> within their own network. 
>> 
>> It has been a while since i have played setting one up so figured might as 
>> well ask 
>> 
>> 
>> Glenn S. Kelley, Connectivity.Engineer 
>> Text and Voice Direct:  740-206-9624
>> 
>> 
>> 

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

On Mon, Jun 20, 2022 at 11:02:25AM -0400, Michael Butler via NANOG wrote:
> I treat these folk with the same respect they afford me. Not once in 30
> years of having a connected network (v4 or v6) has any entity asked "is it
> OK if we .. ?".
> 
> To my mind, it seems rather idiotic and self-defeating to have the plumbing
> congested with packets intended to measure congestion :-(
> 
>   Michael

Well put!

> 
> On 6/20/22 09:46, Mel Beckman wrote:
> > Carsten,
> > 
> > No, it’s more like 50,000 furnace guys who show up several times a day to 
> > rattle doorknobs, attempt to push slim Jim’s into window latches, hack your 
> > garage door opener, sneak into your back garden, and fly drones around your 
> > home to see what valuables you might have. Yes, some of them are 
> > altruistic, but some are self-righteous officious boobs, and the vast 
> > majority are career criminals that will rob your house, drain your 
> > retirement account, and kill your family with a spoofed SWAT raid.
> > 
> >   -mel beckman
> > 
> > > On Jun 20, 2022, at 4:20 AM, Carsten Bormann  wrote:
> > > On 2022-06-20, at 04:18, Mel Beckman  wrote:
> > > > 
> > > > When researchers, or whoever, claim their scanning an altruistic 
> > > > service, I ask them if they would mind someone coming to their home and 
> > > > trying to open all the doors and windows every night.
> > > 
> > > Well, it is more like the guy who comes once a year and checks that your 
> > > central heating is not going to blow up.
> > > 
> > > (Disclaimer: I have supervised students who designed and executed benign 
> > > mass-scans of the IPv4 Internet in order to validate hypotheses about 
> > > market penetration of certain security updates, and I definitely would do 
> > > that again if there is a good reason to perform such a scan.)
> > > 
> > > Grüße, Carsten
> 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Test email

[J. Hellenthal via NANOG]

This is like setting a read-receipt-to: to a mailing list. The results
are phenom !

But on the other hand you get a nice handy list of replies that say "did
not read" ;) leaking their address as a member.

Done this by accident myself :(

On Mon, Jun 20, 2022 at 02:11:50AM -0600, h...@interall.co.il wrote:
> 
> Hello,
> 
> Checking Email Functionality.
> 
> Hosting Support
> Thank you,

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

On Mon, Jun 20, 2022 at 02:47:27PM +0200, Carsten Bormann wrote:
> J.,
> 
> > On 2022-06-20, at 14:14, J. Hellenthal  wrote:
> > 
> > Yeah that's another thing, "research" cause you need to learn it let's have 
> > them do it too, multiply that by every university \o/
> 

No no not saying there wasnt. Research is needed for sure and education
is very important. But the fact of most matters stand in that area where
some code may not exactly be up to par from "some students" and still
exaust itself on the public internet of things where little real
oversight actually happens from its origin until it has already impacted
multiple destinations that did not ask for it.

Definately did sign up for it! and with all the proper checks and
balances, can handle them appropriately at 2am when when N students have
been asleep letting their code run wild.

Sorry not picking on "you/this" in particular on your part. It's just
not all of them are exactly up to par while following what they believe
are best practices governed by an instructor(not you) that deems it
benign where I have found some instructors/educators have very little
knowledge in the field whatsoever beyond a textbook and a home
computer/lab. I look forward to the school years to begin, it brings a
challenge where traffic from skids drops between certain hours in
different countries and the detection begins for advertisement scanners
and real threats.

Noise is cool, it gives pretty results where the ugly of the networks
typically just annoy you. Not cool when its amplified by N number of
whatever (advertising/company/students) like a udp amplification attack
but initiated by india.edu, america.edu, X.edu all at the wrong time.

Anyway I retract

Happy fathers day yesterday and hope all your're weekends have been
great.

> there was some actual research involved.
> 
> I agree that there should be a very good reason to expend a tiny bit of 
> everyone’s resources on this.
> 
> I do not agree that this externality makes any research in this space 
> unethical.
> 
> You signed up for this when you joined the Internet (er, stuck with the IPv4 
> Internet, I should probably say).
> 
> Grüße, Carsten
> 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Yeah that's another thing, "research" cause you need to learn it let's have 
them do it too, multiply that by every university \o/

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 06:22, Carsten Bormann  wrote:
> 
> On 2022-06-20, at 04:18, Mel Beckman  wrote:
>> 
>> When researchers, or whoever, claim their scanning an altruistic service, I 
>> ask them if they would mind someone coming to their home and trying to open 
>> all the doors and windows every night. 
> 
> Well, it is more like the guy who comes once a year and checks that your 
> central heating is not going to blow up.  
> 
> (Disclaimer: I have supervised students who designed and executed benign 
> mass-scans of the IPv4 Internet in order to validate hypotheses about market 
> penetration of certain security updates, and I definitely would do that again 
> if there is a good reason to perform such a scan.)
> 
> Grüße, Carsten
> 

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Wish I still had that email from them where person "possibly not speaking for the company" stated that "they scan the entire internet for vulns and other nefarious things.Where I stated "don't care get your unwanted advertisement scans off my edge, if I want you in the future I know where to find you". And he kept beating around the bush.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jun 20, 2022, at 01:09, Owen DeLong via NANOG  wrote:shadow server (to the best of my knowledge) only scans sites that have invited them to do so.OwenOn Jun 19, 2022, at 10:43 , Forrest Christian (List Account) <li...@packetflux.com> wrote:See shadowserver.netOn Sun, Jun 19, 2022, 4:13 AM Ronald F. Guilmette <r...@tristatelogic.com> wrote:I would like to solicit the opinions of network operators on the practice
of scanning all of, or large chunks of the internet for known vulnerabilities.

In earlier times, this was generally viewed as being distinctly anti-social
behavior, but perhaps attitudes have changed relative to earlier eras.
I would thus like to know how people feel about it now, in 2022.


Regards,
rfg


P.S.  Just to be clear, I personally have neither any desire nor any intent
to undertake such activity myself, nor am I in communiacation with any party
or parties that have such an intent or desire.  I cannot however say that I
am unaware of any parties that may currently be involved in such activities.

Re: Test email

[J. Hellenthal via NANOG]

Novices 浪

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jun 20, 2022, at 03:36, Hank Nussbacher  wrote:
> 
> On 20/06/2022 11:30, Peter Potvin wrote:
> 
> I did not send this to the list.  I assume the admins are testing out what 
> has been blocking my emails for the past month and somehow this email slipped 
> thru.  Just ignore and delete.
> 
> -Hank
> 
>> Why did moderation let this through the filters? I don't believe that 
>> testing email functionality is the intended use case of the NANOG mailing 
>> list.
>> Also worth noting that the website for the domain this came from says the 
>> owner of the site specializes in "anti-spam", which based on this email 
>> alone doesn't look to be the case. Anyone else agree?
>> Regards,
>> Peter
>> On Mon., Jun. 20, 2022, 4:15 a.m. , > <mailto:h...@interall.co.il>> wrote:
>>Hello,
>>Checking Email Functionality.
>>Hosting Support
>>Thank you,
>> The information contained in this message may be privileged, confidential 
>> and protected from disclosure. This message is intended only for the 
>> designated recipient(s). It is subject to access, review and disclosure by 
>> the sender's Email System Administrator. If you have received this message 
>> in error, please advise by return e-mail so that our address records can be 
>> corrected and please delete immediately without reading, copying or 
>> forwarding to others. Any unauthorized review, use, disclosure or 
>> distribution is prohibited.
>> Copyright © 2022 Accuris Technologies Ltd. All Rights Reserved.
>> L'information contenue dans ce message pourrait être de nature privilégiée, 
>> confidentielle et protégée contre toute divulgation. Ce message est destiné 
>> à l'usage exclusif du(des) destinataire(s) visé(s). Le gestionnaire de 
>> système du courrier électronique de l'expéditeur pourrait avoir accès à ce 
>> message, l'examiner et le divulguer. Si ce message vous est transmis par 
>> erreur, veuillez nous en aviser par courrier électronique à notre adresse, 
>> afin que l'on puisse corriger nos registres, puis veuillez le supprimer 
>> immédiatement, sans le lire, le copier ou le transmettre à des tiers. Tout 
>> examen, toute utilisation, divulgation ou distribution non autorisé de cette 
>> information est interdit.
>> Droit d'auteur © 2022 Accuris Technologies Ltd. Tous droits réservés.
> 

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Yep that's exactly what that is. While the intention is good, it's all still unwarranted.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jun 19, 2022, at 21:18, Mel Beckman  wrote:




When researchers, or whoever, claim their scanning an altruistic service, I ask them if they would mind someone coming to their home and trying to open all the doors and windows every night. 


 -mel beckman


On Jun 19, 2022, at 6:14 PM, J. Hellenthal via NANOG  wrote:




 Had to send these guys a cease and desist a few years back as they became so noisy it was causing to much of a disconnect between information we were trying to compare.






Personally I don't care who you are. Probably not hiring your services (free or not), stay off my edge.


-- 
 J. Hellenthal


The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Jun 19, 2022, at 13:56, Amreesh Phokeer  wrote:





Project Sonar from Rapid7 conducts internet-wide surveys and is kind enough to share the data with researchers:
https://www.rapid7.com/research/project-sonar/


On Sun, Jun 19, 2022 at 10:24 PM Mark Seiden <m...@seiden.com> wrote:


btw, if you want to do this yourself, you might consider using something like


https://github.com/opsdisk/scantron





-- 
Amreesh Phokeer

Re: Scanning the Internet for Vulnerabilities

[J. Hellenthal via NANOG]

Had to send these guys a cease and desist a few years back as they became so noisy it was causing to much of a disconnect between information we were trying to compare.Can't for for more idiot services to just jump on the wagon and deploy their own scanners and pollute edges without a just cause. Personally I don't care who you are. Probably not hiring your services (free or not), stay off my edge.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jun 19, 2022, at 13:56, Amreesh Phokeer  wrote:Project Sonar from Rapid7 conducts internet-wide surveys and is kind enough to share the data with researchers:https://www.rapid7.com/research/project-sonar/On Sun, Jun 19, 2022 at 10:24 PM Mark Seiden <m...@seiden.com> wrote:btw, if you want to do this yourself, you might consider using something likehttps://github.com/opsdisk/scantron-- Amreesh Phokeer

Re: Bgpmon alternative

[J. Hellenthal via NANOG]

BGPlay isn't so bad. Alerting could be worked in they're somewhere but the 
explicit use case you need it for is somewhat vague ATM. As in "I have this 
scenario X that I am trying to get Y & Z information about.

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Jun 15, 2022, at 08:45, Mehmet Akcin  wrote:
> 
> Hi there
> 
> What are the best alternatives to BGPmon these days?
> 
> Goal is to try to monitor bgp routing changes for specific prefixes.
> 
> Mehmet
> -- 
> Mehmet
> +1-424-298-1903

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[J. Hellenthal via NANOG]

Faster off the line then more open connections are always available putting 
less strain on providers and endpoints allowing them to serve more people right 
off the line.

But we all know where bandwidth goes... once it's increased. ;)

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Jun 7, 2022, at 09:45, Denis Fondras  wrote:
> 
> Le Tue, Jun 07, 2022 at 08:12:07AM -0500, Mike Hammett a écrit :
>> Would it matter if it took 10 minutes or an hour? 
>> 
> 
> Yes, it means the computer could be off for 50 minutes.
> Also everyone who had a connection reset when uploading a big file after 55
> minutes understands why it is good if it only would take 10 minutes.
> 
> Peace of mind is under-rated :)
> 
>> 
>> What's the OneDrive rate limit? 
>> 
>> 
>> 
>> 
>> - 
>> Mike Hammett 
>> Intelligent Computing Solutions 
>> http://www.ics-il.com 
>> 
>> Midwest-IX 
>> http://www.midwest-ix.com 
>> 
>> - Original Message -
>> 
>> From: "Tony Wicks"  
>> To: nanog@nanog.org 
>> Sent: Monday, June 6, 2022 5:36:13 PM 
>> Subject: RE: FCC proposes higher speed goals (100/20 Mbps) for USF providers 
>> 
>> 
>> 
>>> This whole thread is about hypothetical futures, so it's not hard to 
>>> imagine downloads filling to available capacity. 
>>> Mike 
>> 
>> So, a good example of how this capacity is used, In New Zealand we have a 
>> pretty broad fibre network covering most of the population. My niece asked 
>> me to share my backup copy of her wedding photo’s/video’s the other day. I 
>> have a 4Gb/s / 4Gb/s XGSPON connection and she’s got a 1Gb/s / 500Mb/s GPON 
>> connection. I simply dropped a copy of the 5.1G directory into a one drive 
>> folder and shared it, 10 minutes later (one drive is still limited in how 
>> fast you can upload) she had it all and she was very happy. With these 
>> speeds its not even a consideration to think about capacity, everything just 
>> works. 

Re: Open source tool for network map visualization

[J. Hellenthal via NANOG]

Greylog has a feature to visualize attacks/threats on a map visualized by 
syslog messages being sent by IDS systems like snort/suricata. If either of 
those are deployed at your locations then you can get a map for each location 
among number of threats detected.

Just a simple related mapping feature.
https://www.graylog.org/

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On May 27, 2022, at 07:41, Marinos Dimolianis  
> wrote:
> 
> Hi all,
> 
> I was looking for an open source tool to visualize our network infrastructure 
> in a world map including also our link utilization.
> 
> Any ideas?
> 
> Thank you in advance,
> 
> Marinos
> 

Re: BGP Javascript Map/Visualization

[J. Hellenthal via NANOG]

https://github.com/anvaka/pm/tree/master/about#software-galaxies-documentation

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On May 26, 2022, at 17:46, Adam Thompson  wrote:
> 
> Neat.  Any idea who to ask questions of, regarding the incorrectness of the 
> data?  I would have assumed Job, but he's long gone from NTT, is this 
> abandonware or maintained?  Anyone know?
> 
> Adam Thompson
> Consultant, Infrastructure Services
> MERLIN
> 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: athomp...@merlin.mb.ca
> 
> 
>> -Original Message-
>> From: NANOG  On Behalf
>> Of b...@uu3.net
>> Sent: Thursday, May 26, 2022 3:50 PM
>> To: nanog@nanog.org
>> Subject: Re: BGP Javascript Map/Visualization
>> 
>> You were close... I think you mean this one?
>> https://as2914.net/
>> 
>> -- Original message --
>> 
>> From: Brian Johnson 
>> To: nanog@nanog.org
>> Subject: BGP Javascript Map/Visualization
>> Date: Thu, 26 May 2022 20:07:51 +
>> 
>> Hey all,
>> 
>> Sorry for the noise.  Years ago someone here built and shared a
>> javascript
>> visualization of what their routers saw for the state of BGP and paths
>> to
>> get to various ASs. One could use WSAD and other keys to fly around
>> and
>> examine various other ASs.  I thought it was as2814.net, but that
>> seems to
>> not be a thing anymore.  Can someone refresh my memory where that
>> might be?
>> Or did it get taken down?
>> 
>> Thanks in advance,
>> - brian
>> 
>> 
>> 
>> 
> 

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[j k]

With this funding, does the FCC require IPv6 and/or dual stack?  If not, it
could cause a new IPv6 digital divide.

Joe Klein

On Tue, May 24, 2022, 9:21 AM Max Tulyev  wrote:

> Do they help with a local government ("we do not need your cables, go
> avway")?
>
> 23.05.22 21:56, Sean Donelan пише:
> >
> > Money, money, money.
> >
> >
> > On Mon, 23 May 2022, Aaron Wendel wrote:
> >
> >> The Fiber Broadband Association estimates that the average US
> >> household will need more than a gig within 5 years.  Why not just jump
> >> it to a gig or more?
> >>
> >>
> >> On 5/23/2022 1:40 PM, Sean Donelan wrote:
> >>>
> >>>
> https://www.fcc.gov/document/fcc-proposes-higher-speed-goals-small-rural-broadband-providers-0
> >>>
> >>> The Federal Communications Commission voted [May 19, 2022] to seek
> >>> comment on a proposal to provide additional universal service support
> >>> to certain rural carriers in exchange for increasing deployment to
> >>> more locations at higher speeds. The proposal would make changes to
> >>> the Alternative Connect America Cost Model (A-CAM) program, with the
> >>> goal of achieving widespread deployment of faster 100/20 Mbps
> >>> broadband service throughout the rural areas served by rural carriers
> >>> currently receiving A-CAM support.
> >>>
> >>
> >>
> >
>

Re: 10 Do's + Don'ts for Visiting Québec + Register Now for N85!

[J EMail]

On Thu, 5 May 2022 at 08:57, Nanog News  wrote:

> *10 Do's + Don'ts for Visiting Québec*
> *NANOG 85 Meeting Will Take Place Jun. 6 - 8 in Montréal*
>
> We are delighted to cross international borders in our mission to grow,
> inspire + profoundly build the Internet of tomorrow!
>
> Montréal is Canada's second-largest city and is known for its melting pot
> of diverse culture, established universities, enthralling art, food,
> history + festivals. It has been called one of the world's "happiest
> locations" as an estimated 45,000 immigrants relocate to the city every
> year.
>
> For those who don't call Québec home, we have prepared a list of cultural
> "Do's and Don'ts" to help you quickly acclimate + thrive in this foreign
> destination.
>
> *READ MORE  *
>
>
>  I have lived ten minutes from Quebec and two hours from Montreal for a
long time, I have never encountered either item 1 or item 2. Of course,
there might be a place that won't take a credit card, but your credit card
company will charge you a fee and be happy to use a terrible exchange rate
as will restaurants if you pay in US cash.

Consider getting cash from your bank account at an ATM at a bank once you
land although there are fees there as well. If you are a TD bank customer,
TD is a Canadian Bank and that will eliminate a fee.

As for culture, smoked meat, bagels (they are different) and poutine should
be on this list.

Re: Comcast/Florida

[J. Hellenthal via NANOG]

Good find Jeff !



-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Apr 26, 2022, at 08:25, JeffP  wrote:
> 
> Joe-
> 
> Another wayward backhoe strikes again..
> 
> https://www.heraldtribune.com/story/news/local/2022/04/25/comcast-outage-no-internet-florida/7446019001/
> 
>> On 4/25/22 15:34, Joe Carroll wrote:
>> Comcast in Florida
> -- 
> JeffP
> 

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[J. Hellenthal via NANOG]

Hope this is 40 business hours

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Apr 5, 2022, at 22:42, Rubens Kuhl  wrote:
> 
> For the inclusion of proxy objects in ALTDB for ARIN-NONAUTH, this is
> the current state of objects among known IRRs:
> 
> 
> source  total obj rt objaut-num obj
> 
> AFRINIC127024  99313   2116
> ALTDB   29342  21385   1481
> APNIC  879374 572495  17737
> ARIN   151087  61535   2461
> ARIN-NONAUTH34334  29291932(* Final
> mirror obtained April 4 *)
> BBOI 1200869 57
> BELL29827  29613105
> CANARIE  1832   1425177
> HOST2  0  1
> IDNIC9301   4886   1845
> JPIRR   13404  11398425
> LACNIC   8008   4742   1039
> LEVEL3 111542  90593300
> NESTEGG 8  4  2
> NTTCOM 453257 444518548
> OPENFACE   25 17  1
> PANIX  42 40  1
> RADB  15943761397813   9077
> REACH   20280  18177  2
> RGNET  80 43  6
> RIPE  1394165 379711  37475
> RIPE-NONAUTH57851  54281   2140
> TC  29936  12207   3703
> WCGDB   65135  62849773None
> 
> 
> Rubens
> 
>> On Mon, Apr 4, 2022 at 12:57 PM Job Snijders via NANOG  
>> wrote:
>> 
>> Dear all,
>> 
>>> On Sat, Apr 02, 2022 at 09:09:58PM +, John Curran wrote:
>>> As previously reported here, ARIN will be shutting down the
>>> ARIN-NONAUTH IRR database on Monday, 4 April 2022 at 12:00 PM ET.
>>> 
>>> It is quite likely that some network operators will see different
>>> route processing as a result of this change, as validation against the
>>> ARIN-NONAUTH IRR database will not longer be possible.
>>> 
>>> Please be aware of this upcoming event and make alternative
>>> arrangements if you are presently relying on upon routing objects in
>>> the ARIN-NONAUTH IRR database.
>> 
>> I ran an analysis just now in which I created an intersection between
>> prefixes observed in the BGP default-free zone and exactly matching
>> route:/route6: objects in ARIN-NONAUTH. I then substracted exact
>> matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
>> APNIC IRR sources. The result is a list of routes which might
>> experience service disruptions due to missing IRR objects.
>> 
>> The below 2,749 Prefix + Origin AS pairings are at risk as a result of
>> ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
>> are likely to manifest themselves in the coming 24 - 32 hours. Prior to
>> this announcement, ARIN consulted with its community on the future of
>> its IRR service.
>> 
>> I voiced objection and raised concerns about (what appeared to be)
>> limited visibility into what exactly the effects of such a database
>> shutdown would mean for the Internet: 
>> https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
>> Other community members also shared concerns: 
>> https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
>> A number of graceful alternative mechanisms were proposed, but not
>> acted upon: 
>> https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html
>> 
>> One might argue "well, folks had more than a year to move their
>> objects!", but on the other hand, it is entirely possible not all the
>> right people were reached, or in cases where affected parties did
>> receive a communication from ARIN, they perhaps were unable to
>> understand the message.
>> 
>> Please check if any of your prefixes are on the below list, and if so,
>> double check whether your IRR administration is able to overcome the
>> disappearance of ARIN-NONAUTH. Godspeed!
>> 
>> This tool might be useful: https://irrexplorer.nlnog.net/
>> 
>> Kind regards,
>> 
>> Job
>> 

Re: "Permanent" DST

[J. Hellenthal via NANOG]

On Thu, Mar 17, 2022 at 12:51:56PM -0700, Owen DeLong via NANOG wrote:
> 
> 
> > On Mar 16, 2022, at 12:24 , Chris Adams  wrote:
> > 
> > Once upon a time, Owen DeLong  said:
> >> You’re right… Two changes to a single file in most cases:
> >> 
> >> 1. Set the correct new timezone (e.g. MST for California).
> > 
> > And now your system displays wrong info 100% of the time, since as I
> > understand it, the zones will be changed (e.g. for me, CST will change
> > from UTC-0600 to UTC-0500).  How will you distinguish between "old" MST
> > and "new" MST when you see it listed?
> 
> As I said, if necessary for your situation, rename the appropriate file and 
> then keep
> the TZ name and simply change the DST on/off flag to off.

that'll be done by most major distribution without thought.

> 
> Owen
> 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Dropping support for the .ru top level domain

[J. Hellenthal via NANOG]

Thank you for you're support.?.


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Mar 12, 2022, at 04:47, Patrick Bryant  wrote:
> 
> I don't like the idea of disrupting any Internet service. But the current 
> situation is unprecedented.
> 
> The Achilles Heel of general public use of Internet services has always been 
> the functionality of DNS. 
> 
> Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD 
> can be accomplished without disrupting the Russian population's ability to 
> access information and services in the West.
> 
> The only countermeasure would be the distribution of Russian national DNS 
> zones to a multiplicity of individual DNS resolvers within Russia. Russian 
> operators are in fact implementing this countermeasure, but it is a slow and 
> arduous process, and it will entail many of the operational difficulties that 
> existed with distributing Host files, which DNS was implemented to overcome. 
> 
> The .ru TLD could be globally disrupted by dropping the .ru zone from the 13 
> DNS root servers. This would be the most effective action, but would require 
> an authoritative consensus. One level down in DNS delegation are the 5 
> authoritative servers. I will leave it to the imagination of others to 
> envision what action that could be taken there...
> 
> ru  nameserver = a.dns.ripn.net
> ru  nameserver = b.dns.ripn.net
> ru  nameserver = d.dns.ripn.net
> ru  nameserver = e.dns.ripn.net
> ru  nameserver = f.dns.ripn.net
> 
> The impact of any action would take time (days) to propagate.
> 

Re: Cogent cutting links to Russia?

[J. Hellenthal via NANOG]

Yet another trash understanding from Jeff.

Give it a break dude!

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Mar 7, 2022, at 09:07, Masataka Ohta  
> wrote:
> 
> JeffP wrote:
> 
>> Actually, try this:
>> https://home.treasury.gov/news/press-releases/jy0628
> 
> Are you saying "sanctioning numerous Russian elites and their
> family members" has something to do with NANOG?
> 
>   Masataka Ohta

Re: Russia to disconnect from global Internet

[J. Hellenthal via NANOG]

This whole convo is out of hand for this list

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 6, 2022, at 18:36, Jorge Amodio  wrote:
> 
> 
> 
> kick your leader out of the window first ...
> - Elon
> 
>> On Sun, Mar 6, 2022 at 5:54 PM Jay Hennigan  wrote:
>> Dear Elon:
>> 
>> Us next?
>> 
>> - Russian citizens
>> 
>> > 

Re: Get in touch with Cloudflare

[J. Hellenthal via NANOG]

There are a couple to a few that lurk here. Give it a few hours.

This list is a lot less volume than they have on the interim communications.

-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Feb 28, 2022, at 08:52, Oskar Borgqvist via NANOG  wrote:
> 
> Hi
> 
> We have tried to get hold of cloudflare because we have migrated from one ASN 
> to another.
> 
> We have tried with the contact information that is public (peeringdb). We 
> have been waiting for several weeks without a response.
> 
> Would have appreciated if anyone here could have helped us with this.
> 
> With kind regards,
> Oskar Borgqvist
> Bahnflow AB

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Huh


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Feb 11, 2022, at 09:10, Tom Beecher  wrote:
> 
> I am disappointed but not surprised to see this discussion on NANOG. 
> Encouraging Users to use a tool (that is often ignored by the hardware 
> targeted) by providing a non-revenue-creating special target does not make 
> business sense.
> 
> To be fair, I don't think this is unique to this community. Plenty of 
> conversations on the IETF lists that are fundamentally the same. ( Proposals 
> to change X or implement standard Y to solve something that is already 
> solvable with current tech and standards. ) Really it's just the complexity 
> of the existing solution that's different. :) 
> 
> On Fri, Feb 11, 2022 at 9:51 AM james.cut...@consultant.com 
>  wrote:
> On Feb 11, 2022, at 8:33 AM, Tom Beecher  wrote:
>> 
>> The prediciate assumption that "pinging one destination is a valid check 
>> that my internet works' is INCORRECT. There is no magical unicorn that could 
>> be built that could make that true, and 'they're gonna do it anyways' is a 
>> poor excuse to even consider it. 
>> 
> 
> The predicate assumption that unsuccessful pinging one destination is a valid 
> check that my internet DOES NOT work' is  ALSO INCORRECT. Still no magical 
> unicorn. 
> 
> I am disappointed but not surprised to see this discussion on NANOG. 
> Encouraging Users to use a tool (that is often ignored by the hardware 
> targeted) by providing a non-revenue-creating special target does not make 
> business sense.
> 
> An allied issue is educating ‘Users’ about traceroute AKA sequential ping 
> with TTL progression:
> 
>   •  Seeing missing or excessively long traceroute results from 
> intermediate nodes does NOT indicate a real problem, especially when the 
> target node is reachable with acceptable delay. 
> 
> I’ve lost count of my replies on user forums explaining this issue, even to 
> otherwise well educated users. 
> 
> To be blunt, browsing to amazon.com, apple.com or another vendor site is a 
> simple and easy to teach Internet aliveness check and, at least, offers the 
> chance for the targeted vendor site to receive revenue from sales. I have no 
> crisis of conscience from clicking an vendor shortcut for a basic end-to-end 
> Internet functional test. Or for teaching a User to do the same. This meets 
> the business purpose locally and requires no $pecial effort from Users, 
> network providers, or target systems. This precludes memorization of IP 
> addresses by end Users thus reducing the offered load from the likes of 
> excessive ping 8.8.8.8. 
> 
> I would expect NANOG members to have favorite ping target addresses based on 
> their environment, e.g., default router and a few designated targets. These 
> are useful for manual debugging but, as mentioned previously, are not 
> suitable as singular input to network monitoring.

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Not to mention. It is viable traffic to monitor, if I know that I get X
number of icmp traffic through a point in tranfer consistently and that
starts to drop off considerably that it may be a failing connection due
to some circumstance I should start checking that equipment.

And if im that connection in the middle... that is money !

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



-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Anyone willing to write a icmp(8/0) concatenation/concentration/proxy tool ? 
That can be deployed at the provider edge ?

Catch all the packets !!!

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Feb 8, 2022, at 21:18, Mike Hammett  wrote:
> 
> 
> What irked me today was an equipment manufacturer. I found out because Google 
> had some issues handling ICMP to their DNS resolvers today and some of my 
> devices started spazzing out.
> 
> There's no reason this manufacturer doesn't just setup a variety their own 
> servers to handle this, other than being lazy.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP
> 
> From: "Mark Delany" 
> To: "NANOG" 
> Sent: Tuesday, February 8, 2022 5:13:30 PM
> Subject: Re: Authoritative Resources for Public DNS Pinging
> 
> On 08Feb22, Mike Hammett allegedly wrote:
> 
> > Some people need a clue by four and I'm looking to build my collection of 
> > them. 
> 
> > "Google services, including Google Public DNS, are not designed as ICMP 
> > network testing services"
> 
> Hard to disagree with "their network, their rules", but we're talking about 
> an entrenched,
> pervasive, Internet-wide behaviorial issue.
> 
> My guess is that making ping/ICMP less reliable to the extent that it becomes 
> unusable
> wont change fundamental behavior. Rather, it'll make said "pingers" reach for 
> another tool
> that does more or less the same thing with more or less as little extra 
> effort as possible
> on their part.
> 
> And what might such an alternate tool do? My guess is one which SYN/ACKs 
> various popular
> TCP ports (say 22, 25, 80, 443) and maybe sends a well-formed UDP packet to a 
> few popular
> DNS ports (say 53 and 119). Let's call this command "nmap -sn" with a few 
> tweaks, shall
> we?
> 
> After all, it's no big deal to the pinger if their reachability command now 
> exchanges
> 10-12 packets with resource intensive destination ports instead of a couple 
> of packets to
> lightweight destinations. I'll bet most pingers will neither know nor care, 
> especially if
> their next-gen ping works more consistently than the old one.
> 
> So. Question. Will making ping/ICMP mostly useless for home-gamers and lazy 
> network admins
> change internet behaviour for the better? Or will it have unintended 
> consequences such as
> an evolutionary adaptation by the tools resulting in yet more unwanted 
> traffic which is
> even harder to eliminate?
> 
> 
> Mark.
> 

Re: Request to participate in 2-min study survey on IPv6 Adoption

[J. Hellenthal via NANOG]

That's just plain as* bullsh** right there.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 30, 2022, at 19:09, Töma Gavrichenkov  wrote:
> 
> 
> Peace,
> 
>> On Thu, Jan 27, 2022, 4:38 PM Smahena Amakran  
>> wrote:
>> For my studies, I am researching IPv6 adoption.
> 
> 
> For your consideration, there's one thing that's always overlooked.
> 
> E.g. I've been talking once to a big employee of a large content provider, 
> and that person told me they don't enable IPv6 because doing otherwise 
> produces tons of comment spam.
> 
> The thing is, we have this spam problem. This is not really the "information 
> security issue" you've mentioned, this is just a glimpse of a real issue.
> 
> IPv6 is now cheap as chips. It's very dirty therefore. All kinds of bots, 
> spammers, password brute force programs live in there, and it's significantly 
> harder to correlate and ditch these with the sparse IPv6 address space.
> 
> ISPs don't typically focus on these kinds of things but ISPs, speaking of 
> large ones, are also typically champions in IPv6 deployment.  It's usually 
> content providers who don't do their stuff.  And, as sad as it gets, it's not 
> getting away any time soon since it's there for a reason.
> 
> --
> Töma

Re: [EXTERNAL] Happy Holidays

[J. Hellenthal via NANOG]

HH -

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Dec 22, 2021, at 17:13, Mann, Jason via NANOG  wrote:
> 
> 
> Same to everyone out there!!
>  
> From: NANOG  On Behalf Of Nanog News
> Sent: Wednesday, December 22, 2021 3:17 PM
> To: nanog-annou...@nanog.org; nanog@nanog.org
> Subject: [EXTERNAL] Happy Holidays
>  
> Wishing you + yours a very warm holiday season from NANOG. 

Re: Anyone seeing ping corruption?

[J Doe]

On 2021-12-09 11:50, Lukas Tribus wrote:


On Thu, 9 Dec 2021 at 17:39, Deepak Jain  wrote:

Google’s 14 corrupts the packet or maybe deliberately manipulates it? 1.1.1.1 
doesn’t do that.


8.8.8.8 truncates ICMP's responses, this is well known. Different
platforms will react differently to it.

lukas@dev:~$ ping 8.8.8.8 -c1 -s1000
PING 8.8.8.8 (8.8.8.8) 1000(1028) bytes of data.
76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 (truncated)

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.657/5.657/5.657/0.000 ms
lukas@dev:~$ ping 1.1.1.1 -c1 -s1000
PING 1.1.1.1 (1.1.1.1) 1000(1028) bytes of data.
1008 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=15.8 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.893/15.893/15.893/0.000 ms
lukas@dev:~$


Hi,

Out of curiosity - does anyone know why Google is truncating ICMP 
responses ?


Thanks,

- J

Re: Theorical question about cyclic dependency in IRR filtering

[J. Hellenthal via NANOG]

Coin phrase ... IRR (dedup)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 29, 2021, at 07:17, Job Snijders via NANOG  wrote:
> 
> 
> Hi Anurag,
> 
> Circular dependencies definitely are a thing to keep in mind when designing 
> IRR and RPKI pipelines!
> 
> In the case of IRR: It is quite rare to query the RIR IRR services directly. 
> Instead, the common practise is that utilities such as bgpq3, peval, and 
> bgpq4 query “IRRd” (https://IRRd.net) instances at for example whois.radb.net 
> and rr.ntt.net. You can verify this with tcpdump. These IRRd instances serve 
> as intermediate caches, and will continue to serve old cached data in case 
> the origin is down. This phenomenon in the global IRR deployment avoids a lot 
> of potential for circular dependencies.
> 
> Also, some organisations use threshold checks before deploying new IRR-based 
> filters to reduce risk of “misfiring”.
> 
> 
> The RPKI case is slightly different: the timers are far more aggressive 
> compared to IRR, and until “Publish in Parent” (RFC 8181) becomes common 
> place, there are more publication points, thus more potential for operators 
> to paint themselves into a corner.
> 
> Certainly, in the case of RPKI, all Publication Point (PP) operators need to 
> take special care to not host CAs which have the PP’s INRs listed as 
> subordinate resources inside the PP.
> 
> See RFC 7115 Section 5 for more information: “Operators should be aware that 
> there is a trade-off in placement of an RPKI repository in address space for 
> which the repository’s content is authoritative. On one hand, an operator 
> will wish to maximize control over the repository. On the other hand, if 
> there are reachability problems to the address space, changes in the 
> repository to correct them may not be easily access by others”
> 
> Ryan Sleevi once told me: "yes, it strikes me that you should prevent 
> self-compromise from being able to perpetually own yourself, by limiting an 
> attacker’s ability to persist beyond remediation."
> 
> A possible duct tape approach is outlined at  
> https://bgpfilterguide.nlnog.net/guides/slurm_ta/
> However, I can’t really recommend the SLURM file approach. Instead, RPKI 
> repository operators are probably best off hosting their repository *outside* 
> their own address space.
> 
> Just like with Authoritative DNS servers, make sure you also can serve your 
> records via a competitor! :-)
> 
> For example, if ARIN moved one of their three publication point clusters into 
> address space managed by any of the other four RIRs, some risk would be 
> reduced.
> 
> Kind regards,
> 
> Job
> 
>> On Mon, 29 Nov 2021 at 13:37, Anurag Bhatia  wrote:
>> Hello everyone, 
>> 
>> While discussing IRR on some groups recently, I was thinking if there can be 
>> (and if there is) cycling dependency in filtering where IRR (run by whoever 
>> APNIC, RIPE, RADB etc) uses some upstream and accepts only routes with 
>> existing & valid route object. 
>> 
>> 
>> 
>> So hypothetical case (can apply to any IRR): 
>> 
>> APNIC registry source is whois.apnic.net and points to 202.12.28.136 / 
>> 2001:dc0:1:0:4777::136. The aggregate of both these has a valid route object 
>> at the APNIC registry itself. 
>> 
>> Their upstreams say AS X, Y and Z have tooling in place to generate and push 
>> filters by checking all popular IRRs. All is well till this point. 
>> 
>> Say APNIC has some server/service issue for a few mins and X Y and Z are 
>> updating their filters at the same time. They cannot contact whois.apnic.net 
>> and hence miss generating filters for all APNIC IRR hosted prefixes. 
>> 
>> X, Y and  Z drop APNIC prefixes including those of IRR & the loop goes on 
>> from this point onwards. 
>> 
>> So my question is: Can that actually happen? 
>> If not, do X, Y and Z and possible all upstreams till default-free zone 
>> treat these prefixes in a special manner to avoid such loop in resolution? 
>> 
>> 
>> 
>> 
>> Thanks! 
>> 
>> -- 
>> Anurag Bhatia
>> anuragbhatia.com

Re: is ipv6 fast, was silly Redeploying

[j k]

When considering the IPv6 product, I would suggest you read
USGv6-Revision-1 (1) to define the specification you need for the product.
Then go to the USGv6 Registry (2), select the features and read the
Supplier Declaration of Conformity (SDOC) to ensure that the product meets
your requirements. Do this prior to having the discussion with the vendor
sales.

Also, ask for documents which provide details on performance and security
testing. It will save you hours of troubleshooting problems and patching
vulnerability.

Lessons learned from implementing IPv6 products.

(1) https://www.nist.gov/programs-projects/usgv6-program/usgv6-revision-1
(2) https://www.iol.unh.edu/registry/usgv6

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Sat, Nov 20, 2021 at 2:36 AM John Lee  wrote:

> Cisco and Juniper routers have had v6 functionality for over 10 years.
> Lucent/Nokia, and others. Check UNL list at
> https://www.iol.unh.edu/registry/usgv6 for v6 compliant routers and
> switches.
>
> John Lee
>
> On Fri, Nov 19, 2021 at 5:48 PM John Levine  wrote:
>
>> It appears that Michael Thomas  said:
>> >And just as impossible since it would pop it out of the fast path. Does
>> >big iron support ipv6 these days?
>>
>> My research associate Ms. Google advises me that Juniper does:
>>
>>
>> https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/ipv6-technology-overview.html
>>
>> As does Cisco:
>>
>>
>> https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9600-series-switches/nb-06-cat9600-ser-sup-eng-data-sheet-cte-en.pdf
>>
>> R's,
>> John
>>
>

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[J. Hellenthal via NANOG]

Just replying to Joe's post here to add a little more context to at least one 
of the problems that will certainly appear if this would come about.

FreeBSD operators have been using this space for quite a long time for many 
NAT'ing reasons including firewalls and other services behind them for jail 
routing and such.

https://dan.langille.org/2013/12/29/freebsd-jails-on-non-routable-ip-addresses/

That's just one example that I've seen repeated in multiple other ways. One of 
which a jail operator with about 250 addresses out of that range that enabled 
his jail routed services.

Of course that can be changed but really for just this small of a influx of 
addresses ? Seems really wasteful to me.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 20, 2021, at 23:54, Joe Maimon  wrote:
> 
> 
> Jay Hennigan wrote:
>>> On 11/19/21 10:27, William Herrin wrote:
>>> Howdy,
>>> That depends on your timeline. Do you know many non-technical people
>>> still using their Pentium III computers with circa 2001 software
>>> versions? Connected to the Internet?
>> 
>> There are lots of very old networked industrial machines with embedded 
>> computers operated by non-network-savvy people that are still very much in 
>> use.
>> 
>> Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be a bit 
>> surprised to find quite a few 2001-era boxes still in service.
> In the context of re-purposed IPv4 address scopes specialized equipment will 
> tend to be fairly limited in its communication needs and unlikely to be 
> affected.
> 
> I certainly hope they are, otherwise the security implications are severe.
> 
> How about we recast this as general purpose internet communicating platforms 
> likely to have occasion to interact with these re-purposed addresses are 
> nearly certain to undergo an upgrade or more over the next decade, or how 
> many non-technical people are still using the original wrtg platform to 
> connect them to the internet?
> 
> And yes, its quite possible that even then those addresses may have some more 
> baggage than the typical IPv4 block in use today (which are hardly clean 
> bills of health more often than not).
> 
> But the sooner the effort begins the more likely the utilitarian value will 
> be there if or when its needed.
> 
> Joe

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[J. Hellenthal via NANOG]

He answered it completely. "You" worried about interception of RPKI exchange 
over the wire are failing to see that there is nothing there important to 
decrypt because the encryption in the transmission is not there !

And yet you've failed to even follow up to his question... "What's your point 
regarding your message? ROV does not use (nor needs) encryption."

So maybe you could give some context on that so someone can steer you out of 
the wrong direction.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 30, 2021, at 10:31, A Crisan  wrote:
> 
> 
> Hi Matthew, 
> 
> Quantum computing exists as POCs, IBM being one of those advertising them and 
> announced to extend their project. There are others on the market, Amazon 
> advertised quantum computing as a service back in 2019: 
> https://www.theverge.com/2019/12/2/20992602/amazon-is-now-offering-quantum-computing-as-a-service.
>  The bottle neck of the current technology is scalability: we will not see QC 
> as personal computing level just yet (to go in more detail, current 
> technologies work at cryogenic temperatures, thus they are hyper expensive 
> and not really scalable), but they exist and one could be imagine they 
> are/will be used for various tasks.
> 
> On the other hand, you've actually commented every word of my mail, minus the 
> stated question. Thanks. 
> 
> Best Regards, 
> Dora Crisan 
> 
> 
> 
>  
> 
>> On Fri, Oct 29, 2021 at 8:10 PM Matthew Walster  wrote:
>> 
>> 
>>> On Fri, 29 Oct 2021, 15:55 A Crisan,  wrote:
>>> Hi Matthew,
>>> I was reading the above exchange, and I do have a question linked to your 
>>> last affirmation. To give you some context, the last 2021 ENISA report seem 
>>> to suggest that internet traffic is "casually registered" by X actors to 
>>> apply post Retrospective decryption (excerpt below). This would be at odds 
>>> with your (deescalating) affirmation that hijacks are non-malicious and 
>>> they are de-peered quickly, unless you pinpoint complete flux arrest only. 
>>> Are there any reportings/indicators... that look into internet flux 
>>> constant monitoring capabilities/capacities? Thanks.
>> 
>> 
>> RPKI uses authentication not confidentiality. There is no encryption taking 
>> place, other than the signatures on the certificates etc.
>> 
>>> Excerpt from the introduction: "What makes matters worse is that any cipher 
>>> text intercepted by an attacker today can be decrypted by the attacker as 
>>> soon as he has access to a large quantum computer (Retrospective 
>>> decryption).
>> 
>> 
>> Which do not exist (yet).
>> 
>>> Analysis of Advanced Persistent Threats (APT) and Nation State capabilities,
>> 
>> 
>> Buzzwords.
>> 
>>> along with whistle blowers’ revelations
>> 
>>>  have shown that threat actors can and are casually recording all Internet 
>>> traffic in their data centers
>> 
>> 
>> No they're not. It's just not possible or indeed necessary to duplicate 
>> everything at large scale. Perhaps with a large amount of filtering, certain 
>> flows would be captured, but in the days of pervasive TLS, this seems less 
>> and less worthwhile.
>> 
>>>  and that they select encrypted traffic as interesting and worth 
>>> storing.This means that any data encrypted using any of the standard 
>>> public-key systems today will need to be considered compromised once a 
>>> quantum computer exists and there is no way to protect it retroactively, 
>>> because a copy of the ciphertexts in the hands of the attacker. This means 
>>> that data that needs to remain confidential after the arrival of quantum 
>>> computers need to be encrypted with alternative means"
>> 
>> 
>> None of this is relevant to RPKI (ROV) at all. In fact, it reads like the 
>> fevered dreams of a cyber security research student. What's your point 
>> regarding your message? ROV does not use (nor needs) encryption.
>> 
>> M
>> 

Re: Safe Geo-location Defaults

[J. Hellenthal via NANOG]

I'd agree with that wholly. I've had a drunk couple show up at my place years 
back insisting I had her phone. Once the guy tried to push through the door he 
got the business end of good ole Louie and a cute little breaking and entering 
sentence at a vacation destination known as lockup 浪

With enough said if this was a business location or courthouse it may have 
saved them a little gas and time getting there, and myself not having to wake 
up so damn late.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 21, 2021, at 09:02, Sean Donelan  wrote:
> 
> Has anyone published "safe" geo-location defaults? By safe I mean default 
> lat/lon coordinates for a country, state/province, city, postal code which do 
> not resolve near a residence.
> 
> It seems like too many people use "Find My " or other geo-location 
> services, and then go to the exact location shown on the mapping service for 
> the default lat/lon which is often a default location.  Knock on the person 
> which happens to live near the default centroid, and acuse them of stealing 
> their  because "Find My " showed that location.
> 
> 
> 

RE: Linux WiFi Package Issues

[Chris J. Ruschmann]

I have the same issues with a Lenovo when connecting to a wifi6 that does 8x8 
and 4x4 Mimo

Moving back to Wifi5 access point and I don’t have the issues anymore.


Hope this helps.


From: NANOG  On Behalf Of Pascal 
Masha
Sent: Tuesday, October 12, 2021 3:22 AM
To: nanog@nanog.org
Subject: Linux WiFi Package Issues

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hello All,

I have been wondering whether there is any known issue with the Linux WiFi 
package since the last 3 days or so? I'm Ubuntu 20.04.3 LTS 64bit Distro and 
WiFi has been dropping almost every 5 minutes. A colleague on another Linux 
Disto also contacted me about the same thing. Has anyone in the community 
experienced the same issue?

Regards
Paschal Masha

Re: Linux WiFi Package Issues

[J. Hellenthal via NANOG]

Shrug... almost straight to junk 

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 12, 2021, at 08:02, Pascal Masha  wrote:
> 
> 
> Hello All,
> 
> I have been wondering whether there is any known issue with the Linux WiFi 
> package since the last 3 days or so? I'm Ubuntu 20.04.3 LTS 64bit Distro and 
> WiFi has been dropping almost every 5 minutes. A colleague on another Linux 
> Disto also contacted me about the same thing. Has anyone in the community 
> experienced the same issue?
> 
> Regards
> Paschal Masha

Re: DNS pulling BGP routes?

[J. Hellenthal via NANOG]

They most likely sent an update to the DNS servers for TLV DNSSEC and in 
oversight forgot they needed to null something's out of the workbook to not 
touch the BGP instances.

I'd hardly believe that would be triggered by the dns server itself.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 6, 2021, at 12:45, Michael Thomas  wrote:
> 
> So if I understand their post correctly, their DNS servers have the ability 
> to withdraw routes if they determine are sub-optimal (fsvo). I can certainly 
> understand for the DNS servers to not give answers they think are unreachable 
> but there is always the problem that they may be partitioned and not the 
> routes themselves. At a minimum, I would think they'd need some consensus 
> protocol that says that it's broken across multiple servers.
> 
> But I just don't understand why this is a good idea at all. Network topology 
> is not DNS's bailiwick so using it as a trigger to withdraw routes seems 
> really strange and fraught with unintended consequences. Why is it a good 
> idea to withdraw the route if it doesn't seem reachable from the DNS server? 
> Give answers that are reachable, sure, but to actually make a topology 
> decision? Yikes. And what happens to the cached answers that still point to 
> the supposedly dead route? They're going to fail until the TTL expires anyway 
> so why is it preferable withdraw the route too?
> 
> My guess is that their post while more clear that most doesn't go into enough 
> detail, but is it me or does it seem like this is a really weird thing to do?
> 
> Mike
> 
> 
>> On 10/5/21 11:56 PM, Bjørn Mork wrote:
>> Masataka Ohta  writes:
>> 
>>> As long as name servers with expired zone data won't serve
>>> request from outside of facebook, whether BGP routes to the
>>> name servers are announced or not is unimportant.
>> I am not convinced this is true.  You'd normally serve some semi-static
>> content, especially wrt stuff you need yourself to manage your network.
>> Removing all DNS servers at the same time is never a good idea, even in
>> the situation where you believe they are all failing.
>> 
>> The problem is of course that you can't let the servers take the
>> decision to withdraw from anycast if you want to prevent this
>> catastrophe.  The servers have no knowledge of the rest of the network.
>> They only know that they've lost contact with it.  So they all make the
>> same stupid decision.
>> 
>> But if the servers can't withdraw, then they will serve stale content if
>> the data center loses backbone access. And with a large enough network
>> then that is probably something which happens on a regular basis.
>> 
>> This is a very hard problem to solve.
>> 
>> Thanks a lot to facebook for making the detailed explanation available
>> to the public.  I'm crossing my fingers hoping they follow up with
>> details about the solutions they come up with.  The problem affects any
>> critical anycast DNS service. And it doesn't have to be as big as
>> facebook to be locally critical to an enterprise, ISP or whatever.
>> 
>> 
>> 
>> Bjørn

Re: FYI: NANOG and ICANN

[J. Hellenthal via NANOG]

You mean they could not come together enough to share even the same page yet 
even a domain name or central corporation to oversee these needs ?

Personally I'm calling partially "bullshit" the Matthew McConaughey way!

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 4, 2021, at 09:33, Patrick W. Gilmore  wrote:
> 
> NANOG’s version: 
> https://www.nanog.org/stories/nanog-signs-a-memorandum-of-understanding-with-internet-society-icann/
> 
> -- 
> TTFN,
> patrick
> 
> 
>> On Oct 4, 2021, at 4:42 AM, Hank Nussbacher  wrote:
>> 
>> https://www.icann.org/en/announcements/details/icann-signs-a-memorandum-of-understanding-with-nanog-27-9-2021-en
>> 
>> Regards,
>> Hank
> 

Re: The great Netflix vpn debacle! (geofeeds)

[J. Hellenthal via NANOG]

Also don't get a smart litterbox... ;-)

Yeah that's a thing and connects to the local Wi-Fi. Kinda want to DMZ that 
mutha and wait for a script kiddie to turn one of my cats upside down...

dubs litter-robot.com

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Aug 31, 2021, at 19:16, Jay Hennigan  wrote:
> 
> On 8/31/21 16:32, Jeroen Massar via NANOG wrote:
> 
>> Fun part being that it is hard to get a Dumb TV... though that is primarily 
>> simply because of all the tracking non-sense in them that makes them 
>> 'cheaper'... (still wonder how well that tracking stuff complies with GDPR, 
>> I am thinking it does not ... Schrems anyone? :) )
> 
> Just get a "smart" TV, don't connect it to the Internet, and use its HDMI 
> ports for your cable box, Apple TV, etc. and/or antenna input for local 
> off-air reception.
> 
> -- 
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV

Re: netflow in the core used for surveillance

[J. Hellenthal via NANOG]

Im finding this really hard to believe for the "Team Cymru" part at least. 
Being originally a provider of security centric configuration of network 
components... IOS ... Juniper etc... and maintaining such a high standard for 
years that they turn foot and resell/sell data on customer traffic obtained 
from other networks they themself are a customer of for resale of data. This 
feels like a hit job on a company that secures more than it insecures by gov't 
passage.

Not trying to start a flame war here but... what do you do to your most secure 
threat? (That has financial and influential aspects)... 


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Aug 25, 2021, at 16:13, Randy Bush  wrote:
> 
> https://www.vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru
> 
> used to get dissidents, activists, and journos killed
> 
> at, comcast, ... zayo, please tell us you do not do this.
> 
> randy

Re: 100G, input errors and/or transceiver issues

[Stonebraker, Jack J]

We have a moderately dense deployment of 100-Gig LR4 (Both DWDM Lambdas and 
Juniper MX) around our WAN and we don't clock any background input errors on 
our interfaces unless there is an ongoing problem.  That said, we have 
experienced issues with sub-millisecond link state changes between two 
endpoints that are physically cross connected to one another with no 
intermediary Layer 1 (DWDM, Etc.).  There doesn't seem to be rhyme or reason to 
this and we've looked at each lane extensively and so far, everything has been 
inconclusive.  We also experienced some code issues on Juniper MPC3D-NG's 
running 100-Gig's and our DWDM Client Ports where timing would start to slip 
and eventually cause the link to fail.  Both Juniper and the DWDM Vendor found 
code variances they patched.  We haven't had any such issues on Juniper MPC5's 
7's or the 10003 Line Cards.

TL;DR:  In my experience, 100-Gig might require some more TLC then 10-Gig to 
run clean and is more sensitive to variations in transport.  Other's mileage 
may vary.

Best,
JJ Stonebraker  |  Associate Director
The University of Texas System | Office of Telecommunication Services
(512) 232-0888  | j...@ots.utsystem.edu


From: NANOG  on behalf of Graham 
Johnston 
Sent: Monday, July 19, 2021 12:19 PM
To: Saku Ytti 
Cc: nanog list 
Subject: Re: 100G, input errors and/or transceiver issues

Saku,

I don't at this point have long term data collection compiled for the issues 
that we've faced. That said, we have two 100G transport links that have a 
regular background level of input errors at ranges that hover between 0.00055 
to 0.00383 PPS on one link, and none to 0.00135 PPS (that jumped to 0.03943 PPS 
over the weekend). The range is often directionally associated rather than 
variable behavior of a single direction. The data comes from the last 24 hours, 
the two referenced links are operated by different providers on very different 
paths (opposite directions). Over shorter distances, we've definitely seen 
input errors that have affected PNI connections within a datacenter as well. In 
the case of the last PNI issue, the other party swapped their transceiver, we 
didn't even physically touch our side; I note this only to express that I don't 
think this is just a case of the transceivers that we are sourcing.

Comparatively, other than clear transport system issues, I don't recall this 
sort of thing at all with 10G "wavelength" transport that we had purchased for 
years prior. I put wavelengths in quotes there knowing that it may have been a 
while since our transport was a literal wavelength as compared to being muxed 
into a 100G+ wavelength.

On Mon, 19 Jul 2021 at 12:01, Saku Ytti mailto:s...@ytti.fi>> 
wrote:
On Mon, 19 Jul 2021 at 19:47, Graham Johnston
mailto:johnston.grah...@gmail.com>> wrote:

Hey Graham,

> How commonly do other operators experience input errors with 100G interfaces?
> How often do you find that you have to change a transceiver out? Either for 
> errors or another reason.
> Do we collectively expect this to improve as 100G becomes more common and 
> production volumes increase in the future?

New rule. Share your own data before asking others to share theirs.

IN DC, SP markets 100GE has dominated the market for several years
now, so it rings odd to many at 'more common'. 112G SERDES is shipping
on the electric side, and there is nowhere more mature to go from
100GE POV. The optical side, QSFP112, is really the only thing left to
cost optimise 100GE.
We've had our share of MSA ambiguity issues with 100GE, but today
100GE looks mature to our eyes in failure rates and compatibility. 1GE
is really hard to support and 10GE is becoming problematic, in terms
of hardware procurement.


--
  ++ytti

Re: google fi outage?

[J. Hellenthal via NANOG]

Can confirm t-mobile as working in south east wi

> On May 28, 2021, at 08:23, Dan Walters via NANOG  wrote:
> 
> 
> Just figured id let everyone know if they haven’t seen yet that at least in 
> the WI area the only working carrier for fi right now is T-Mobile. The rest 
> will assign the wrong phone numbers to the activated sim.
> 

Re: DoD IP Space

[j k]

In the positive side of things, guess we will see IPv6 usage.

Joe Klein

On Sun, Apr 25, 2021, 6:11 PM John Curran  wrote:

> Sronan -
>
> I made no claims other than pointing out that IP address blocks in the
> ARIN registry are subject to ARIN policies.
>
> ARIN was formed specifically so that the Internet community could engage
> in self-regulation for IP number resources; to wit: "Creation of ARIN will
> give the users of IP numbers (mostly Internet service providers,
> corporations and other large institutions) a voice in the policies by which
> they are managed and allocated within the North American region” [1] – thus
> ARIN's policies for management of the registry apply to all resources in
> the registry because that was inherent to the purpose to which ARIN was
> formed.
>
> This includes having ARIN "assume full responsibility for Internet
> Protocol (IP) number assignments and related administrative tasks
> previously handled by NSI.”, whereby ARIN formally became the successor
> registry operator for organizational assignments in a long chain that
> includes USC/ISI, SRI, GSI, and NSI.
>
> The community wanted self-governance, and that’s exactly what it got…  the
> result is a fairly important reason to participate in ARIN policy
> development and/or governance if you feel strongly about these matters.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> [1] https://www.nsf.gov/news/news_summ.jsp?cntn_id=102819 - "Internet
> Moves Toward Privatization / IP numbers handled by non-profit”
>
>
> On Apr 25, 2021, at 11:38 AM, sro...@ronan-online.com wrote:
>
>  So you are claiming that ARIN has jurisdiction over DoD IP space?
>
> Sent from my iPhone
>
> On Apr 25, 2021, at 9:13 AM, John Curran  wrote:
>
>  Sronan -
>
> I’d suggest asking rather than making assertions when it comes to ARIN, as
> this will avoid propagating existing misinformation in the community.
>
> Many US government agencies, including the US Department of Defense, have
> signed registration services agreements with ARIN.
>
> From https://account.arin.net/public/member-list -
>
> United States Department of Defense (DoD)
>
> USDDD 
>
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> On 25 Apr 2021, at 8:54 AM, sro...@ronan-online.com wrote:
>
> Except these DoD blocks don’t fall under ARIM justification, as they
> predate ARIN. It is very likely that the DoD has never and will never sign
> any sort of ARIN agreement.
>
> Sent from my iPhone
>
> On Apr 25, 2021, at 3:40 AM, Mel Beckman  wrote:
>
> Mark,
>
> ARIN rules require every IP space holder to publish accurate — and
> effective —  Admin, Tech, and Abuse POCs. The DOD hasn’t done this, as I
> pointed out, and as you can test for yourself. Your expectation that the
> DOD will “generally comply with all of the expected norms” is sorely naive,
> and already disproven.
>
> As far as “why does anyone on the Internet need to publish to your
> arbitrary standards”, you seem to forget that in the U.S., the government
> is accountable to the People. Where a private company may not have to
> explain its purposes, the government most certainly does in the private
> sector. With these IP spaces being thrust into the civilian realm, yes,
> they owe the citizenry an explanation of their actions, just as they would
> if they had started mounting missile launchers on highway overpasses. It’s
> a direct militarization of a civilian utility.
>
> Keep in mind that the U.S. Government — under all administrations — has
> shown that it will abuse every technical advantage it can, as long as it
> can do so in secret. Perhaps you’ve forgotten James Clapper, the former
> director of national intelligence, who falsely testified to Congress that
> the government does “not wittingly” collect the telephone records of
> millions of Americans. And he was just the tip of the iceberg. Before
> Clapper under Obama there was the Bush administration’s Stellar Wind"
> warrantless surveillance program. The list of government abuse of civilian
> resources is colossal .
>
> Fighting against that isn’t political. It’s patriotic.
>
> -mel
>
> On Apr 25, 2021, at 12:02 AM, Mark Foster  wrote:
>
> 
>
> On 25/04/2021 3:24 am, Mel Beckman wrote:
>
> This doesn’t sound good, no matter how you slice it. The lack of
> transparency with a civilian resource is troubling at a minimum. I’m going
> to bogon this space as a defensive measure, until its real — and detailed —
> purpose can be known. The secret places of our government have proven
> themselves untrustworthy in the protection of citizens’ data and networks.
> They tend to think they know “what’s good for” us.
>
> -mel
>
>
> Why does anyone on the Internet need to publish to your arbitrary
> standards, what they intend to do with their IP address ranges?
>
> Failure to advertise the IP address space to the 

Re: 10 years from now... (was: internet futures)

[Javier J]

Since FiOS still doesn't do ipv6 (I don't bother checking anymore) I've
used tunnelbroker since I was stuck on Comcast.
I'm not running BGP since that's overkill for my home lab needs. just a
tunnel with the /64 they give you and an addition /48.

If I have to renumber, there are maybe just 4-5 places where an ipv6 is
manually set. I'll just setup a new tunnel and change the router
advertisement settings.

- J

On Tue, Mar 30, 2021 at 4:53 AM  wrote:

> So, I assume you have PI IPv6 space and doing BGP with HE?
> In other case, if anything will happen to HE (they close they
> tunnelbroker service) you will have to renumber.
>
>
> -- Original message --
>
> From: Javier J 
> To: b...@uu3.net
> Cc: nanog 
> Subject: Re: 10 years from now... (was: internet futures)
> Date: Mon, 29 Mar 2021 13:57:20 -0400
>
> I've had an IPV6 tunnel from Hurricane Electric for 10+ years I think.
> IPv4 will probably live as it does now in my network, mostly for management
> / interserver coms for legacy hardware/software that doesn't support ipv6.
>
>
> On Fri, Mar 26, 2021 at 5:31 PM  wrote:
>
> > Oh, sorry to disappoint you, but they are not missing anything..
> > Internet become a consumer product where data is provided by
> > large corporations similary to TV now. Your avarage Joe consumer
> > does NOT care about NAT and that he cant run services or he does NOT
> > have full e2e communication.
> >
> > Yes, you are right, NAT was a second class internet for a while but
> > now it seems that we cannot live without it anymore :)
> > I dont really see other way how I can connect LAN to internet now.
> > Using public IPs? Thats so terrible idea. How can I be el-cheappo
> > dual-homed then?
> >
> >
> > -- Original message --
> >
> > From: Mark Andrews 
> > To: Andy Ringsmuth 
> > Cc: Grant Taylor via NANOG 
> > Subject: Re: 10 years from now... (was: internet futures)
> > Date: Sat, 27 Mar 2021 08:00:38 +1100
> >
> > There are more smart phones in use in the world today the world than can
> > be
> > addressed by IPv4. Complaining about lack of IPv6 deployment has been
> > legitimate for a long time. Telcos shouldn˙˙t have to deploy NATs. Homes
> > shouldn˙˙t have to deploy NATs. Businesses shouldn˙˙t have to deploy
> NATs.
> >
> > NATs produce a second class Internet.  We have had to lived with a second
> > class Internet for so long that most don˙˙t know what they are missing.
> --
> > Mark Andrews
> >
>

Re: 10 years from now... (was: internet futures)

[Javier J]

I've had an IPV6 tunnel from Hurricane Electric for 10+ years I think.
IPv4 will probably live as it does now in my network, mostly for management
/ interserver coms for legacy hardware/software that doesn't support ipv6.


On Fri, Mar 26, 2021 at 5:31 PM  wrote:

> Oh, sorry to disappoint you, but they are not missing anything..
> Internet become a consumer product where data is provided by
> large corporations similary to TV now. Your avarage Joe consumer
> does NOT care about NAT and that he cant run services or he does NOT
> have full e2e communication.
>
> Yes, you are right, NAT was a second class internet for a while but
> now it seems that we cannot live without it anymore :)
> I dont really see other way how I can connect LAN to internet now.
> Using public IPs? Thats so terrible idea. How can I be el-cheappo
> dual-homed then?
>
>
> -- Original message --
>
> From: Mark Andrews 
> To: Andy Ringsmuth 
> Cc: Grant Taylor via NANOG 
> Subject: Re: 10 years from now... (was: internet futures)
> Date: Sat, 27 Mar 2021 08:00:38 +1100
>
> There are more smart phones in use in the world today the world than can
> be
> addressed by IPv4. Complaining about lack of IPv6 deployment has been
> legitimate for a long time. Telcos shouldn˙˙t have to deploy NATs. Homes
> shouldn˙˙t have to deploy NATs. Businesses shouldn˙˙t have to deploy NATs.
>
> NATs produce a second class Internet.  We have had to lived with a second
> class Internet for so long that most don˙˙t know what they are missing. --
> Mark Andrews
>

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[J. Hellenthal via NANOG]

Nail -> Head <- Hammer

Well put ! I don’t know if it could have been put better than that.

-- 
J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 23, 2021, at 10:57, Emil Pfeffer  wrote:
> 
> On Tue, Mar 23, 2021 at 09:20:14AM -0500, Mike Hammett wrote:
>> "But why it should or shouldn't be clicked..."
>> Sorta like most man pages.
> 
> They both need prior knowledge to use. 
> We tend to simplify things in order to save time but then the new generation 
> comes
> in and thinks the simple things it's all there is and have no willingness to 
> go
> back in time and accumulate "useless" knowledge. It is useless because the 
> problems
> it fixes were already fixed but it is paramount in understanding whats behind 
> the 
> simple things. Knowledge can only be simplified so much and there's no 
> shortcut to
> accumulating it. (hence why most people will prefer to just use the tools)
> 
> The generational gap is not an issue it is how things need to be. The network
> engineering the younger generation deals with is not the same networking the 
> old
> generation deals with but built upon this old networks. This two generations 
> do
> not need the same knowledge and it is in each others best interest that they 
> stay
> separated. Although we would gladly help someone that is obviously putting in 
> the
> effort and is looking to learn we have not volunteered to be teachers and 
> some people
> need to understand that we prefer to keep it simple because we have no time 
> to waste.
> 
> It is easy to believe that the method you are using is the one but eventually
> the good ones will have to pass the test of time which mailling lists and a 
> plethora
> of the old tools successfully did. 
> --

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[J. Hellenthal via NANOG]

Can we end this troll here

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 20, 2021, at 20:48, Eric Kuhnke  wrote:
> 
> 
> It's one thing to use a GUI tool when it's convenient and quick. I think 
> anyone that's ever experienced setting up a Unifi controller would probably 
> prefer provisioning a new 802.11ac AP from the GUI rather than doing it 
> manually at a command line. 
> 
> But it's another thing to consider that we have a whole new generation of 
> people who don't know and don't care what's going underneath the GUI and 
> might not be able to do anything with the OS running on bare metal, if they 
> have to. 
> 
> If we intend to abstract away configuring devices to a GUI level only and not 
> care about what's going on under the hood, then it's time for everyone to 
> just run out and renew their MCSE certifications and buy Meraki subscriptions.
> 
> 
> 
>> On Sat, Mar 20, 2021 at 6:35 PM David Siegel  wrote:
>> 
>> ...not to mention that all mature networks are moving more towards GUI front 
>> ends for their automated network.  As the complexity of a network increases, 
>> CLI access becomes considerably more risky.
>> 
>> The idea that "real engineers use the CLI" is dinosaur thinking that will 
>> eventually land those with that philosophy out of a job.  Just my personal 
>> $.02 (though I'm certainly not alone in my opinion).
>> 
>> But I'd like to reiterate that the board's goal with modernization is not to 
>> alienate anyone from the existing community by forcing them into a 
>> web-interface.  Discourse is under evaluation, and if it doesn't accomplish 
>> the goal we'll try something else or build our own tool.
>> 
>> Dave
>> 
>> 
>> 
>> 
>>> On Sat, Mar 20, 2021 at 6:52 PM Matthew Petach  
>>> wrote:
>>> 
>>> 
>>> On Sat, Mar 20, 2021 at 5:13 PM scott  wrote:
>>> [...] 
>>>>  Of course, one would 
>>>> not find an HTTP GUI on the bigger networks dealt with on this list; 
>>>> only on the tiny networks.  So they're beginning learners and are, of 
>>>> course, welcome.  They will lean a lot, just as I did in the early days 
>>>> and do every day now days.
>>> [...] 
>>>> scott
>>> 
>>> Let's see...
>>> Google: Gmail
>>> Microsoft: Hotmail/Outlook/Office365
>>> Yahoo/VerizonMedia: Yahoo Mail
>>> 
>>> I'd have to say, there's some pretty big networks on this list that 
>>> use HTTP GUIs for their email.
>>> 
>>> Of course, you might be big enough that you look down on the 
>>> networks of Google, Microsoft, and VZM as "tiny networks" -- in 
>>> which case, you're definitely entitled to your opinion, as all 8000
>>> pound gorillas that look down on the puny 800 lb gorillas are.  ;)
>>> 
>>> Matt
>>>  

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[J. Hellenthal via NANOG]

Here here !

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 20, 2021, at 19:13, scott  wrote:
> 
> 
> :: The board has been thinking about enhancements to the NANOG list for a 
> couple of years now
> 
> Please let me put in my $0.02.  I would like to ask that there're no changes. 
>  For myself, it has been 24 years here and I see no problems.  I enjoy the 
> off-topic as much as the on-topic...most times.  If a person can't figure out 
> how to filter out a subject or sender in an email client they will have way 
> more problems trying to be a network engineer on anything but the tiniest of 
> networks.  I would think a person who can't figure out how use filters on a 
> mail client would rather configure routers through the HTTP GUI, rather than 
> the CLI.  Of course, one would not find an HTTP GUI on the bigger networks 
> dealt with on this list; only on the tiny networks.  So they're beginning 
> learners and are, of course, welcome.  They will lean a lot, just as I did in 
> the early days and do every day now days.
> 
> In agreement with others here, randy's comment:
> 
> "i do not find the volume or diversity on the nanog list problematic.
> in fact, i suspect its diversity and openness are major factors in
> it being the de facto global anything-ops list.  perhaps we do not
> need to fix that."
> 
> Is spot on.
> 
> And last, John Covici also hit the nail on the head and all network engineers 
> will recognize his comment "Keep it simple, please" as a very nice way of 
> saying KISS, which any network engineer who has had time on a network will 
> realize as the basic design principle.
> 
> scott
> 

Re: Saudi Arabia

[J. Hellenthal via NANOG]

ROFL 

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 18, 2021, at 11:54, Randy Bush  wrote:
> 
> 
>> 
>> https://www.itc.sa/en/
> 
> mehmet, you actually answered rod's question.  that is not allowed on
> the nanog list.  you need to start a 20 message thread excoriating him
> for asking for actual operational help finding a circuit in a difficult
> place.
> 
> what is this world coming to?  sheesh!
> 
> randy
> 
> ---
> ra...@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
> signatures are back, thanks to dmarc header butchery

Re: DoD IP Space

[j k]

Two questions...

1. How many on this list already have dual-stack or IPv6 only in operation?

2. If you are running IPv4 only, and a major service was to switch to IPv6
only,..
 a. How fast would you move to a dual-stack of IPv6 only?
 b. What would it impact your customers?
 c. How would it impact your business?

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Thu, Feb 11, 2021 at 12:56 PM William Herrin  wrote:

> On Thu, Feb 11, 2021 at 6:13 AM Izaac  wrote:
> > On Wed, Feb 10, 2021 at 10:38:00AM -0800, William Herrin wrote:
> > > None whatsoever. You just have to be really big.
> >
> > Hi Beel,
>
> That was unnecessary. Sorry I used an S instead of a Z.
>
> > Thanks for backing me up with an example of an organization with
> > competent network engineering.  Their ability to almost infinitely
> > leverage the existing rfc1918 address space to serve an appreciable
> > fraction of all Internet attached hosts is a real demonstration of the
> > possible.
>
> Except they don't. One of the reasons you can't put vms in multiple
> regions into the same VPC is they don't have enough IP addresses to
> uniquely address the backend hosts in every region. They end up with a
> squirrelly VPC peering thing they relies on multiple gateway hosts to
> overcome the address partitioning from overlapping RFC1918.
>
> In other words, it proves the exact opposite of your assertion.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Cable Landing Station Address

[J. Hellenthal via NANOG]

Can you talk to …. Mehmet Akcin meh...@akcin.net “copied in” or someone he may 
be able to refer you to ?



https://www.infrapedia.com/app/cls/vung-tau-vnpt



> On Mar 10, 2021, at 08:13, Rod Beck  wrote:
> 
> Vung Tau


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Network / Infrastructure security testing services

[J. Hellenthal via NANOG]

Huh

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 9, 2021, at 13:57, Nathanael Cariaga  wrote:
> 
> 
> Apologies for this shameless plug, but wanted to ask if any folks on this 
> list who does network/infrastructure security testing? Please to reach back 
> to me off the list.   
> 
> Thank you for your time.
> 

Re: gnail rejecting logwatch reports

[J. Hellenthal via NANOG]

Rejected with what error codes? 

Let’s carry this off list ... can you send through the full headers ?

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Mar 4, 2021, at 11:11, jimmy keffer  wrote:
> 
> i have a server that use gmail for smtp it working excpt its rejecting
> my  logwatch reports other mail is sending fine the reject page at
> google is no help
> thanks jimmy

Re: DoD IP Space

[Kenneth J. Dupuis]

1995? https://en.m.wikipedia.org/wiki/IPv6On Feb 11, 2021 8:51 PM, Michael Thomas  wrote:
On 2/11/21 5:41 PM, Izaac wrote:
>
>> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.
> So, in your mind, IPv4 was "obsolete" in 1996 -- almost three years
> before IPv6 was even specified?  Fascinating.  I could be in no way
> mistaken for an IPv4/NAT apologist, but that one's new on me.

ipv6 was on my radar in the early 90's. it was definitely at least 1993, 
maybe earlier.

Mike

Re: New York Carrier Hotels

[Kenneth J. Dupuis]

I don't know about future ones but 32AoA, 60H, etc. are still important.https://www.datacentermap.com/usa/new-york/new-york/I've lived here 44 years so if you need photos, on-the-ground knowledge, etc., let me know off-list. KenOn Feb 11, 2021 1:51 PM, Rod Beck  wrote:

Hey Folks, 





I am looking for a list of the ten most important NYC telecom hotels. Over the last 15 years carrier business has shifted to a large extent to Secaucus Equinix & Google has taken over a big part of 111 8th Avenue. What the important sites today and are any
 new facilities on the horizon?












Roderick Beck
Global Network Capacity Procurement
United Cable Company
www.unitedcablecompany.com

https://unitedcablecompany.com/video/


New York City & Budapest

rod.b...@unitedcablecompany.com
Budapest: 36-70-605-5144
NJ: 908-452-8183 

Re: Suspicious IP reporting

[J. Hellenthal via NANOG]

Sorry wasn’t meant directly aimed at you… unless you are the same person \?

> On Feb 5, 2021, at 09:12, J. Hellenthal  wrote:
> 
> And just like deploying IoT devices in vehicles without proper security 
> preparations will lead you to a C network … just saying the hammer swings 
> both ways here and getting a IP reported isn’t going to do you any damn good 
> at ALL.
> 
> Personally I’d rip those IoT vehicles off the market for a recall but I 
> suspect we’ll be hearing of that in the not to distant future.
> 
> So in hindsight why don’t we just close down this thread here.
> 
>> On Feb 5, 2021, at 08:50, Joe  wrote:
>> 
>> Much like your banning of an email address is an ability you have with your 
>> provider (gmail), you should have the same abilities with your cellular 
>> provider for an IP address. 
>> I would think (at a minimum) you would be able to negotiate such an action 
>> with them, perhaps it is time to re-negotiate that contract?
>> If your simply trying to report an offending IP for brute force stuff 
>> perhaps the tact you may find more helpful is to ask for a contact at xzy 
>> ISP on list, versus asking folks to do reporting for you. As well there are 
>> like 100s of lists to report this to outside of NANOG  
>> As well, if I am reading this correctly, deployment of devices that have 
>> public facing IPs and do not have a means to protect themselves is 
>> concerning to say the least. 
>> This is about as reckless as putting up a login page without a password and 
>> crying foul when something gains access that you didn't expect. Again, I do 
>> not know all of the details of this so I may be way off base with that 
>> respect. 
>> 
>> If your ability to prevent issues is due to lack of a firewall/control to 
>> your network, possibly asking for help in mitigating such threats would be 
>> better, as there are a lot of very well versed/clever folks that help out.
>> Regards,
>> -Joe
>> 
>> 
>> On Thu, Feb 4, 2021 at 7:17 PM JoeSox  wrote:
>> Ryan,
>> Thanks but like I said these devices are in moving vehicles ok?
>> I stated we have a plan but it is ways out.  
>> FACT: we have a known malicious C
>> FACT: We know what networks it is hitting and the cellular network is the 
>> most vulnerable, imo.
>> FACT: this IP is against Verizon terms of service so the way to address it 
>> is to report it to them as they request.
>> 
>> I honestly got what I needed from this thread, thanks. And I thank the 
>> nonbullies that helped me off list.
>> --
>> Thank You,
>> Joe 
>> 
>> 
>> On Thu, Feb 4, 2021 at 5:11 PM Ryan Hamel  wrote:
>> Joe,
>> 
>> 
>> 
>> It isn’t on Verizon to setup a firewall, especially if you have a direct 
>> public IP service. The device being attached directly to the Internet (no 
>> matter the transmission medium), must be able to protect itself. ISPs 
>> provide routers which function as a NAT/Firewall appliance, to provide a 
>> means of safety and convenience for them, but also charge you a rental fee.
>> 
>> 
>> 
>> Stick a Cradlepoint router or something in front of your device, if you want 
>> an external means of protection. Otherwise you’ll need to enable the Windows 
>> Firewall if it’s a Windows system, or setup iptables on Linux, ipfw/pf on 
>> *BSD, etc.
>> 
>> 
>> 
>> Ryan
>> 
>> 
>> 
>> From: JoeSox  
>> Sent: Thursday, February 4, 2021 5:04 PM
>> To: r...@rkhtech.org
>> Cc: TJ Trout ; NANOG 
>> Subject: Re: Suspicious IP reporting
>> 
>> 
>> 
>> How do I setup a firewall when I am not a Verizon engineer?
>> 
>> There is a firewall via the antivirus and operating system but that's it.
>> 
>> Do you not understand my issue? I thought that is the real problem with the 
>> online bullies in this thread.
>> 
>> --
>> 
>> Thank You,
>> 
>> Joe
>> 
>> 
>> 
>> 
>> 
>> On Thu, Feb 4, 2021 at 5:01 PM Ryan Hamel  wrote:
>> 
>> Joe,
>> 
>> 
>> 
>> The underlying premise here is, “pick your battles”. If you don’t want an IP 
>> address to access your device in anyway, setup a firewall and properly 
>> configure it to accept whitelisted traffic only, or just expose a VPN 
>> endpoint. The Internet is full of both good and bad actors that probe and 
>> scan anything and everything.
>> 
>> 
>> 
>> While some appreciate the notification here, others will find it annoying. 
>> We cannot report

Re: Suspicious IP reporting

[J. Hellenthal via NANOG]

 LOL
> 
> I think if everyone gets off their high horse, the list communication would 
> be less noisy for the list veterans.
> 
> --
> 
> Thank You,
> 
> Joe
> 
>  
> 
>  
> 
> On Thu, Feb 4, 2021 at 4:36 PM TJ Trout  wrote:
> 
> This seems like a highly suspect request coming from a North American network 
> operator...? 
> 
>  
> 
>  
> 
> On Thu, Feb 4, 2021 at 10:23 AM JoeSox  wrote:
> 
>  
> 
> This IP is hitting devices on cellular networks for the past day or so.
> 
>   https://www.abuseipdb.com/whois/79.124.62.86  
> 
> I think this is the info to report it to the ISP.  Any help or if everyone 
> can report it, I would be a happy camper.
> 
>  
> 
> ab...@4cloud.mobi; ab...@fiberinternet.bg
> 
>  
> 
> https://en.asytech.cn/check-ip/79.124.62.25#gsc.tab=0
> 
>  
> 
> --
> 
> Thank You,
> 
> Joe
> 


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Nice work Ron

[J. Hellenthal via NANOG]

Cool nice work Ron! Maybe a new subject for what this is really about  ...

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 24, 2021, at 13:36, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> Again, I'm not saying is the best way, is what the community *decided* 
> before I added a clarification. The 50% was not a change, just to make it 
> explicit, what was the actual interpretation.
> 
> If you don't like it, stop complaining, and send a policy proposal, I could 
> even support it, but I'm not convinced it will reach consensus.
> 
> 
> 
> El 24/1/21 15:34, "NANOG en nombre de Masataka Ohta" 
>  mo...@necom830.hpcl.titech.ac.jp> escribió:
> 
>JORDI PALET MARTINEZ via NANOG wrote:
> 
>> I fully understand what you mean, however, I don’t think this is a
>> problem even if all the RIRs ask for “%50 or even 100%” of usage in
>> the region.
> 
>So, you don't know how most, if not all, ISPs are operating
>their network.
> 
>> That will make your life more complex, as you will need to obtain
> 
>It makes ISP's operations a lot more complex and a lot less
>profitable to be ignored by almost all, if not all, ISPs.
> 
>Your theory that ISPs could have behaved otherwise is not
>helpful in the real world of business and not practically
>acceptable by RIRs mostly consisting of ISPs.
> 
>Masataka Ohta
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
> 
> 
> 

Re: DoD IP Space

[j k]

Organizations I have worked with for IPv6 transition, reduced CAPex and
OPex by leveraging the IT refresh cycle, and by ensuring there investment
included leveraging the USGv6 (
https://www.nist.gov/programs-projects/usgv6-program) or IPv6Ready (
https://www.ipv6ready.org/) to mitigate the "We sell IPv6 products, and
want to you to pay for the debugging costs".

Can I assume other organizations don't leverage the IT refresh cycle?

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Thu, Jan 21, 2021 at 2:34 PM Brandon Svec 
wrote:

> That's a good one.  Perhaps you don't live/work in the US and can be
> excused for not knowing that US corporations don't pay taxes.  In many
> cases we subsidize them by giving tax credits to the point that the money
> is flowing in the opposite direction entirely. It would be hard to give
> them any more of a break ;)
>
>>
>>
>> Financial incentives also work. Perhaps we can convince Mr. Biden to give
>> a .5%
>> tax cut to corporations that fully implement v6. That will create some
>> bonus
>> targets.
>>
>> Thanks,
>>
>> Sabri
>>
>

Re: DoD IP Space

[j k]

My question becomes, what level of risk are these companies taking on by
using the DoD ranges on their internal networks? And have they
quantified the costs of this outage against moving to IPv6?

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Wed, Jan 20, 2021 at 9:06 AM John Curran  wrote:

> Indeed.
> /John
>
> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
> >
> > But if you do this, make sure you keep track of where you might have put
> policies like this in, in case the DoD sells some the space or whatever in
> the future.
>
>

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[Javier J]

Sounds like someone has more time to talk/type about political dogma with
random strangers than the purpose of this mailing list.

- J

On Tue, Jan 19, 2021 at 6:58 AM J. Hellenthal 
wrote:

> Yeah he did the same dolt act to me to. Just a really bored dolt looking
> for nonsense with a crush on AOC.
>
> --
>  J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says
> a lot about anticipated traffic volume.
>
> On Jan 19, 2021, at 00:40, Javier J  wrote:
>
> 
> you too, why are you emailing me?
>
> I didn't ask anyone to contact me off list.
>
> On Mon, Jan 18, 2021 at 8:53 PM Sam Silvester 
> wrote:
>
>> Archives are browsable by anybody. How do you expect to keep political
>> types out of the discussion?
>>
>> On Tue, 19 Jan 2021 at 11:36 am, Javier J 
>> wrote:
>>
>>> I couldn't agree more.
>>> If I want to talk politics, I will go to other places. I use this
>>> mailing list to talk about things relevant to technology and operation of
>>> networks in North American and other places.
>>>
>>> - Javier
>>>
>>>
>>> On Mon, Jan 18, 2021 at 4:19 PM Mel Beckman  wrote:
>>>
>>>> javier,
>>>>
>>>> I concur. What we don’t need on Nanog is outside parties deciding to
>>>> “reign in” our discussions on political grounds!
>>>>
>>>>  -mel beckman
>>>>
>>>> On Jan 18, 2021, at 12:38 PM, Javier J 
>>>> wrote:
>>>>
>>>> 
>>>> I agree 100%.
>>>>
>>>> I know the emails on this list are public and that is fine.  What I
>>>> don't appreciate is that now my email address is in some politico's address
>>>> list because of someone's behavior.
>>>>
>>>> - Javier
>>>>
>>>> On Mon, Jan 18, 2021 at 3:20 PM Jon Lewis  wrote:
>>>>
>>>>> There's a world of difference between "don't expect list posts to be
>>>>> private to list members" and "don't forward the list to
>>>>> autoresponders."
>>>>> The stupidity of the latter, if it can be tracked down to who did it,
>>>>> should result in their removal from the list, at least until they
>>>>> explain
>>>>> what caused them to do that and have undone it.
>>>>>
>>>>> On Mon, 18 Jan 2021, Paul Timmins wrote:
>>>>>
>>>>> > The list has public archives. Draw your own conclusions on the
>>>>> policy.
>>>>> >
>>>>> > https://mailman.nanog.org/pipermail/nanog/
>>>>> >
>>>>> > On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
>>>>> >>  Not under that impression at all. That's very different from "what
>>>>> is the
>>>>> >>  policy" - at least in the groups I run, if the policy is "no
>>>>> sharing
>>>>> >>  offlist" and then someone does, there are consequences for that
>>>>> someone.
>>>>> >>  Anne
>>>>> >>
>>>>> >>  --
>>>>> >>  Anne P. Mitchell,  Attorney at Law
>>>>> >>  Dean of Cyberlaw & Cybersecurity, Lincoln Law School
>>>>> >>  Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal
>>>>> anti-spam law)
>>>>> >>  Board of Directors, Denver Internet Exchange
>>>>> >>  Chair Emeritus, Asilomar Microcomputer Workshop
>>>>> >>  Former Counsel: Mail Abuse Prevention System (MAPS)
>>>>> >>
>>>>> >
>>>>>
>>>>> --
>>>>>   Jon Lewis, MCP :)   |  I route
>>>>>   StackPath, Sr. Neteng   |  therefore you are
>>>>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>>>>>
>>>>

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[J. Hellenthal via NANOG]

Yeah he did the same dolt act to me to. Just a really bored dolt looking for 
nonsense with a crush on AOC.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 19, 2021, at 00:40, Javier J  wrote:
> 
> 
> you too, why are you emailing me?
> 
> I didn't ask anyone to contact me off list.
> 
>> On Mon, Jan 18, 2021 at 8:53 PM Sam Silvester  
>> wrote:
>> Archives are browsable by anybody. How do you expect to keep political types 
>> out of the discussion?
>> 
>>> On Tue, 19 Jan 2021 at 11:36 am, Javier J  
>>> wrote:
>>> I couldn't agree more.
>>> If I want to talk politics, I will go to other places. I use this mailing 
>>> list to talk about things relevant to technology and operation of networks 
>>> in North American and other places.
>>> 
>>> - Javier
>>> 
>>> 
>>>> On Mon, Jan 18, 2021 at 4:19 PM Mel Beckman  wrote:
>>>> javier,
>>>> 
>>>> I concur. What we don’t need on Nanog is outside parties deciding to 
>>>> “reign in” our discussions on political grounds!
>>>> 
>>>>  -mel beckman
>>>> 
>>>>> On Jan 18, 2021, at 12:38 PM, Javier J  wrote:
>>>>> 
>>>>> 
>>>>> I agree 100%.
>>>>> 
>>>>> I know the emails on this list are public and that is fine.  What I don't 
>>>>> appreciate is that now my email address is in some politico's address 
>>>>> list because of someone's behavior.
>>>>> 
>>>>> - Javier
>>>>> 
>>>>>> On Mon, Jan 18, 2021 at 3:20 PM Jon Lewis  wrote:
>>>>>> There's a world of difference between "don't expect list posts to be 
>>>>>> private to list members" and "don't forward the list to autoresponders."
>>>>>> The stupidity of the latter, if it can be tracked down to who did it, 
>>>>>> should result in their removal from the list, at least until they 
>>>>>> explain 
>>>>>> what caused them to do that and have undone it.
>>>>>> 
>>>>>> On Mon, 18 Jan 2021, Paul Timmins wrote:
>>>>>> 
>>>>>> > The list has public archives. Draw your own conclusions on the policy.
>>>>>> >
>>>>>> > https://mailman.nanog.org/pipermail/nanog/
>>>>>> >
>>>>>> > On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
>>>>>> >>  Not under that impression at all. That's very different from "what 
>>>>>> >> is the
>>>>>> >>  policy" - at least in the groups I run, if the policy is "no sharing
>>>>>> >>  offlist" and then someone does, there are consequences for that 
>>>>>> >> someone.
>>>>>> >>  Anne
>>>>>> >>
>>>>>> >>  --
>>>>>> >>  Anne P. Mitchell,  Attorney at Law
>>>>>> >>  Dean of Cyberlaw & Cybersecurity, Lincoln Law School
>>>>>> >>  Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam 
>>>>>> >> law)
>>>>>> >>  Board of Directors, Denver Internet Exchange
>>>>>> >>  Chair Emeritus, Asilomar Microcomputer Workshop
>>>>>> >>  Former Counsel: Mail Abuse Prevention System (MAPS)
>>>>>> >> 
>>>>>> >
>>>>>> 
>>>>>> --
>>>>>>   Jon Lewis, MCP :)   |  I route
>>>>>>   StackPath, Sr. Neteng   |  therefore you are
>>>>>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[Javier J]

you too, why are you emailing me?

I didn't ask anyone to contact me off list.

On Mon, Jan 18, 2021 at 8:53 PM Sam Silvester 
wrote:

> Archives are browsable by anybody. How do you expect to keep political
> types out of the discussion?
>
> On Tue, 19 Jan 2021 at 11:36 am, Javier J 
> wrote:
>
>> I couldn't agree more.
>> If I want to talk politics, I will go to other places. I use this mailing
>> list to talk about things relevant to technology and operation of networks
>> in North American and other places.
>>
>> - Javier
>>
>>
>> On Mon, Jan 18, 2021 at 4:19 PM Mel Beckman  wrote:
>>
>>> javier,
>>>
>>> I concur. What we don’t need on Nanog is outside parties deciding to
>>> “reign in” our discussions on political grounds!
>>>
>>>  -mel beckman
>>>
>>> On Jan 18, 2021, at 12:38 PM, Javier J 
>>> wrote:
>>>
>>> 
>>> I agree 100%.
>>>
>>> I know the emails on this list are public and that is fine.  What I
>>> don't appreciate is that now my email address is in some politico's address
>>> list because of someone's behavior.
>>>
>>> - Javier
>>>
>>> On Mon, Jan 18, 2021 at 3:20 PM Jon Lewis  wrote:
>>>
>>>> There's a world of difference between "don't expect list posts to be
>>>> private to list members" and "don't forward the list to autoresponders."
>>>> The stupidity of the latter, if it can be tracked down to who did it,
>>>> should result in their removal from the list, at least until they
>>>> explain
>>>> what caused them to do that and have undone it.
>>>>
>>>> On Mon, 18 Jan 2021, Paul Timmins wrote:
>>>>
>>>> > The list has public archives. Draw your own conclusions on the policy.
>>>> >
>>>> > https://mailman.nanog.org/pipermail/nanog/
>>>> >
>>>> > On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
>>>> >>  Not under that impression at all. That's very different from "what
>>>> is the
>>>> >>  policy" - at least in the groups I run, if the policy is "no sharing
>>>> >>  offlist" and then someone does, there are consequences for that
>>>> someone.
>>>> >>  Anne
>>>> >>
>>>> >>  --
>>>> >>  Anne P. Mitchell,  Attorney at Law
>>>> >>  Dean of Cyberlaw & Cybersecurity, Lincoln Law School
>>>> >>  Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal
>>>> anti-spam law)
>>>> >>  Board of Directors, Denver Internet Exchange
>>>> >>  Chair Emeritus, Asilomar Microcomputer Workshop
>>>> >>  Former Counsel: Mail Abuse Prevention System (MAPS)
>>>> >>
>>>> >
>>>>
>>>> --
>>>>   Jon Lewis, MCP :)   |  I route
>>>>   StackPath, Sr. Neteng   |  therefore you are
>>>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>>>>
>>>

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[Javier J]

Why are you emailing me?

On Mon, Jan 18, 2021 at 3:54 PM Jeff P  wrote:

> SEE!?!
>
> With no evidence yet publicly acknowledged as to who added the AOC email
> to the list now they are just accusing some random "A woman!"
>
> Words (The Pen) are mightier than any brute force (The Sword).
>
> And you did it without thought, just piled on. It came as natural to you
> as putting on your shoes in the morning.
>
> JeffP
> je...@jeffp.us
>
>
>
> *Please consider the environment before printing this e-mail.*
>
> NOTICE:
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> Use or dissemination by persons other than the intended recipient(s) is
> strictly prohibited. If you have received this message in error, please
> notify the sender immediately by reply e-mail to correct our records.
> Please then delete the original message (including any attachments) in its
> entirety, including any backup processes that your system may perform.
> Please note that any views or opinions presented in this email are solely
> those of the author. Email transmission cannot be guaranteed to be secure
> or error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender,
> therefore, does not accept liability for any errors or omissions in the
> contents of this message, which arise as a result of e-mail transmission.
>
>
>
>
> -- Forwarded message -
> From: Lorell Hathcock 
> Date: Mon, Jan 18, 2021 at 12:43 PM
> Subject: Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is
> the policy about sharing email offlist?
> To: Javier J 
> Cc: nanog 
>
>
> A-woman!
>
> Sincerely,
>
> Lorell Hathcock
>
> On Jan 18, 2021, at 1:36 PM, Javier J  wrote:
>
> 
> I agree 100%.
>
> I know the emails on this list are public and that is fine.  What I don't
> appreciate is that now my email address is in some politico's address list
> because of someone's behavior.
>
> - Javier
>
> On Mon, Jan 18, 2021 at 3:20 PM Jon Lewis  wrote:
>
>> There's a world of difference between "don't expect list posts to be
>> private to list members" and "don't forward the list to autoresponders."
>> The stupidity of the latter, if it can be tracked down to who did it,
>> should result in their removal from the list, at least until they explain
>> what caused them to do that and have undone it.
>>
>> On Mon, 18 Jan 2021, Paul Timmins wrote:
>>
>> > The list has public archives. Draw your own conclusions on the policy.
>> >
>> > https://mailman.nanog.org/pipermail/nanog/
>> >
>> > On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
>> >>  Not under that impression at all. That's very different from "what is
>> the
>> >>  policy" - at least in the groups I run, if the policy is "no sharing
>> >>  offlist" and then someone does, there are consequences for that
>> someone.
>> >>  Anne
>> >>
>> >>  --
>> >>  Anne P. Mitchell,  Attorney at Law
>> >>  Dean of Cyberlaw & Cybersecurity, Lincoln Law School
>> >>  Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam
>> law)
>> >>  Board of Directors, Denver Internet Exchange
>> >>  Chair Emeritus, Asilomar Microcomputer Workshop
>> >>  Former Counsel: Mail Abuse Prevention System (MAPS)
>> >>
>> >
>>
>> --
>>   Jon Lewis, MCP :)   |  I route
>>   StackPath, Sr. Neteng   |  therefore you are
>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>>
>

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[Javier J]

I couldn't agree more.
If I want to talk politics, I will go to other places. I use this mailing
list to talk about things relevant to technology and operation of networks
in North American and other places.

- Javier


On Mon, Jan 18, 2021 at 4:19 PM Mel Beckman  wrote:

> javier,
>
> I concur. What we don’t need on Nanog is outside parties deciding to
> “reign in” our discussions on political grounds!
>
>  -mel beckman
>
> On Jan 18, 2021, at 12:38 PM, Javier J  wrote:
>
> 
> I agree 100%.
>
> I know the emails on this list are public and that is fine.  What I don't
> appreciate is that now my email address is in some politico's address list
> because of someone's behavior.
>
> - Javier
>
> On Mon, Jan 18, 2021 at 3:20 PM Jon Lewis  wrote:
>
>> There's a world of difference between "don't expect list posts to be
>> private to list members" and "don't forward the list to autoresponders."
>> The stupidity of the latter, if it can be tracked down to who did it,
>> should result in their removal from the list, at least until they explain
>> what caused them to do that and have undone it.
>>
>> On Mon, 18 Jan 2021, Paul Timmins wrote:
>>
>> > The list has public archives. Draw your own conclusions on the policy.
>> >
>> > https://mailman.nanog.org/pipermail/nanog/
>> >
>> > On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
>> >>  Not under that impression at all. That's very different from "what is
>> the
>> >>  policy" - at least in the groups I run, if the policy is "no sharing
>> >>  offlist" and then someone does, there are consequences for that
>> someone.
>> >>  Anne
>> >>
>> >>  --
>> >>  Anne P. Mitchell,  Attorney at Law
>> >>  Dean of Cyberlaw & Cybersecurity, Lincoln Law School
>> >>  Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam
>> law)
>> >>  Board of Directors, Denver Internet Exchange
>> >>  Chair Emeritus, Asilomar Microcomputer Workshop
>> >>  Former Counsel: Mail Abuse Prevention System (MAPS)
>> >>
>> >
>>
>> --
>>   Jon Lewis, MCP :)   |  I route
>>   StackPath, Sr. Neteng   |  therefore you are
>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>>
>

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[Javier J]

I agree 100%.

I know the emails on this list are public and that is fine.  What I don't
appreciate is that now my email address is in some politico's address list
because of someone's behavior.

- Javier

On Mon, Jan 18, 2021 at 3:20 PM Jon Lewis  wrote:

> There's a world of difference between "don't expect list posts to be
> private to list members" and "don't forward the list to autoresponders."
> The stupidity of the latter, if it can be tracked down to who did it,
> should result in their removal from the list, at least until they explain
> what caused them to do that and have undone it.
>
> On Mon, 18 Jan 2021, Paul Timmins wrote:
>
> > The list has public archives. Draw your own conclusions on the policy.
> >
> > https://mailman.nanog.org/pipermail/nanog/
> >
> > On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
> >>  Not under that impression at all. That's very different from "what is
> the
> >>  policy" - at least in the groups I run, if the policy is "no sharing
> >>  offlist" and then someone does, there are consequences for that
> someone.
> >>  Anne
> >>
> >>  --
> >>  Anne P. Mitchell,  Attorney at Law
> >>  Dean of Cyberlaw & Cybersecurity, Lincoln Law School
> >>  Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam
> law)
> >>  Board of Directors, Denver Internet Exchange
> >>  Chair Emeritus, Asilomar Microcomputer Workshop
> >>  Former Counsel: Mail Abuse Prevention System (MAPS)
> >>
> >
>
> --
>   Jon Lewis, MCP :)   |  I route
>   StackPath, Sr. Neteng   |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>

Re: Nashville

[Javier J]

I heard she knows how to mix drinks, but that's as far as in depth I go
into politics.

On Sun, Jan 17, 2021 at 4:11 PM J. Hellenthal 
wrote:

> That’s funny... sure you don’t want to watch her do some home decorating
> or house projects like fixing the sink ? ;-)
>
> --
>  J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says
> a lot about anticipated traffic volume.
>
> On Jan 17, 2021, at 14:06, Javier J  wrote:
>
> 
> WTF is this? Responding to a thread on NANOG is now emailing politicians?
>
> -- Forwarded message -
> From: 
> Date: Sun, Jan 17, 2021 at 1:31 PM
> Subject: Re: Re: Nashville
> To: Javier J 
>
>
> Hi there,
>
> Thanks very much for your message, and for reaching out to the campaign
> office of Representative Ocasio-Cortez!
>
>- *For press inquiries*, please reach out to our Press Secretary, Ivet
>Contreras, at i...@ocasiocortez.com. We also recommend following
>Alexandria on Twitter <https://twitter.com/AOC> for direct quotes and
>real-time updates. Sign up for our press advisory list here
><http://eepurl.com/hblQ5r>.
>
>
>- *If you are a resident of New York's 14th Congressional District and
>are reaching out for assistance, *please contact Alexandria's
>congressional team directly by visiting
>https://ocasio-cortez.house.gov/contact.
>
>
>- *If you are reaching out to request a meeting or invite Alexandria
>to an event*, please visit
>https://ocasio-cortez.house.gov/scheduling-request and submit a
>Scheduling Request for review by Alexandria's congressional schedulers.
>
>
>- *If your inquiry is not press-related*, please email
>u...@ocasiocortez.com.
>
>
> Thank you again for reaching out, and we hope to be able to connect with
> you soon!
>
>

Re: Nashville

[J. Hellenthal via NANOG]

That’s funny... sure you don’t want to watch her do some home decorating or 
house projects like fixing the sink ? ;-)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 17, 2021, at 14:06, Javier J  wrote:
> 
> 
> WTF is this? Responding to a thread on NANOG is now emailing politicians?
> 
> -- Forwarded message -
> From: 
> Date: Sun, Jan 17, 2021 at 1:31 PM
> Subject: Re: Re: Nashville
> To: Javier J 
> 
> 
> Hi there,
> 
> Thanks very much for your message, and for reaching out to the campaign 
> office of Representative Ocasio-Cortez!  
> For press inquiries, please reach out to our Press Secretary, Ivet Contreras, 
> at i...@ocasiocortez.com. We also recommend following Alexandria on Twitter 
> for direct quotes and real-time updates. Sign up for our press advisory list 
> here.
> If you are a resident of New York's 14th Congressional District and are 
> reaching out for assistance, please contact Alexandria's congressional team 
> directly by visiting https://ocasio-cortez.house.gov/contact.
> If you are reaching out to request a meeting or invite Alexandria to an 
> event, please visit https://ocasio-cortez.house.gov/scheduling-request and 
> submit a Scheduling Request for review by Alexandria's congressional 
> schedulers. 
> If your inquiry is not press-related, please email u...@ocasiocortez.com.
> 
> Thank you again for reaching out, and we hope to be able to connect with you 
> soon!

Fwd: Re: Nashville

[Javier J]

WTF is this? Responding to a thread on NANOG is now emailing politicians?

-- Forwarded message -
From: 
Date: Sun, Jan 17, 2021 at 1:31 PM
Subject: Re: Re: Nashville
To: Javier J 


Hi there,

Thanks very much for your message, and for reaching out to the campaign
office of Representative Ocasio-Cortez!

   - *For press inquiries*, please reach out to our Press Secretary, Ivet
   Contreras, at i...@ocasiocortez.com. We also recommend following
   Alexandria on Twitter <https://twitter.com/AOC> for direct quotes and
   real-time updates. Sign up for our press advisory list here
   <http://eepurl.com/hblQ5r>.


   - *If you are a resident of New York's 14th Congressional District and
   are reaching out for assistance, *please contact Alexandria's
   congressional team directly by visiting
   https://ocasio-cortez.house.gov/contact.


   - *If you are reaching out to request a meeting or invite Alexandria to
   an event*, please visit
   https://ocasio-cortez.house.gov/scheduling-request and submit a
   Scheduling Request for review by Alexandria's congressional schedulers.


   - *If your inquiry is not press-related*, please email
   u...@ocasiocortez.com.


Thank you again for reaching out, and we hope to be able to connect with
you soon!

Re: opportunistic email encryption by the MTA (not MUA)

[Brian J. Murrell]

On Fri, 2021-01-15 at 10:26 -0500, Bryan Fields wrote:
> 
> It's still stored unencrypted on the server, and the admin can see
> all.

This is true.  I was just referring to transit leakage.

> If
> you want it secure, you have to run gpg and encrypt the body.

Again, true.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: opportunistic email encryption by the MTA (not MUA)

[Brian J. Murrell]

On Fri, 2021-01-15 at 03:33 -0800, Randy Bush wrote:
> email from a friend who uses protonmail as their MTA suddenly started
> to
> be opportunistically encrypted with pgp; i.e. the sender's MUA did
> nothing to cause the encryption.  i believe this started when i
> provided
> my pgp public key over WKD [0].

Interesting.  When I read the subject though, I have to admit that I
was hoping your e-mail was going to be about REQUIRETLS/RFC8689.

It's a real pity that there appears to be no real-world
use/implementation of RFC8689.

I think in practice the old adage that "e-mail is insecure" is becoming
untrue, by a significant amount, I suspect, due to the prevalence of
STARTTLS.

The problem with STARTTLS of course is that it is opportunistic only
and with no way for the sender to indicate that a message MUST use TLS
or not be delivered at all.

I routinely send things by e-mail that, while they are not the
combination to the big safe at Fort Knox, they are not something I
would staple to utility poles.

When doing such I will typically look up the MXes for the recipient and
test their SMTP port for STARTTLS to see if the mail will at least ride
the wires with TLS.

It would be so much easier to have a checkbox in my MUA to do this
though.  :-)

All of that said, thanks for the pointer to WKD.  I didn't know about
that.

Use of it at the MTA level is interesting.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: Looking for hosted SMTP service for small ISP

[J. Hellenthal via NANOG]

Check out sendgrid.net

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 14, 2021, at 12:59, chiel  wrote:
> 
> Hello,
> 
> We are a small ISP. Most of our customers have a hosted e-mail service
> (gmail/office365/etc..) and have their own outgoing email sorted.
> 
> But a handful of customers rely on our SMTP server for outgoing e-mail.
> Currently we host this our self with a physical box. But I would like to
> have a hosted solution so that I don't have to worry about keeping up
> with updates and latest spam techniques.
> 
> Preferred I'm looking to make a DNS name like smtp.example.com and point
> this to a hosted solution. This excepts any email from our IP ranges.
> All controlled with a nice dashboard.
> 
> I was in contact with Solarwinds (Mail Assure) but they don't seem to be
> able to help.
> 
> Chiel

Re: Nashville

[Javier J]

I wouldn't say bad design, I would say outdated design. How do you take a
single fiber optic cable or a copper cable bundle going to a
business/building or a house and terminate it at 2 different Central
Offices? It inherently has a single points of failure. (why I added extra
straps to my fiber outside at home because stupid wind blows the damn cable
around that goes to the pole, I'm in NJ everything on poles here)

I don't think a bomb going off was part of the redundancy design process
when telephone central offices were first starting to be built.
I heard the rumour is (perhaps fact) the generators were keeping everything
up till about 12-1 PM eastern when they shut the gas supply off to the
neighborhood earlier safety. Once the batteries drained, that was it.

Family I have in Nashville were on the phone when it cut out and then
everything went dark.

I do think they could have done a better job with the wireless infra.

No reason you can't have some cell sites that can feed to a different
central office.

The fact is, distributed systems could work better, many smaller switching
and distribution buildings scattered about a metro area with redundant
links. A mesh. That was the single point of failure is just the link from
your house to the next hop. Obviously not feasible with copper pairs.

- Javier



On Thu, Jan 14, 2021 at 10:05 AM Hiers, David  wrote:

> No doubt they’re good, but the best support can’t overcome bad design.
>
>
>
>
>
>
>
> *From:* NANOG  *On Behalf Of
> *Robert DeVita
> *Sent:* Tuesday, December 29, 2020 5:17 PM
> *To:* Eric Kuhnke ; Sean Donelan 
> *Cc:* NANOG 
> *Subject:* Re: Nashville
>
>
>
> AT Disaster Recovery Team is probably the best in the business. The
> resources they can bring to the table are unmatched. This would have been
> 100x worse if it hit a carrier neutral datacenter. They don’t have nearly
> the same resources to restore something like this. They usually do a road
> show (pre Covid). If you get a chance it’s definitely something you should
> go check out. Very impressive.
>
>
>
> Robert DeVita
>
> Founder & CEO
>
> Mejeticks
>
> c. 469-441-8864
>
> e. radev...@mejeticks.com
> --
>
> *From:* NANOG  on behalf
> of Eric Kuhnke 
> *Sent:* Tuesday, December 29, 2020 5:06:00 PM
> *To:* Sean Donelan 
> *Cc:* NANOG 
> *Subject:* Re: Nashville
>
>
>
> From a few days ago. Obviously centralizing lots of ss7/pstn stuff all in
> one place has a long recovery time when it's physically damaged. Something
> to think about for entities that own and operate traditional telco COs and
> their plans for disaster recovery.
>
>
>
>
>
> Nv1
>
>
>
> Here is the latest update:  6:46AM 12/27:
>
>
>
> Work continues restoring service to the CRS routers in the Nashville
> Central Office. One router remains out of service and the other is in
> service with some links remaining out of service.
>
>
>
> The working bridge will reconvene at 08:00 CT with the following action
> plan:
>
> Additional cabling added to the first portable generator to enable full
> load capabilities (08:00 CT)
>
> Pigtails with camlocks installed for easy swap; investigate possibility to
> land generator on the emergency service board to give the site N+1 with a
> manual ability to choose anyone. (08:00 CT)
>
> check small power plants on floors 4 and 6 (08:00 CT)
>
> Investigate water damage on 1st floor and energize if safe (08:00 CT
>
> Air handlers for floors 4,5 and 6 (09:00 CT)
>
> complete all transport work
>
> Turn up SS7
>
> Turn up 911 service - Approximately noon or after)
>
> Turn up switching service.
>
> TDM Switching team will reconvene at 09:00 CT and the Signaling team will
> reconvene at 11:00 CT on 12/27/2020.
>
> DMS equipment on the 1st floor will be assessed for water damage.
> Switching teams will monitor power and HVAC restoration and will begin
> switch restoration as soon as the go ahead is provided by the power team.
>
>
>
> Recovery Priorities:
>
> 1. 4th & 5th floors (Specify transport equipment needed to clear MTSO SS7
> isolation & Datakit needed for Local Switch restoration). Transport SMEs
> currently working to turn up transport equipment
>
> 2. 6th floor (ESINET Groomers)
>
> 3. 10th and 8th floors (N4E) – Trunks
>
> 4. 1st floor (DMS: DS1, 5E: DS3) - Local POTS
>
> 5. 1st floor (DMS: DS0, DS2 | 5E: DS6) – Trunks
>
> 6. 11th floor (DMS: 01T) – Trunks
>
> 7. 4th floor (STP and SCP with mates up in Donelson)
>
>
>
> The next update will be issued at approximately 09:00 CT on December 27.
>
>
>
>
>
>
>
> Nv2
>
>
>
> As of 09:00 CT: Teams worked through the night to restore service and
> improve conditions at the Nashville 2nd Ave Central Office. Since the
> initial service impact, over 75% of the Out of Service Mobility Sites have
> been restored. Certain call flows may be limited and should improve as
> additional restoration activities complete.
>
> The generator that is currently powering equipment on the 2nd and 3rd
> floor, was refueled and ran 

Re: DoNotPay Spam?

[J. Hellenthal via NANOG]

Any chance the HTML can be turned off ? 

;-)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jan 13, 2021, at 19:18, Mel Beckman  wrote:
> 
>  Tons, and we are litigating them. They are spamming most of the addresses 
> in several of our domains. 
> 
> -mel via cell
> 
>>> On Jan 13, 2021, at 2:18 PM, Mike Hammett  wrote:
>>> 
>> 
>> I have reached out to the list admins and the donotpay people and they're 
>> working on it.
>> 
>> In short, someone that uses that service reported the NANOG list as SPAM to 
>> the DoNotPay service.
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>> 
>> From: "Robert Webb" 
>> To: "NANOG list" 
>> Sent: Wednesday, January 13, 2021 4:06:15 PM
>> Subject: DoNotPay Spam?
>> 
>> Anyone else getting spam from DoNotPay everytime they send an email to the 
>> list?
>> 
>> I have not sent anything in a while until my ATT email and now I am getting 
>> this on every new email I send to the list.
>> 
>> 
>> 
>> You’re almost there! Sign up once to unlock lifetime protection (and even 
>> compensation) on all spam emails.
>> 

Re: Nashville

[Javier J]

Is there a video of this? I would also love to see pictures of what the
damage was inside the building and repairs. Not sure if that was documented
anywhere. I would assume they are still doing repairs and upgrades to the
facility.

On Tue, Dec 29, 2020 at 8:18 PM Robert DeVita 
wrote:

> AT Disaster Recovery Team is probably the best in the business. The
> resources they can bring to the table are unmatched. This would have been
> 100x worse if it hit a carrier neutral datacenter. They don’t have nearly
> the same resources to restore something like this. They usually do a road
> show (pre Covid). If you get a chance it’s definitely something you should
> go check out. Very impressive.
>
> Robert DeVita
> Founder & CEO
> Mejeticks
> c. 469-441-8864
> e. radev...@mejeticks.com
> --
> *From:* NANOG  on behalf
> of Eric Kuhnke 
> *Sent:* Tuesday, December 29, 2020 5:06:00 PM
> *To:* Sean Donelan 
> *Cc:* NANOG 
> *Subject:* Re: Nashville
>
> From a few days ago. Obviously centralizing lots of ss7/pstn stuff all in
> one place has a long recovery time when it's physically damaged. Something
> to think about for entities that own and operate traditional telco COs and
> their plans for disaster recovery.
>
>
> Nv1
>
> Here is the latest update:  6:46AM 12/27:
>
> Work continues restoring service to the CRS routers in the Nashville
> Central Office. One router remains out of service and the other is in
> service with some links remaining out of service.
>
> The working bridge will reconvene at 08:00 CT with the following action
> plan:
> Additional cabling added to the first portable generator to enable full
> load capabilities (08:00 CT)
> Pigtails with camlocks installed for easy swap; investigate possibility to
> land generator on the emergency service board to give the site N+1 with a
> manual ability to choose anyone. (08:00 CT)
> check small power plants on floors 4 and 6 (08:00 CT)
> Investigate water damage on 1st floor and energize if safe (08:00 CT
> Air handlers for floors 4,5 and 6 (09:00 CT)
> complete all transport work
> Turn up SS7
> Turn up 911 service - Approximately noon or after)
> Turn up switching service.
> TDM Switching team will reconvene at 09:00 CT and the Signaling team will
> reconvene at 11:00 CT on 12/27/2020.
> DMS equipment on the 1st floor will be assessed for water damage.
> Switching teams will monitor power and HVAC restoration and will begin
> switch restoration as soon as the go ahead is provided by the power team.
>
> Recovery Priorities:
> 1. 4th & 5th floors (Specify transport equipment needed to clear MTSO SS7
> isolation & Datakit needed for Local Switch restoration). Transport SMEs
> currently working to turn up transport equipment
> 2. 6th floor (ESINET Groomers)
> 3. 10th and 8th floors (N4E) – Trunks
> 4. 1st floor (DMS: DS1, 5E: DS3) - Local POTS
> 5. 1st floor (DMS: DS0, DS2 | 5E: DS6) – Trunks
> 6. 11th floor (DMS: 01T) – Trunks
> 7. 4th floor (STP and SCP with mates up in Donelson)
>
> The next update will be issued at approximately 09:00 CT on December 27.
>
>
>
> Nv2
>
> As of 09:00 CT: Teams worked through the night to restore service and
> improve conditions at the Nashville 2nd Ave Central Office. Since the
> initial service impact, over 75% of the Out of Service Mobility Sites have
> been restored. Certain call flows may be limited and should improve as
> additional restoration activities complete.
> The generator that is currently powering equipment on the 2nd and 3rd
> floor, was refueled and ran with no issues through the night. Overnight,
> the batteries connected to it, continued to charge. Teams have placed
> additional power cables, which once connected, will allow the working
> generator, to better handle the load in the building. In order to
> accomplish this, the generator will need to be shut down for 15-30 minutes
> this morning, so teams can connect the new cables to the system. The power
> team reports they are still on target to restore power and cooling to the
> 5th and 6th floor by approximately 12:00 CT. Also, a portable chiller will
> be delivered this morning and strategically placed, in case it is needed to
> assist in cooling the office.
> There is a Call Center at 333 Commerce, in Nashville that does not have
> network or phone services available. Corporate Real Estate (CRE) reports
> there is some damage to that office, but the extent of the damage will not
> be known until they can gain access to the site. Because of this, the
> impacted Call Center ceased operations until further notice.
> DMS switching equipment on the 1st floor will be assessed for water
> damage. Switching teams will monitor power and HVAC restoration. Equipment
> power ups will begin, as soon as the go ahead is provided by the power
> team.
> Two SatCOLTs remain positioned on the East and West sides of the NSVLTNMT
> Central Office providing critical communication for teams working
> restoration efforts. There are 17 assets