Re: Any Zayo clue on the list?

[Ryan Hamel]

Mike,

Do you have the full MTR? Packet loss in the middle of the trace means nothing 
if it is not persistent all the way to the end.

Ryan Hamel


From: NANOG  on behalf of Mike Lyon 

Sent: Wednesday, June 5, 2024 4:56 PM
To: NANOG list 
Subject: Any Zayo clue on the list?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


Have a zayo packet loss issue and your NOC doesn't see anything wrong...

Host Loss% Snt Last Avg Best Wrst StDev 1.
ae15.cs4.sjc4.us.zip.zayo.com 94.3% 142 28.7 28.9 28.0 30.6 0.8 2.
ae8.cs2.sea1.us.zip.zayo.com 27.5% 142 30.8 30.5 27.5 41.6 3.9

Any help would be appreciated. Please ping me off list.

Thank You,
Mike

--
Mike Lyon
mike.l...@gmail.com
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmlyon=05%7C02%7Cryan%40rkhtech.org%7Ca6a10508e6da4f64cbcd08dc85bb689b%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638532287160068907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=4%2FczHZgV7KE6hVea2nFEThVBts%2BRJeEQd8UqzthloEA%3D=0<http://www.linkedin.com/in/mlyon>

Re: N91 Women mixer on Sunday?

[Ryan Hamel]

Paul,

Anne's opinion is just as valid as the others here. I have also browsed through 
the recent attendee lists and do not see you listed either, pot calling the 
kettle black. Your comments about her email signature and which voices are 
valid here, are not productive. We are allowed to back up and/or side with 
whomever we please, even if it includes the NANOG board, staff, and committee 
members. We are also allowed to call people out on their behavior towards 
others.

Anyway, no one truly knows how many people could have raised the scheduling 
issue with various committee members, the board, staff, or provided feedback 
via the contact form on the website, and who knows it could have come from 
young women. Those voices do not have to come from the mailing list, to be just 
as valid as ours.

Ryan Hamel


From: NANOG  on behalf of Paul WALL 

Sent: Friday, March 29, 2024 5:22 PM
To: Anne P. Mitchell, Esq. 
Cc: nanog@nanog.org 
Subject: Re: N91 Women mixer on Sunday?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


Hi, Anne-

I'm sure that your time was better spent gathering the "credentials"
in your signature, but I checked the last 20 or so NANOG meetings and
didn't see a single registration from you, so perhaps stay out of
things you know literally nothing about.

If it weren't for Ilissa, NANOG would not exist in the form that it
does today, and she's done more work on and off the clock driving the
success of the organization and their meetings than she takes credit
for. NANOG, and especially the women that attend NANOG, owe her a
tremendous debt of gratitude. Her opinion, and Tina's response, are
literally the only ones that carry any weight in this thread, period.

--
Drive Slow,

Paul Wall
Rapper, Retired, and Actor
Swishahouse Alum
Author: Get Money, Stay True
Nominated: Best Rap Performance as a Duo or Group
Winner: Best Rap Collaboration
Winner: Best Rap/R Collaboration
Winner: Taste Maker (Style and Trendsetter)
Contributor: Midnight Club 3: DUB Edition for Xbox and PlayStation 2 –
"Sittin' Sidewayz"
Author: The Peoples Champ
Emeritus: Houston University (no degree)


On Thu, Mar 28, 2024 at 3:24 PM Anne P. Mitchell, Esq.
 wrote:
>
>
>
> > I'm not sure people realize how much crap that staff and the PC get *every 
> > meeting* about the agenda. There's always someone unhappy because this 
> > event wasn't the same, or why was it in this room over here, or OMG Wed 
> > afternoon, etc. Having seen how that sausage gets made, they don't get 
> > enough credit.
>
> Having been the chair of the Asilomar Microcomputer workshop, and the founder 
> and chair of the original Email Deliverability Summits, as well as organizing 
> many legal conferences, I have to say "^^^ this, 1000%."
>
> Furthermore:
>
> > On Mar 28, 2024, at 11:45 AM, Ilissa Miller  wrote:
> >
> > For those that know me, I rarely provide constructive input about NANOG 
> > matters
>
> ..and you haven't here, either.  Pointing fingers and griping about things is 
> not constructive.  If you really care about this issue, then get involved and 
> help change it.
>
> Anne
>
> ---
> Anne P. Mitchell, Esq.
> Internet Law & Policy Attorney
> CEO Institute for Social Internet Public Policy (ISIPP)
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing 
> law)
> Board of Directors, Denver Internet Exchange
> Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
> Prof. Emeritus, Lincoln Law School
> Chair Emeritus, Asilomar Microcomputer Workshop
> Counsel Emeritus, eMail Abuse Prevention System (MAPS)
>
>
>
>
>

On Thu, Mar 28, 2024 at 3:24 PM Anne P. Mitchell, Esq.
 wrote:
>
>
>
> > I'm not sure people realize how much crap that staff and the PC get *every 
> > meeting* about the agenda. There's always someone unhappy because this 
> > event wasn't the same, or why was it in this room over here, or OMG Wed 
> > afternoon, etc. Having seen how that sausage gets made, they don't get 
> > enough credit.
>
> Having been the chair of the Asilomar Microcomputer workshop, and the founder 
> and chair of the original Email Deliverability Summits, as well as organizing 
> many legal conferences, I have to say "^^^ this, 1000%."
>
> Furthermore:
>
> > On Mar 28, 2024, at 11:45 AM, Ilissa Miller  wrote:
> >
> > For those that know me, I rarely provide constructive input about NANOG 
> > matters
>
> ..and you haven't here, either.  Pointing fingers and griping about things is 
> not constructive.  If you really care about this issue, then get involved and 
> help change it.
>
> Anne
>
> ---
> Anne P. Mitc

Re: Any info on AT Wireless Outage?

[Ryan Wilkins via NANOG]

No $5 received here.. Just a text message saying, "It's AT We apologize for 
Thursday's outage, which may have impacted you. As a valued customer, your 
connection matters and we are committed to doing better.” 

I had the thought the other day that maybe this was a hack and that they didn’t 
want to admit such.  I’m sure FirstNet being taken over by hackers isn’t 
exactly the message they want out there.  Regardless of what the actual cause 
was, their lack of communicating anything meaningful is saying something which 
boosts the chances that this was a hack in my mind.

Agreed on the human error thing, but maybe the human error was something the 
hackers did that they didn’t mean to.


> On Feb 29, 2024, at 2:55 PM, Javier J  wrote:
> 
> 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  
>>  | 
>> 
>> m: (469) 441-8864 
>> e: radev...@mejeticks.com 
>>  | 
>> 
>> w: mejeticks.com 
>> a: 
>> 
>> 2323 N Akard Street
>> 
>> , 
>> 
>> Dallas
>> 
>> , 
>> 
>> 75201
>> 
>>     
>>   
>>  
>>  
>>  
>> 
>> 
>> 
>> 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: Any info on AT Wireless Outage?

[Ryan A. Krenzischek via NANOG]

The same as well for FirstNet but am now able to make calls.  Others who are on 
AT are unable to receive or send calls.  Enabling wifi calling on a regular 
AT phone (android) results in a 502 bad gateway error message.  

Ryan

> On Feb 22, 2024, at 08:11, Ray Orsini via NANOG  wrote:
> 
> 
> We're affected as well. Unable to dial out. I haven't found any official 
> statement though.
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 uptake (was: The Reg does 240/4)

[Ryan Hamel]

Again Bill, the NAT process layer is not involved in dropping unwanted traffic 
until the packet is at least four/five levels deep. On ingress, a firewall will 
check if there is any flow/stream associated to it, ensure the packet follows 
the applicable protocol state machine, process it against the inbound interface 
rules, do any DPI rule processing, THEN NAT lookup, and egress routing + ACLs 
on the outbound ACL. 
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html

On a standard LAN -> WAN firewall configured with a single public IPv4 IP; your 
protection comes from the connect state/flow tables primarily. No one would be 
touching NAT configurations at the same rate as zone and policy configurations, 
unless it's for complex VPN setups. Using NAT as a defense in depth strategy 
against deploying v6 is only hurting yourself. I have yet to come across an 
enterprise that uses it between internal VLANs or policies/zones, where the 
same threat potential can be, especially in a DMZ.

Ryan Hamel


From: NANOG  on behalf of William 
Herrin 
Sent: Friday, February 16, 2024 8:03 PM
To: John R. Levine 
Cc: nanog@nanog.org 
Subject: Re: IPv6 uptake (was: The Reg does 240/4)

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


On Fri, Feb 16, 2024 at 7:41 PM John R. Levine  wrote:
> > That it's possible to implement network security well without using
> > NAT does not contradict the claim that NAT enhances network security.
>
> I think we're each overgeneralizing from our individual expeience.
>
> You can configure a V6 firewall to be default closed as easily as you can
> configure a NAT.

Hi John,

We're probably not speaking the same language. You're talking about
configuring the function of one layer in a security stack. I'm talking
about adding or removing a layer in a security stack. Address
overloaded NAT in conjunction with private internal addresses is an
additional layer in a security stack. It has security-relevant
properties that the other layers don't duplicate. Regardless of how
you configure it.

Also, you can't "configure" a layer to be default closed. That's a
property of the security layer. It either is or it is not.

You can configure a layer to be "default deny," which I assume is what
you meant. The issue is that anything that can be configured can be
accidentally unconfigured. When default-deny is accidentally
unconfigured, the network becomes wide open. When NAT is accidentally
unconfigured, the network stops functioning entirely. The gate is
closed.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F=05%7C02%7Cryan%40rkhtech.org%7C0de6c54d274c4b231dc608dc2f6dc319%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437395698409506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=k19sefOjlCNOBGbiAmhzcFszrOEhf8SQQfs0MQThyaU%3D=0<https://bill.herrin.us/>

Re: IPv6 uptake (was: The Reg does 240/4)

[Ryan Hamel]

sronan,

A subnet can come from the ISP (residential/small business), or business is 
utilizing BGP with their upstream. When V6 is in use, a firewall does not need 
to perform NAT, just stateful flow inspection and applying the applicable rules 
based on the zone and/or interface.

Bill,

Depending on where that rule is placed within your ACL, yes that can happen 
with *ANY* address family.

---

All things aside, I agree with Dan that NAT was never ever designed to be a 
security tool. It is used because of the scarcity of public address space, and 
it provides a "defense" depending on how it is implemented, with minimal 
effort. This video tells the story of NAT and the Cisco PIX, straight from the 
creators https://youtu.be/GLrfqtf4txw

Ryan Hamel


From: NANOG  on behalf of 
sro...@ronan-online.com 
Sent: Friday, February 16, 2024 5:44 PM
To: William Herrin 
Cc: nanog@nanog.org 
Subject: Re: IPv6 uptake (was: The Reg does 240/4)

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


Why is your Internal v6 subnet advertised to the Internet?

> On Feb 16, 2024, at 8:08 PM, William Herrin  wrote:
>
> On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas  wrote:
>> If you know which subnets need to be NAT'd don't you also know which
>> ones shouldn't exposed to incoming connections (or conversely, which
>> should be permitted)? It seems to me that all you're doing is moving
>> around where that knowledge is stored? Ie, DHCP so it can give it
>> private address rather than at the firewall knowing which subnets not to
>> allow access? Yes, DHCP can be easily configured to make everything
>> private, but DHCP for static reachable addresses is pretty handy too.
>
> Hi Mike,
>
> Suppose I have a firewall at 2602:815:6000::1 with an internal network
> of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
> switch that accepts telnet connections with a user/password of
> admin/admin. On the firewall, I program it to disallow all Internet
> packets to 2602:815:6001::/64 that are not part of an established
> connection.
>
> Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
>
> Now, I make a mistake on my firewall. I insert a rule intended to
> allow packets outbound from 2602:815:6001::4 but I fat-finger it and
> so it allows them inbound to that address instead. Someone tries to
> telnet to 2602:815:6001::4. What happens? Hacked.
>
> Now suppose I have a firewall at 199.33.225.1 with an internal network
> of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch
> that accepts telnet connections with a user/password of admin/admin.
> On the firewall, I program it to do NAT translation from
> 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which
> also has the effect of disallowing inbound packets to 192.168.55.0/24
> which are not part of an established connection.
>
> Someone tries to telnet to 192.168.55.4. What happens? The packet
> never even reaches my firewall because that IP address doesn't go
> anywhere on the Internet.
>
> Now I make a mistake on my firewall. I insert a rule intended to allow
> packets outbound from 192.168.55.4 but I fat-finger it and so it
> allows them inbound to that address instead. Someone tries to telnet
> to 192.168.55.4. What happens? The packet STILL doesn't reach my
> firewall because that IP address doesn't go anywhere on the Internet.
>
> See the difference? Accessible versus accessible and addressable. Not
> addressable enhances security.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F=05%7C02%7Cryan%40rkhtech.org%7C5672986956c34e345fd208dc2f5a571c%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437312255883842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=iuKWxWts%2B9buTCz318C7hz6DbuWSST%2FKPZAWbbhSj8Q%3D=0<https://bill.herrin.us/>

Re: The Reg does 240/4

[Ryan Hamel]

Allocating 240/4 only temporarily drives down pricing until it's all assigned, 
then we're all back at square one. Ya know what does not put us back square 
one, nor waste our time? Implementing IPv6.

Ryan Hamel


From: NANOG  on behalf of Christopher 
Hawker 
Sent: Wednesday, February 14, 2024 4:49 AM
To: David Conrad 
Cc: North American Operators' Group 
Subject: Re: The Reg does 240/4

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi David,

I agree with the fact that introducing this space has the very real risk of it 
being obtained by the highest bidder. Perhaps I may be naive in believing that 
we have a possible chance to delegate this space wisely and prevent it from 
being exhausted at a rather rapid rate, however I can only hope that people 
will see the potential benefit that this could bring, and policy not being 
changed to benefit the larger players in the space.

IP resources were never intended to become a commodity, rather a tool that 
allowed people to globally connect. It should never have become a commodity, 
and it's a shame that it is being treated as such with a price tag put on it.

Regards,
Christopher Hawker

From: David Conrad 
Sent: Wednesday, February 14, 2024 1:03 PM
To: Christopher Hawker 
Cc: North American Operators' Group 
Subject: Re: The Reg does 240/4

Christopher,

On Feb 13, 2024, at 4:14 PM, Christopher Hawker  wrote:
This is a second chance to purposefully ration out a finite resource.

Perhaps I’m overly cynical, but other than more players and _way_ more money, 
the dynamics of [limited resource, unlimited demand] don’t appear to have 
changed significantly from the first time around. However, I suspect the real 
roadblock you’ll face in policy discussions (aside from the folks who make 
their money leasing IPv4 addresses) is the argument that efforts to ration and 
thereby extend the life of IPv4 will continue to distort the market and impede 
the only useful signal to network operators regarding the costs of remaining 
with IPv4 compared to supporting IPv6.  Good luck!

Regards,
-drc

Re: The Reg does 240/4

[Ryan Hamel]

Tim,

How is that Mikrotik a let down?

Ryan


From: NANOG  on behalf of Tim Howe 

Sent: Tuesday, February 13, 2024 12:04:50 PM
To: nanog@nanog.org 
Subject: Re: The Reg does 240/4

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


That's very disappointing.

I acquired a Mikrotik L009 router to play with recently, and it's been one
let-down after another; now this.

--TimH

On Tue, 13 Feb 2024 17:04:45 +0100
Bryan Holloway  wrote:

> Let me know when they support /31s.
>
>
> On 2/13/24 08:07, Dave Taht wrote:
> > And routerOS is one of
> > the more up to date platforms.

Re: NANOG 90 Attendance?

[Ryan Hamel]

Mike,

The numbers have not bounced back to pre-pandemic levels, and it doesn't help 
that NANOG 90 has had some hotel issues.

Ryan


From: NANOG  on behalf of Mike 
Hammett 
Sent: Sunday, February 11, 2024 5:31:02 AM
To: nanog 
Subject: NANOG 90 Attendance?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

I haven't been to a NANOG meeting in a while. While going through the attendee 
list for NANOG 90 to try to book meetings with people, I noticed a lack of (or 
extremely minimal) attendance by several organizations that have traditionally 
had several employees attend. I've also noticed that some organizations I had 
an interest in were only sending sales people, not technical people.

How long has this been a thing? I remember when I attended years ago that there 
simply wasn't enough time to meet with technical people from all of the 
organizations I wanted to meet with. Now the calendar is looking a bit dry.



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

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

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

What you are presenting here is a solution looking for a problem. There are 
multiple solutions available today that do not require your proposed hacks to 
IPv4 space. If your ideas keep getting rejected by the masses, maybe you should 
read the room and lookup the phrase "resistance is futile."

That is the last of my .02c for this thread.

Ryan


From: NANOG  on behalf of Abraham Y. 
Chen via NANOG 
Sent: Sunday, January 21, 2024 9:06:28 AM
To: Chris Adams 
Cc: Chen, Abraham Y. ; NANOG 
Subject: Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address 
block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Chris:

0)Thanks for your observation.

1)Although I specifically requested Karim to go offline on our idea to his 
inquiry, lots of comments appeared on NANOG publicly. To be polite, I tried to 
respond by clarifying and describing each. Unfortunately, many comments are 
actually persistent IPv6 promotions, even my attempt of bringing up the 
community consensus of "Dual-Stack has distinguished IPv6 and IPv4 into 
separate tracks" was in vain.

2)Philosophically, IPv6 and IPv4 are kind of like two religions, each with 
its own believers. As long as the devotees of each focus on their respective 
passion, the world will be peaceful. As soon as one camp imposes its preference 
onto the other, friction starts. Unchecked, it can go even worse. ... But, I 
digressed.

Regards,


Abe (2024-01-21 12:06)


On 2024-01-20 12:50, Chris Adams wrote:

Once upon a time, sro...@ronan-online.com<mailto:sro...@ronan-online.com> 
<mailto:sro...@ronan-online.com> said:


I am curious if anyone has ever given you positive feedback on this idea? So far
all I’ve seen is the entire community thinking it’s a bad idea. Why do you
insist this is a good solution?



Because people keep responding.



[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
  
Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

It has existed for many years, already supported on many devices, does not 
require NAT, address space is plentiful, does not require additional proposals, 
and it accounts for 40% of the traffic at Google.

Ryan


From: Abraham Y. Chen 
Sent: Friday, January 12, 2024 3:45:32 AM
To: Ryan Hamel 
Cc: nanog@nanog.org ; Michael Butler 
; Chen, Abraham Y. 
Subject: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address 
block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Ryan:

1)   " ...  Save yourself the time and effort on this and implement IPv6.":

What is your selling point?


Regards,


Abe (2024-01-12 06:44)




2024-01-11 12:39, Ryan Hamel wrote:
Abraham,

You're arguing semantics instead of the actual point. Residential customers 
want Internet access, not intranet access. Again, VRFs are plentiful and so are 
CG-NAT firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG 
<mailto:nanog-bounces+ryan=rkhtech@nanog.org>
 on behalf of Abraham Y. Chen <mailto:ayc...@avinta.com>
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 
<mailto:i...@protected-networks.net>
Cc: nanog@nanog.org<mailto:nanog@nanog.org> 
<mailto:nanog@nanog.org>
Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block


Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Michael:

1)" ... While you may be able to get packets from point A to B in a private 
setting, using them might also be .. a challenge. ...   ":

EzIP uses 240/4 netblock only within the RAN (Regional Area Network) as 
"Private" address, not "publicly" routable, according to the conventional 
Internet definition. This is actually the same as how 100.64/10 is used within 
CG-NAT.

2)However, this might be where the confusion comes from. With the 
geographical area coverage so much bigger, an RAN is effectively a public 
network. To mesh the two for consistency, we defined everything related to 
240/4 as "Semi-Public" to distinguish this new layer of networking facility 
from the current public / private separation. That is, the CG-NAT routers will 
become SPRs (Semi-Public Routers) in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,


Abe (2024-01-11 12:21)



On 2024-01-10 10:45, Michael Butler via NANOG wrote:
On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able 
to use it on internal networks if your equipment supports it, you cannot use it 
as publicly routable space. There have been many proposals over the years to 
reclassify 240/4, but that has not happened, and is unlikely to at any point in 
the foreseeable future.

While you may be able to get packets from point A to B in a private setting, 
using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions 
about allowable ranges. That is, they've been compiled with a header that 
defines ..

#define IN_BADCLASS(i)(((in_addr_t)(i) & 0xf000) == 0xf000)

Michael



[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
  
Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

You may not need permission from the IETF, but you effectively need it from 
every networking vendor, hardware vendor, and OS vendor. If you do not have buy 
in from key stakeholders, it's dead-on arrival.

Ryan

From: NANOG  on behalf of Abraham Y. 
Chen 
Sent: Thursday, January 11, 2024 6:38:52 PM
To: Vasilenko Eduard 
Cc: Chen, Abraham Y. ; nanog@nanog.org 
Subject: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Vasilenko:

1)... These “multi-national conglo” has enough influence on the IETF to not 
permit it.":

As classified by Vint Cerf, 240/4 enabled EzIP is an overlay network that 
may be deployed stealthily (just like the events reported by the RIPE-LAB). So, 
EzIP deployment does not need permission from the IETF.

Regards,


Abe (2024-01-11 21:38 EST)




On 2024-01-11 01:17, Vasilenko Eduard wrote:

> It has been known that multi-national conglomerates have been using it 
> without announcement.

This is an assurance that 240/4 would never be permitted for Public Internet. 
These “multi-national conglo” has enough influence on the IETF to not permit it.

Ed/

From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Wednesday, January 10, 2024 3:35 PM
To: KARIM MEKKAOUI <mailto:amekka...@mektel.ca>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>; Chen, Abraham Y. 
<mailto:ayc...@alum.mit.edu>
Subject: 202401100645.AYC Re: IPv4 address block
Importance: High



Hi, Karim:



1)If you have control of your own equipment (I presume that your business 
includes IAP - Internet Access Provider, since you are asking to buy IPv4 
blocks.), you can get a large block of reserved IPv4 address for free by 
disabling the program codes in your current facility that has been disabling 
the use of 240/4 netblock. Please have a look at the below whitepaper. Utilized 
according to the outlined disciplines, this is a practically unlimited 
resources. It has been known that multi-national conglomerates have been using 
it without announcement. So, you can do so stealthily according to the proposed 
mechanism which establishes uniform practices, just as well.



https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf



2)Being an unorthodox solution, if not controversial, please follow up with 
me offline. Unless, other NANOGers express their interests.





Regards,





Abe (2024-01-10 07:34 EST)







On 2024-01-07 22:46, KARIM MEKKAOUI wrote:

Hi Nanog Community



Any idea please on the best way to buy IPv4 blocs and what is the price?



Thank you



KARIM







[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

You're arguing semantics instead of the actual point. Residential customers 
want Internet access, not intranet access. Again, VRFs are plentiful and so are 
CG-NAT firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan


From: NANOG  on behalf of Abraham Y. 
Chen 
Sent: Thursday, January 11, 2024 9:24:18 AM
To: Michael Butler 
Cc: nanog@nanog.org 
Subject: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Michael:

1)" ... While you may be able to get packets from point A to B in a private 
setting, using them might also be .. a challenge. ...   ":

EzIP uses 240/4 netblock only within the RAN (Regional Area Network) as 
"Private" address, not "publicly" routable, according to the conventional 
Internet definition. This is actually the same as how 100.64/10 is used within 
CG-NAT.

2)However, this might be where the confusion comes from. With the 
geographical area coverage so much bigger, an RAN is effectively a public 
network. To mesh the two for consistency, we defined everything related to 
240/4 as "Semi-Public" to distinguish this new layer of networking facility 
from the current public / private separation. That is, the CG-NAT routers will 
become SPRs (Semi-Public Routers) in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,


Abe (2024-01-11 12:21)



On 2024-01-10 10:45, Michael Butler via NANOG wrote:
On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able 
to use it on internal networks if your equipment supports it, you cannot use it 
as publicly routable space. There have been many proposals over the years to 
reclassify 240/4, but that has not happened, and is unlikely to at any point in 
the foreseeable future.

While you may be able to get packets from point A to B in a private setting, 
using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain assumptions 
about allowable ranges. That is, they've been compiled with a header that 
defines ..

#define IN_BADCLASS(i)(((in_addr_t)(i) & 0xf000) == 0xf000)

Michael



[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
  
Virus-free.www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

There is no need to run one giant cluster. Many small clusters with VRFs and 
CG-NAT devices to bridge the gap from the VRF to the Internet and keep the 
blast radius small, are enough. A CG-NAT ISP should not need to work so hard to 
provide a unique enough CG-NAT IP address, as long as they can match a MAC 
address of the customer router + MAC address of the carrier equipment, to the 
DHCP and flow logs.

As along as the carrier implements IPv6, it will cut down on the active NAT 
sessions and port forwards the equipment needs to process.

Ryan Hamel


From: NANOG  on behalf of Abraham Y. 
Chen 
Sent: Wednesday, January 10, 2024 8:09 PM
To: Tom Beecher 
Cc: Chen, Abraham Y. ; nanog@nanog.org 
Subject: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: 
IPv4 address block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Tom:

1)Your caution advice to Karim is professional. With a lot of convoluted 
topics behind it, however, the net result is basically discouraging the 
listener from investigating the possibilities. Since this is rather 
philosophical, it can distract us from the essence unless we carry on a lengthy 
debate. Instead, I would like to address below only one aspect that you brought 
up.

2)"... an operator clearly looking to acquire *publicly routable* space 
without being clear that this suggestion wouldn't meet their needs.  ":

Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current 
CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from 
another angle, an IAP will then be able to expand the subscriber set 64 fold 
with still the original one publicly routable IPv4 address.

3)This 64 fold scaling factor is critical because it allows one CG-NAT 
cluster to serve a geographical area that becomes sufficient to cover a 
significant political territory. For example, if we assign two 240/4 addresses 
to each subscriber, one for stationary applications, one for mobile devices. 
And, each 240/4 address can be expanded by RFC1918 netblocks (total about 17.6M 
each). Each CG-NAT can now serve a country with population up to 128M. It turns 
out that population of over 90+ % of countries are fewer than this. So, each of 
them needs only one publicly routable IPv4 address. Then, the demand for IPv4 
address is drastically reduced.

4)In brief, the 240/4 is to substitute that of 100.64/10. So that the need 
for the publicly routable IPv4 addresses is significantly reduced.

Regards,


Abe (2024-01-10 23:08 EST)


On 2024-01-10 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able 
to use it on internal networks if your equipment supports it, you cannot use it 
as publicly routable space. There have been many proposals over the years to 
reclassify 240/4, but that has not happened, and is unlikely to at any point in 
the foreseeable future.

Mr. Chen-

I understand your perspective surrounding 240/4, and respect your position, 
even though I disagree. That being said, it's pretty dirty pool to toss this 
idea to an operator clearly looking to acquire *publicaly routable* space 
without being clear that this suggestion wouldn't meet their needs.

( Unless people are transferring RFC1918 space these days, in which case who 
wants to make me an offer for 10/8? )

On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI 
mailto:amekka...@mektel.ca>> wrote:

Interesting and thank you for sharing.



KARIM



From: Abraham Y. Chen mailto:ayc...@avinta.com>>
Sent: January 10, 2024 7:35 AM
To: KARIM MEKKAOUI mailto:amekka...@mektel.ca>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>; Chen, Abraham Y. 
mailto:ayc...@alum.mit.edu>>
Subject: 202401100645.AYC Re: IPv4 address block
Importance: High



Hi, Karim:



1)If you have control of your own equipment (I presume that your business 
includes IAP - Internet Access Provider, since you are asking to buy IPv4 
blocks.), you can get a large block of reserved IPv4 address for free by 
disabling the program codes in your current facility that has been disabling 
the use of 240/4 netblock. Please have a look at the below whitepaper. Utilized 
according to the outlined disciplines, this is a practically unlimited 
resources. It has been known that multi-national conglomerates have been using 
it without announcement. So, you can do so stealthily according to the proposed 
mechanism which establishes uniform practices, just as well.



https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf



2)Being an unorthodox solution, if not controversial, please follow up with 
me offline. Unless, other NANOGers express their interests.





Regards,





Abe (2024-01-10 07:34 EST)







On 2024-01-07 22:46, KARIM ME

Re: Fastly Peering Contact

[Ryan Landry]

Hi folks - former Fastly VP here.

I've flagged this thread to my past colleagues who may not be on the list.
Generally speaking, most routes from AS54113 were always available on any
given IXP route-servers. Some additional anycast routes can be announced
selectively via communities. Respecting the selective peering policy -
bi-lats are provided for somewhat bigger traffic peers, and then of course
PNI's for the really big stuff. Some of this depends on serving capacity at
any given POP.

Certainly, "big" is subjective, as is "worth it". Nevertheless, there was
(and I'm sure still is) mutual performance and cost incentive to peer
everywhere that it makes sense, and where technically feasible to do so.

Hope you all get a reply in short order.

Cheers,
Ryan

Disclaimer: things may have changed - my message here is not authoritative
on current policy posture. I am not replying on Fastly's behalf.

On Wed, Dec 6, 2023 at 10:59 PM Tim Burke  wrote:

> The PeeringDB contact info was very useful for us. Granted, we were
> pulling a substantial amount from them over transit, over 20gb at peak, so
> they have a huge incentive to peer with us. 
>
> On Dec 6, 2023, at 12:31, Justin Wilson (Lists)  wrote:
>
> 
> We have sent them some inquiries in markets we are with no reply.  Just
> figured they weren’t interested.
>
>
>
>
> Justin Wilson
> j...@mtin.net
> jus...@fd-ix.com
> Https://www.fdi-ix.com
>
> On Dec 5, 2023, at 4:14 PM, Peter Potvin via NANOG 
> wrote:
>
> Looking for someone on the Fastly peering team to reach out regarding
> peering on a couple mutual IXPs - sent an email to the peering contact as
> listed on PeeringDB and never heard back, and also have a few colleagues
> who have experienced the same issue.
>
> Regards,
> Peter Potvin | Executive Director
>
> --
> *Accuris Technologies Ltd.*
>
>
>

Re: CPE/NID options

[Ryan Hamel]

For those carriers that do not mind, they have already accepted the cost that 
comes to a truck roll and may pass the cost onto the customer depending on the 
result. Where as there are a number of carriers like Cogent, Colt, Comcast, 
Cox, Crown Castle, Lumen, Zayo, are capable of testing the circuit without a 
truck roll.

Ryan Hamel


From: Josh Luthman 
Sent: Monday, November 27, 2023 6:41 AM
To: Ryan Hamel 
Cc: Christopher Hawker ; North American Network 
Operators' Group 
Subject: Re: CPE/NID options

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Around here, Spectrum uses an Adva for demarc and it can not do rfc2544 
testing.  They will unplug the Adva and plug in the techs' mobile unit (Viavi I 
think).  VZW/Tmo/Sprint/etc don't seem to mind.

On Mon, Nov 27, 2023 at 9:34 AM Ryan Hamel 
mailto:r...@rkhtech.org>> wrote:
The problem with using switches as a CPE device is the lack of RFC2544 (or 
equivalent) testing, and monitoring of the complete circuit with TWAMP. Both of 
which are used to ensure compliance with an SLA.

Ryan Hamel


From: NANOG 
mailto:rkhtech@nanog.org>> on 
behalf of Josh Luthman 
mailto:j...@imaginenetworksllc.com>>
Sent: Monday, November 27, 2023 6:14 AM
To: Christopher Hawker mailto:ch...@thesysadmin.au>>
Cc: North American Network Operators' Group 
mailto:nanog@nanog.org>>
Subject: Re: CPE/NID options

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

When you say fiber, is it Ethernet?  If you just want layer 2 and a media 
converter, Mikrotik is a super good answer.

On Thu, Nov 23, 2023 at 12:19 AM Christopher Hawker 
mailto:ch...@thesysadmin.au>> wrote:
Hi Ross,

I've found these Mikrotik devices to be excellent and reliable:

CRS310-8G+2S+IN: 8 x 2.5G copper ethernet ports, 2 x SFP+ cages, 
rack-mountable. Uses a single DC barrel-jack. 
https://mikrotik.com/product/crs310_8g_2s_in
CRS305-1G-4S+IN: 4 x SFP+ cages, dual DC barrel-jack ports for redundant power, 
1 x 1G copper ethernet port for OOB management. 
https://mikrotik.com/product/crs305_1g_4s_in
CRS310-1G-5S-4S+OUT: 4 x SFP+ cages, 5 x SFP cages, 1 x 1G copper ethernet port 
for OOB management, can be mounted outdoors. 
https://mikrotik.com/product/netfiber_9

MSRP on all three are at or below $249.00 so are priced quite reasonably. If 
you only need SFP+ cages I'd opt for the CRS305-1G-4S+IN.

Regards,
Christopher Hawker



From: NANOG 
mailto:thesysadmin...@nanog.org>> 
on behalf of Ross Tajvar mailto:r...@tajvar.io>>
Sent: Thursday, November 23, 2023 3:41 PM
To: North American Network Operators' Group 
mailto:nanog@nanog.org>>
Subject: CPE/NID options

I'm evaluating CPEs for one of my clients, a regional ISP. Currently, we're 
terminating the customer's service (L3) on our upstream equipment and extending 
it over our own fiber to the customer's premise, where it lands in a Juniper 
EX2200 or EX2300.

At a previous job, I used Accedian's ANTs on the customer prem side. I like the 
ANT because it has a small footprint with only 2 ports, it's passively cooled, 
it's very simple to operate, it's controlled centrally, etc. Unfortunately, 
when I reached out to Accedian, they insisted that the controller (which is 
required) started at $30k, which is a non-starter for us.

I'm not aware of any other products like this. Does anyone have a 
recommendation for a simple L2* device to deploy to customer premises? Not 
necessarily the exact same thing, but something similarly-featured would be 
ideal.

*I'm not sure if the ANT is exactly "layer 2", but I don't know what else to 
call it.

Re: CPE/NID options

[Ryan Hamel]

The problem with using switches as a CPE device is the lack of RFC2544 (or 
equivalent) testing, and monitoring of the complete circuit with TWAMP. Both of 
which are used to ensure compliance with an SLA.

Ryan Hamel


From: NANOG  on behalf of Josh 
Luthman 
Sent: Monday, November 27, 2023 6:14 AM
To: Christopher Hawker 
Cc: North American Network Operators' Group 
Subject: Re: CPE/NID options

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

When you say fiber, is it Ethernet?  If you just want layer 2 and a media 
converter, Mikrotik is a super good answer.

On Thu, Nov 23, 2023 at 12:19 AM Christopher Hawker 
mailto:ch...@thesysadmin.au>> wrote:
Hi Ross,

I've found these Mikrotik devices to be excellent and reliable:

CRS310-8G+2S+IN: 8 x 2.5G copper ethernet ports, 2 x SFP+ cages, 
rack-mountable. Uses a single DC barrel-jack. 
https://mikrotik.com/product/crs310_8g_2s_in
CRS305-1G-4S+IN: 4 x SFP+ cages, dual DC barrel-jack ports for redundant power, 
1 x 1G copper ethernet port for OOB management. 
https://mikrotik.com/product/crs305_1g_4s_in
CRS310-1G-5S-4S+OUT: 4 x SFP+ cages, 5 x SFP cages, 1 x 1G copper ethernet port 
for OOB management, can be mounted outdoors. 
https://mikrotik.com/product/netfiber_9

MSRP on all three are at or below $249.00 so are priced quite reasonably. If 
you only need SFP+ cages I'd opt for the CRS305-1G-4S+IN.

Regards,
Christopher Hawker



From: NANOG 
mailto:thesysadmin...@nanog.org>> 
on behalf of Ross Tajvar mailto:r...@tajvar.io>>
Sent: Thursday, November 23, 2023 3:41 PM
To: North American Network Operators' Group 
mailto:nanog@nanog.org>>
Subject: CPE/NID options

I'm evaluating CPEs for one of my clients, a regional ISP. Currently, we're 
terminating the customer's service (L3) on our upstream equipment and extending 
it over our own fiber to the customer's premise, where it lands in a Juniper 
EX2200 or EX2300.

At a previous job, I used Accedian's ANTs on the customer prem side. I like the 
ANT because it has a small footprint with only 2 ports, it's passively cooled, 
it's very simple to operate, it's controlled centrally, etc. Unfortunately, 
when I reached out to Accedian, they insisted that the controller (which is 
required) started at $30k, which is a non-starter for us.

I'm not aware of any other products like this. Does anyone have a 
recommendation for a simple L2* device to deploy to customer premises? Not 
necessarily the exact same thing, but something similarly-featured would be 
ideal.

*I'm not sure if the ANT is exactly "layer 2", but I don't know what else to 
call it.

Re: ipv6 address management - documentation

[Ryan Hamel]

Christopher,

A residential customer would be getting their /56 from the providers pool via 
RA or DHCPv6. With a /32 aggregate, it can handle 1.6 million /56 delegations, 
which can cover a few regions. It all depends on the planning going into 
splitting up the aggregate.

A rule of thumb I go by in the datacenter is, a /48 per customer per site, and 
further splitting it into /64s per VLAN, all of which can be plugged into a 
spreadsheet formula to produce a valid complete subnet.

Either way, keeping track of IPAM via spreadsheet is a recipe for disaster. 
NetBox and Nautobot are my choices, and is worth deploying on a server or VPS, 
even for home labs.

Ryan


From: NANOG  on behalf of Christopher 
Hawker 
Sent: Thursday, November 16, 2023 3:52:59 PM
To: Aaron Gould ; Owen DeLong 
Cc: nanog@nanog.org 
Subject: Re: ipv6 address management - documentation

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

One of the first things that comes to mind, is that if you were to breakout a 
/64 v6 subnet (a standard-issue subnet to a residential customer) in an Excel 
spreadsheet, the number of columns you would need is 14 digits long. You could 
breakout the equivalent of a /12 v4 in just one column. Understandably in the 
real world no one (in their right mind) would do this, this is just for 
comparison.

Regards,
Christopher H.

From: NANOG  on behalf of Owen 
DeLong via NANOG 
Sent: Friday, November 17, 2023 10:39 AM
To: Aaron Gould 
Cc: nanog@nanog.org 
Subject: Re: ipv6 address management - documentation

Spreadsheets are terrible for IPAM regardless of address length, but I am 
curious to know why you think IPv6 would be particularly worse than IPv4 in 
such a scenario?

Owen


> On Nov 16, 2023, at 10:02, Aaron Gould  wrote:
>
> For years I've used an MS Excel spreadsheet to manage my IPv4 addresses.  
> IPv6 is going to be maddening to manage in a spreadsheet.  What does everyone 
> use for their IPv6 address prefix management and documentation?  Are there 
> open source tools/apps for this?
>
> --
> -Aaron

Re: Am I the only one who thinks this is disconcerting?

[Ryan Hamel]

Matt,

Why would HE hijack Cogent's IP space? That would end in a lawsuit and 
potentially even more de-peering between them.

Ryan Hamel


From: NANOG  on behalf of Matt 
Corallo 
Sent: Monday, November 13, 2023 11:32 AM
To: Bryan Fields ; nanog@nanog.org 
Subject: Re: Am I the only one who thinks this is disconcerting?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


On 11/8/23 2:23 PM, Bryan Fields wrote:
> On 11/8/23 2:25 PM, o...@delong.com wrote:
>> Seems irresponsible to me that a root-server (or other critical DNS 
>> provider) would engage in a
>> peering war to the exclusion of workable DNS.
>
> I've brought this up before and the root servers are not really an IANA 
> function IIRC.  There's not
> much governance over them, other than what's on root-servers.org.  I think a 
> case could be made that
> C is in violation of the polices on that page and RFC 7720 section 3.
>
> Basically none of the root servers want to change this and thus it's never 
> going to change.  DNS
> will fail and select another to talk to, and things will still work.

At what point does HE just host a second C root and announce the same IPv6s? 
Might irritate Cogent,
but its not more "bad" than Cogent failing to uphold the requirements for 
running a root server.

Matt

Re: Congestion/latency-aware routing for MPLS?

[Ryan Hamel]

That's not a good option for bad weather depending on the region. Rain fade and 
other effects at 24Ghz and above can hinder a set of links, which is sometimes 
better than having no links at all. The encoding and error correcting 
capabilities play a crucial part in having a good connection.

Ryan


From: NANOG  on behalf of Mark Tees 

Sent: Wednesday, October 18, 2023 10:01:06 AM
To: Tom Beecher 
Cc: nanog 
Subject: Re: Congestion/latency-aware routing for MPLS?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

In addition to RSVP or may be worth using minimum modulation settings on the 
radios if possible. IE so that links completely drop and you re-route rather 
than run with less bandwidth.

On Wed, Oct 18, 2023, 6:34 PM Tom Beecher 
mailto:beec...@beecher.cc>> wrote:
I believe Jason's proposal is exactly what OP is looking for.

I would agree.


On Wed, Oct 18, 2023 at 11:28 AM Saku Ytti mailto:s...@ytti.fi>> 
wrote:
On Wed, 18 Oct 2023 at 17:39, Tom Beecher 
mailto:beec...@beecher.cc>> wrote:

> Auto-bandwidth won't help here if the bandwidth reduction is 'silent' as 
> stated in the first message. A 1G interface , as far as RSVP is concerned, is 
> a 1G interface, even if radio interference across it means it's effectively a 
> 500M link.

Jason also explained the TWAMP + latency solution, which is an active
solution and doesn't rely on operator or automatic bandwidth providing
information, but network automatically measures latency and encodes
this information in ISIS, allowing automatic traffic engineering for
LSP to choose the lowest latency path.
I believe Jason's proposal is exactly what OP is looking for.

--
  ++ytti

Re: MX204 tunnel services BW

[Ryan Kozak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

According to: 
[https://www.juniper.net/documentation/us/en/software/junos/interfaces-encryption/topics/topic-map/configuring-tunnel-interfaces.html\#id-configuring-tunnel-interfaces-on-mx-204-routers][https_www.juniper.net_documentation_us_en_software_junos_interfaces-encryption_topics_topic-map_configuring-tunnel-interfaces.html_id-configuring-tunnel-interfaces-on-mx-204-routers]

"The MX204 router supports two inline tunnels - one per PIC. To configure the 
tunnel interfaces, include the tunnel-services statement and an optional 
bandwidth of 1 Gbps through 200 Gbps at the \[edit chassis fpc fpc-slot pic 
number\] hierarchy level. If you do not specify the tunnel bandwidth then, the 
tunnel interface can have a maximum bandwidth of up to 200 Gbps."

If JTAC is saying it's no longer optional they need to update their docs.

AFAIK, tunnel services doesn't directly take bandwidth from physical ports, but 
it does take from the total available PFE bandwidth. Disabling a port may be 
required as the MX204 has a maximum PFE bandwidth of 400G and you can 
oversubscribe that with the fixed physical ports.

I just checked a production config as an example, note how et-0/0/3 is not 
configured so the total bandwidth adds up to 400g:

set chassis fpc 0 pic 0 tunnel-services bandwidth 20g
set chassis fpc 0 pic 0 port 0 speed 100g
set chassis fpc 0 pic 0 port 1 speed 100g
set chassis fpc 0 pic 0 port 2 speed 100g
set chassis fpc 0 pic 1 port 0 speed 10g
set chassis fpc 0 pic 1 port 1 speed 10g
set chassis fpc 0 pic 1 port 2 speed 10g
set chassis fpc 0 pic 1 port 3 speed 10g
set chassis fpc 0 pic 1 port 4 speed 10g
set chassis fpc 0 pic 1 port 5 speed 10g
set chassis fpc 0 pic 1 port 6 speed 10g
set chassis fpc 0 pic 1 port 7 speed 10g



Regards,


Ryan








\ Original Message 
On Oct. 16, 2023, 12:49, Jeff Behrns via NANOG < nanog@nanog.org> wrote:

>
> JTAC says we must disable a physical port to allocate BW for tunnel-services. 
> Also leaving tunnel-services bandwidth unspecified is not possible on the 
> 204. I haven't independently tested / validated in lab yet, but this is what 
> they have told me. I advised JTAC to update the MX204 "port-checker" tool 
> with a tunnel-services knob to make this caveat more apparent.


[https_www.juniper.net_documentation_us_en_software_junos_interfaces-encryption_topics_topic-map_configuring-tunnel-interfaces.html_id-configuring-tunnel-interfaces-on-mx-204-routers]:
 
https://www.juniper.net/documentation/us/en/software/junos/interfaces-encryption/topics/topic-map/configuring-tunnel-interfaces.html#id-configuring-tunnel-interfaces-on-mx-204-routers
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wnUEARYIACcFAmUt4VMJEP7aH/V1zBsBFiEExqGOs9CyQpg6/JJ5/tof9XXM
GwEAAJF0AQCDM0b/X+LFPSXjVfC6NQGEyszqkIkbq84tmzl+boOJgwD+NM8u
n7o4e2SoCYs8yOIyaii2ElG+SFT735zXQhFx6A4=
=JuZc
-END PGP SIGNATURE-


publickey - EmailAddress(s=ryan@kozak.io) - 0xC6A18EB3.asc
Description: application/pgp-keys


publickey - EmailAddress(s=ryan@kozak.io) - 0xC6A18EB3.asc.sig
Description: PGP signature

Re: transit and peering costs projections

[Ryan Hamel]

Why not place the routers in Dallas, aggregate the transit, IXP, and PNI's 
there, and backhaul it over redundant dark fiber with DWDM waves or 400G OpenZR?

Ryan


From: NANOG  on behalf of Tim Burke 

Sent: Saturday, October 14, 2023 8:45 PM
To: Dave Taht 
Cc: Network Neutrality is back! Let´s make the technical aspects heard this 
time! ; libreqos 
; NANOG 
Subject: Re: transit and peering costs projections

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


I would say that a 1Gbit IP transit in a carrier neutral DC can be had for a 
good bit less than $900 on the wholesale market.

Sadly, IXP’s are seemingly turning into a pay to play game, with rates almost 
costing as much as transit in many cases after you factor in loop costs.

For example, in the Houston market (one of the largest and fastest growing 
regions in the US!), we do not have a major IX, so to get up to Dallas it’s 
several thousand for a 100g wave, plus several thousand for a 100g port on one 
of those major IXes. Or, a better option, we can get a 100g flat internet 
transit for just a little bit more.

Fortunately, for us as an eyeball network, there are a good number of major 
content networks that are allowing for private peering in markets like Houston 
for just the cost of a cross connect and a QSFP if you’re in the right DC, with 
Google and some others being the outliers.

So for now, we'll keep paying for transit to get to the others (since it’s 
about as much as transporting IXP from Dallas), and hoping someone at Google 
finally sees Houston as more than a third rate city hanging off of Dallas. Or… 
someone finally brings a worthwhile IX to Houston that gets us more than 
peering to Kansas City. Yeah, I think the former is more likely. 

See y’all in San Diego this week,
Tim

On Oct 14, 2023, at 18:04, Dave Taht  wrote:
>
> This set of trendlines was very interesting. Unfortunately the data
> stops in 2015. Does anyone have more recent data?
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrpeering.net%2Fwhite-papers%2FInternet-Transit-Pricing-Historical-And-Projected.php=05%7C01%7Cryan%40rkhtech.org%7Cc8ebae9f0ecd4b368dcb08dbcd319880%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638329385118876648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=nQeWrGi%2BblMmtiG9u7SdF3JOi1h9Fni7xXo%2FusZRopA%3D=0<https://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php>
>
> I believe a gbit circuit that an ISP can resell still runs at about
> $900 - $1.4k (?) in the usa? How about elsewhere?
>
> ...
>
> I am under the impression that many IXPs remain very successful,
> states without them suffer, and I also find the concept of doing micro
> IXPs at the city level, appealing, and now achievable with cheap gear.
> Finer grained cross connects between telco and ISP and IXP would lower
> latencies across town quite hugely...
>
> PS I hear ARIN is planning on dropping the price for, and bundling 3
> BGP AS numbers at a time, as of the end of this year, also.
>
>
>
> --
> Oct 30: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnetdevconf.info%2F0x17%2Fnews%2Fthe-maestro-and-the-music-bof.html=05%7C01%7Cryan%40rkhtech.org%7Cc8ebae9f0ecd4b368dcb08dbcd319880%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638329385118876648%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ROLgtoeiBgfAG40UZqS8Zd8vMK%2B0HQB7RV%2FhQRvIcFM%3D=0<https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html>
> Dave Täht CSO, LibreQos

Re: Low to Mid Range DWDM Platforms

[Ryan Hamel]

Solid Optics? -- 
https://www.solid-optics.com/product/edfamux-multiplexer-amplifier-dispersion-compensation-dwdm-mux-edfa/

Ryan


From: NANOG  on behalf of Dave Bell 

Sent: Friday, October 6, 2023 6:52 AM
To: Mark Tinka 
Cc: nanog@nanog.org 
Subject: Re: Low to Mid Range DWDM Platforms

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Smartoptics?

https://smartoptics.com/

Regards,
Dave

On Fri, 6 Oct 2023 at 14:43, Mark Tinka  wrote:


On 10/6/23 15:07, Mike Hammett wrote:

> I've been using various forms of passive WDM for years. I have a couple 
> different projects on my plate that require me to look at the next level of 
> platform.
>
> In some projects, I'll be looking for needing to have someone long distances 
> of glass without any electronics. Some spans could be over 60 miles.
>
> In some projects, I'll need to transport multiple 100-gig waves.
>
> What is the landscape like between basic passive and something like a 30 
> terabit Ciena? I know of multiple vendors in that space, but I like to learn 
> more about what features I need and what features I don't need from somewhere 
> other than the vendor's mouth. Obviously, the most reliability at the least 
> cost as well.

400G-ZR pluggables will get you 400Gbps on a p2p dark fibre over 80km -
100km. So your main cost there will be routers that will support.

The smallest DCI solution from the leading DWDM vendors is likely to be
your cheapest option. Alternatively, if you are willing to look at the
open market, you can find gear based on older CMOS (40nm, for example),
which will now be EoL for any large scale optical network, but cost next
to nothing for a start-up with considerable capacity value.

There is a DWDM vendor that showed up on the scene back in 2008 or
thereabouts. They were selling a very cheap, 1U box that had a different
approach to DWDM from other vendors at the time. I, for the life of me,
cannot remember their name - but I do know that Randy introduced them to
me back then. Maybe he can remember :-). Not sure if they are still in
business.

Mark.

Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Ryan A. Krenzischek via NANOG]

Yes, I already tried rebooting several times.  Perhaps a large hammer will fix 
it!  At least I know I'll be well notified in an emergency.

> On Oct 4, 2023, at 14:42, Sean Donelan  wrote:
>
> On Wed, 4 Oct 2023, Ryan A. Krenzischek wrote:
>> I've only gotten the alert now ...9 times.
>
> Unless you keep turning your phone off, alerts have a serial number. Phones 
> check the serial number for recently received alerts.
>
>
> Or so Android and iOS developers claim.  If you are getting duplicate alerts, 
> their advice is the standard I.T. mantra -- turn you phone off and on again.
>
>



smime.p7s
Description: S/MIME cryptographic signature

Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Ryan A. Krenzischek via NANOG]

I've only gotten the alert now ...9 times.

Ryan


smime.p7s
Description: S/MIME cryptographic signature

Re: maximum ipv4 bgp prefix length of /24 ?

[Ryan Hamel]

Matt,

It's not just you or Google, I just got those emails to my Office 365 at the 
same time. My guess is that the list admins/moderators got the emails and just 
responded without approving the moderated emails.

Ryan


From: NANOG  on behalf of Matthew 
Petach 
Sent: Friday, September 29, 2023 10:31 AM
To: VOLKAN SALİH 
Cc: nanog list 
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.



On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH 
mailto:volkan.salih...@gmail.com>> wrote:

[...]

I presume there would be another 50 big ASNs that belong to CDNs. And I am 
pretty sure those top 100 networks can invest in gear to support /25-/27.

Volkan,

So far, you haven't presented any good financial reason those top 100 networks 
should spend millions of dollars to upgrade their networks just so your /27 can 
be multihomed.

Sure, they *can* invest in gear to support /25-/27; but they won't, because 
there's no financial benefit for them to do so.

I know from *your* side of the table, it would make your life better if 
everyone would accept /27 prefixes--multihoming for the masses, yay!

Try standing in their shoes for a minute, though.
You need to spend tens of millions of dollars on a multi-year refresh cycle to 
upgrade hundreds of routers in your global backbone, tying up network 
engineering resources on upgrades that at the end, will bring you exactly $0 in 
additional revenue.

Imagine you're the COO or CTO of a Fortune 500 network, and you're meeting with 
your CFO to pitch this idea.
You know your CFO is going to ask one question right off the bat "what's the 
timeframe for us to recoup the cost of
this upgrade?" (hint, he's looking for a number less than 40 months).
If your answer is "well, we're never going to recoup the cost.  It won't bring 
us any additional customers, it won't bring us any additional revenue, and it 
won't make our existing customers any happier with us.  But it will make it 
easier for some of our smaller compeitors to sign up new customers." I can 
pretty much guarantee your meeting with the CFO will end right there.

If you want networks to do this, you need to figure out a way for it to make 
financial sense for them to do it.

So far, you haven't presented anything that would make it a win-win scenario 
for the ISPs and CDNs that would need to upgrade to support this.


ON a separate note--NANOG mailing list admins, I'm noting that Vokan's emails 
just arrived a few minutes ago in my gmail inbox.
However,  I saw replies to his messages from others on the list yesterday, a 
day before they made it to the general list.
Is there a backed up queue somewhere in the NANOG list processing that is 
delaying some messages sent to the list by up to a full day?
If not, I'll just blame gmail for selectively delaying portions of NANOG for 
18+ hours.   ^_^;

Thanks!

Matt

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Ryan Hamel]

Martin and Tom,

How is it a private marketing initiative exactly if the links go to stories on 
NANOG's website? Are you saying the very org that brings us together, is not 
allowed to spur discussion based on newsletter content and cannot provide us 
with updates and/or reminders about various things?

Y'all have been making a mountain out of a molehill.

Ryan


From: Tom Beecher 
Sent: Saturday, September 9, 2023 9:30:13 AM
To: Martin Hannigan 
Cc: Ryan Hamel ; nanog@nanog.org 
Subject: Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC 
Course + More

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

What network does Nanog-news operate?

Marketing email doesn’t  belong on an operational list.  Even if its NANOG 
marketing itself.  (Ack Kentik non involvement).

This is the right comment.

The NANOG Mailing List Usage Guidelines  ( 
https://www.nanog.org/resources/usage-guidelines/ ) are fairly clear about this.

Posts to NANOG’s Mailing List should be focused on operational and technical 
content only, as described by the NANOG Bylaws.
Using the NANOG Mailing List as a source for private marketing initiatives, or 
product marketing of any kind, is prohibited.

Sending this type of message to nanog@ is not appropriate, by our own rules. 
This issue will be raised at the next members meeting.




On Fri, Sep 8, 2023 at 9:39 PM Martin Hannigan 
mailto:hanni...@gmail.com>> wrote:

What network does Nanog-news operate?

Marketing email doesn’t  belong on an operational list.  Even if its NANOG 
marketing itself.  (Ack Kentik non involvement).

Warm regards,

-M<


On Fri, Sep 8, 2023 at 20:52 Ryan Hamel 
mailto:r...@rkhtech.org>> wrote:
Randy,

You're right, the problem is not technical. It's a choice to click the links or 
not. NANOG does not have to sanitize links for you. Those emails do not have to 
be read, and no one is stopping you from filtering them out. For you to say, 
"my privacy has been sold", is simply not true.

Ryan


From: NANOG 
mailto:rkhtech@nanog.org>> on 
behalf of Randy Bush mailto:ra...@psg.com>>
Sent: Friday, September 8, 2023 5:25 PM
To: John Gilmore mailto:g...@toad.com>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org> 
mailto:nanog@nanog.org>>
Subject: Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC 
Course + More

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


> It is totally possible to turn off the spyware in MailChimp.  You just
> need to buy an actual commercial account rather than using their
> "free" service.  To save $13 or $20 per month, you are instead selling
> the privacy of every recipient of your emails.  See:
>
>   
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fenable-and-view-click-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Pw6uDgHDzT%2BavOz1jYAbG4VzTyP0en0oiuBq0PmTtVI%3D=0<https://mailchimp.com/help/enable-and-view-click-tracking/>
>
>   "Check the Track clicks box to enable click tracking, or uncheck the
>   box to disable click tracking.  ...  Mailchimp will continue to
>   redirect URLs for users with free account plans to protect against
>   malicious links.  ...  When a paid user turns off click tracking,
>   Mailchimp will continue to redirect their URLs until certain account
>   activity thresholds are met."
>
> Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> MailChimp inserts by default, too:
>
>   
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fabout-open-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iqkTsuhDFD3poxVltrN4x%2FWY6eXpbIivWxf4VAWcXKA%3D=0<https://mailchimp.com/help/about-open-tracking/>


as usual, the problem is not technical.  there is no need for mailchump
at all.

nanog management has made a very intentional decision to sell my
privacy.  nanog has come a long way, not all of it  good.

randy

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Ryan Hamel]

Randy,

You're right, the problem is not technical. It's a choice to click the links or 
not. NANOG does not have to sanitize links for you. Those emails do not have to 
be read, and no one is stopping you from filtering them out. For you to say, 
"my privacy has been sold", is simply not true.

Ryan


From: NANOG  on behalf of Randy Bush 

Sent: Friday, September 8, 2023 5:25 PM
To: John Gilmore 
Cc: nanog@nanog.org 
Subject: Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC 
Course + More

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


> It is totally possible to turn off the spyware in MailChimp.  You just
> need to buy an actual commercial account rather than using their
> "free" service.  To save $13 or $20 per month, you are instead selling
> the privacy of every recipient of your emails.  See:
>
>   
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fenable-and-view-click-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Pw6uDgHDzT%2BavOz1jYAbG4VzTyP0en0oiuBq0PmTtVI%3D=0<https://mailchimp.com/help/enable-and-view-click-tracking/>
>
>   "Check the Track clicks box to enable click tracking, or uncheck the
>   box to disable click tracking.  ...  Mailchimp will continue to
>   redirect URLs for users with free account plans to protect against
>   malicious links.  ...  When a paid user turns off click tracking,
>   Mailchimp will continue to redirect their URLs until certain account
>   activity thresholds are met."
>
> Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> MailChimp inserts by default, too:
>
>   
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fabout-open-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iqkTsuhDFD3poxVltrN4x%2FWY6eXpbIivWxf4VAWcXKA%3D=0<https://mailchimp.com/help/about-open-tracking/>

as usual, the problem is not technical.  there is no need for mailchump
at all.

nanog management has made a very intentional decision to sell my
privacy.  nanog has come a long way, not all of it  good.

randy

Re: MX204 Virtual Chassis Setup

[Ryan Hamel]

Paschal,

It is not supported, nor is it recommended for redundancy in a routed setup. 
Please describe your (desired) topology, that way the community can discuss 
alternatives.

Thanks,

Ryan Hamel


From: NANOG  on behalf of Pascal 
Masha 
Sent: Monday, August 21, 2023 7:41 AM
To: nanog@nanog.org 
Subject: MX204 Virtual Chassis Setup

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hello,

Does the MX204 support virtual chassis setup?

Regards,
Paschal Masha

Re: 10G CPE w/VXLAN - vendors?

[Ryan Hamel]

I would never let the customer manage the CPE device, unless it was through 
some customer portal where automation can do checks and balances, nor have the 
device participate in a ring topology -- home runs or bust. If the device fails 
or has an issue requiring a field dispatch, that is on the customer to help 
arrange that time and provide on-site contact info, otherwise the SLA clock 
stops ticking.

Now if the customer refuses to allow the vendor to pickup the CPE (regardless 
of make/model) and/or building aggregation/demarc + UPS hardware, the police 
can get called for theft of equipment depending on its value, or 
customer/landlord is sued depending on what the contract states.

As for Ciena's SAOS feature set, I was only going by the RFC's and protocols 
listed on some of the higher end CPE equipment. I do not have first hand 
experience with them.

Tier 1's as in Cogent, Level3/Lumen, Zayo, etc.

Juniper's ACX7024 does look interesting as a building demarc/agg device, but 
overkill for a single client CPE. It can't hold full tables for transit 
handoffs, but the customer can establish multi-hop BGP sessions upstream for 
that.

Ryan Hamel

From: Mark Tinka 
Sent: Wednesday, June 14, 2023 11:50 PM
To: Ryan Hamel ; nanog@nanog.org 
Subject: Re: 10G CPE w/VXLAN - vendors?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.



On 6/15/23 07:49, Ryan Hamel wrote:

If the customer's site goes offline, that is their problem. A CPE device is 
still a CPE device, no matter how smart it is. Setup IS-IS, BGP to route 
servers, LDP + MPLS if you don't go the VXLAN route, and that's it.

So you have two issues here:

  *   If it's a pure CPE device running IS-IS, LDP, RSVP-TE, SR-MPLS, BGP, 
e.t.c. on the core-facing side, you have a problem if the customer can manage 
the router, and potentially introduces badness into your routed core.

  *   If it's a u-PE co-located at the customer site and it goes down, you've 
just isolated part of your ring because, well, the customer's cleaners decided 
they needed the router's socket for their equipment, because it's closer than 
the one they usually use.

As a bonus, if it's a u-PE that you need physical access to for whatever 
reason, but you can't because the customer does not treat their site like a 
typical data centre with whom you have a contract, that will be another avenue 
of pleasure & joy.


As a bonus bonus, if it's a u-PE and you decide you are done with the site and 
want to decommission it, the customer can deny you entry into the site.


Yes, these are real problems. Yes, these real problems have really happened. 
You are not my competitor, so I don't wish them upon you.


I know Ciena's can do that on their more expensive 39xx models.

Unless things changed, my understanding is Ciena's implementation is MPLS-TP. 
Does anybody know if they now have full support for IP/MPLS in the way we have 
it with real router vendors?



There are a few tier 1's...

Don't know what "teir 1's" means :-).


that have delivered Ethernet transport circuits on those exact boxes in the 
field as I speak. It works very well.

Well, the ME3600X/3800X has been EoL for quite some time now. But yes, it would 
work, especially if you don't run BGP on it.



I also agree with your stance on Broadcom, it's hard to come up with 
alternatives that are not ADVA/Ciena/Cisco/RAD.

So the optical OEM's are not generally good options for routers of any kind. 
That knocks Adva, Ciena, Infinera, Xtera, Tejas, e.t.c., off the list.

Nokia do have a decent IP/MPLS platform, thanks for ALU. But the Metro-E boxes 
they position for that segment - the 7250 IXR-e, IXR-s and IXR-x - are also 
using Broadcom.

Not interested in Huawei.

I like Mikrotik, but only as a self-managed CPE, and not for a service provider 
backbone.

Arrcus are currently focusing on the data centre.

Arista aren't interested in the Metro-E space.

HP/3Com, Dell, Extreme - very unknown quantities that I'm not motivated to look 
into.

At the moment, the battle is really etween Cisco's NCS540 and Juniper's 
ACX7100/7200 platforms. Both are Broadcom-based, but I think Juniper have the 
slightly better idea in terms of how much they can squeeze out of Broadcom re: 
how much one can touch a customer's packets.

Mark.

Re: 10G CPE w/VXLAN - vendors?

[Ryan Hamel]

I fully agree here too. That's why I proposed a "smarter" CPE to replace the 
standard appliances deployed on site, where the only thing changing is the 
configuration on the device itself, not product being handed off.

Ryan Hamel

From: NANOG  on behalf of Mark Tinka 

Sent: Wednesday, June 14, 2023 10:31 PM
To: nanog@nanog.org 
Subject: Re: 10G CPE w/VXLAN - vendors?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.



On 6/14/23 21:16, Joe Freeman wrote:


I think you’re probably overthinking this a bit.



Why do you need to extend your vxlan/evpn to the customer premise? There are a 
number of 1G/10G even 100G CPE demarc devices out there that push/pop tags, 
even q-in-q, or 802.1ad. Assuming you have some type of aggregation node you 
bring these back to, tie those tags to the appropriate EVPN instance at the 
aggregation point. Don’t extend anything but a management tag and an S-tag 
essentially to the device at the customer premise.



You can even put that management tagged vlan in it’s own L3 segment, or a 
larger L3 network and impose security. This way you’re not exposing your whole 
service infrastructure to a bad actor that might unplug your cpe device and 
plug into your network directly.

The reason customers ask that their site be part of the customer's Metro-E 
backbone is so that they can enjoy link redundancy without paying for it.

Operators will generally have east and west links coming out of a Metro-E site. 
Customers who single-home into this device only have their last mile as the 
risk. But if the operator drops a Metro-E node into the customer's site, and 
cables it per standard, the customer has the benefit of last mile redundancy, 
because the internal fibre/copper patch to the operator's Metro-E switch does 
not really count as a (risky) last mile.

Sales people like to do this to engender themselves with the customer.

Customers like to do this to get a free meal.

Don't do it, because customer's always assume that that Metro-E node that is in 
their building "belongs to them".

Mark.

Re: 10G CPE w/VXLAN - vendors?

[Ryan Hamel]

> Putting the smart devices on the edge allows for a much-simplified core 
> topology.

>> Putting smart devices in the edge does simplify the network, yes. What 
>> doesn't is making the customer's site part of your edge.

If the customer's site goes offline, that is their problem. A CPE device is 
still a CPE device, no matter how smart it is. Setup IS-IS, BGP to route 
servers, LDP + MPLS if you don't go the VXLAN route, and that's it. I know 
Ciena's can do that on their more expensive 39xx models.

>> We've been running MPLS all the way into the access since 2009 (Cisco 
>> ME3600X/3800X). It is simpler than running an 802.1Q or Q-in-Q Metro-E 
>> backbone, and scales very well. Just leave your customers out of it.

There are a few tier 1's that have delivered Ethernet transport circuits on 
those exact boxes in the field as I speak. It works very well.

I also agree with your stance on Broadcom, it's hard to come up with 
alternatives that are not ADVA/Ciena/Cisco/RAD.

Ryan Hamel

From: NANOG  on behalf of Mark Tinka 

Sent: Wednesday, June 14, 2023 10:30 PM
To: nanog@nanog.org 
Subject: Re: 10G CPE w/VXLAN - vendors?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.


On 6/14/23 22:04, Ryan Hamel wrote:

> Putting the smart devices on the edge allows for a much-simplified
> core topology.

Putting smart devices in the edge does simplify the network, yes. What
doesn't is making the customer's site part of your edge.

We've been running MPLS all the way into the access since 2009 (Cisco
ME3600X/3800X). It is simpler than running an 802.1Q or Q-in-Q Metro-E
backbone, and scales very well. Just leave your customers out of it.


>
> Either way, I was doing research on FPGA-based hardware a couple of
> weeks agoand came across this which may tick all the boxes.
> https://ethernitynet.com/products/enet-network-appliances/uep-60/ I do
> not know the vendor personally and have not worked on their hardware,
> so your mileage may vary.

There aren't a great deal of options in this space, unfortunately. What
is making it worse is most traditional vendors are relegating devices
designed for this to Broadcom chips, which is a problem because the
closer you get to the customer, the more you need to "touch" their
packets, and Broadcom chips, while fast and cheap, aren't terribly good
at working with packets in the way the customers these devices need to
address would like.

Cisco's ASR920 is still, by far, the best option here. Unfortunately, it
has a very small FIB, does not do 10Gbps at any scale, and certainly
does not 100Gbps. But, because most customers tend to run only p2p
EoMPLS services on it (that doesn't require any large FIB), the box is
still actively sold by Cisco even though in Internet years, it is older
than my grandfather's tobacco pipe.

Juniper are pushing their ACX7024, which we are looking at as a viable
option for replacing the ASR920. However, it's Broadcom... and while
Nokia's Broadcom option for the Metro-E network is using the same chip
as the Juniper one, they seem lazier to be more creative with how they
can touch customer packets vs. Juniper.

Cisco's recommended upgrade path is the NCS540, also a Broadcom box; the
heaviness that is IOS XR in a large scale deployment area like the
Metro-E backbone notwithstanding. The rumour is that Cisco want to
optimize Silicon One for their entire routing & switching range, small
and large. I'll believe it when I see it. Until then, I wouldn't touch
the NCS540.

Vendors are trying to do the least in the Metro-E space, knowing full
well how high the margins are. It's a bit disingenuous, considering they
will be shipping more Metro-E routers to customers than core or edge
routers. But, it is what it is.

Mark.

Re: 10G CPE w/VXLAN - vendors?

[Ryan Hamel]

The problem with these switch suggestions is the lack of RFC2544 testing, and 
jitter + latency monitoring required for meeting SLA. That is why I mentioned 
the FPGA solution.

Ryan Hamel


From: NANOG  on behalf of Brandon 
Price 
Sent: Wednesday, June 14, 2023 2:27:02 PM
To: Adam Thompson ; nanog 
Subject: RE: 10G CPE w/VXLAN - vendors?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

The Juniper EX4100-F-12T is pretty nice. Fanless, 1RU, 4x SFP+, 2x 10G Copper 
which can also be used to power up the switch, and 12x 1G Copper ports. 
EVPN/VXLAN requires an additional license. They don’t break the bank, our use 
case is for a CPE as well.

Brandon

From: NANOG  On Behalf Of 
Adam Thompson
Sent: Wednesday, June 14, 2023 11:51 AM
To: nanog 
Subject: 10G CPE w/VXLAN - vendors?

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

Hello, all.
I’m having difficulty finding vendors, never mind products, that fit my need.

We have a small but growing number of L2 (bridged) customers that have diverse 
fiber paths available, and, naturally, want to make use of them.
We have a solution for this: we extend the edge of our EVPN VXLAN fabric right 
to the customer premise.  The customer-prem device needs 4x10G SFP+ cages (2 
redundant paths, plus LAG to customer), and the switches we currently use, 
Arista 7020Rs, are quite expensive if I’m deploying one one per customer.  
(Nice switches, but overkill here – I don’t need 40/100G, and I don’t need 24 
SFP+ ports.  And they still take forever to ship.)

We use RFC7438 §6.3 “vlan-aware-bundle” mode, not §6.1 “vlan-based” mode, which 
limits our choices somewhat.  I might be willing to entertain spinning up a 
separate VXLAN mesh using RFC7438 §6.1 (“vlan-based”) and static VTEPs if it 
saves me a lot of pain.

However, I’m having trouble finding small & cheaper 1U (or even 
desktop/wallmount) devices that have 4 SFP+ cages, and can do VXLAN, in the 
first place.
Who even makes CPE gear with SFP+ ports?  (Other than Mikrotik CRS309-1G-8S+IN 
/ CRS317-1G-16S+RM, which are nice, but our policy requires vendor support 
contracts, so… no-go.)

Vendors?  Model#s, if you happen to know any?

Reply here or privately, whatever floats your boat – any pointers appreciated!

Adam Thompson
Consultant, Infrastructure Services
[[MERLIN logo]]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca<https://www.merlin.mb.ca/>
[cid:image002.png@01D99EC2.B891B0A0]Chat with me on 
Teams<https://teams.microsoft.com/l/chat/0/0?users=athomp...@merlin.mb.ca>

Re: 10G CPE w/VXLAN - vendors?

[Ryan Hamel]

Putting the smart devices on the edge allows for a much-simplified core 
topology.

Either way, I was doing research on FPGA-based hardware a couple of weeks ago 
and came across this which may tick all the boxes. 
https://ethernitynet.com/products/enet-network-appliances/uep-60/ I do not know 
the vendor personally and have not worked on their hardware, so your mileage 
may vary.

Ryan


From: NANOG  on behalf of Joe Freeman 

Sent: Wednesday, June 14, 2023 12:19:26 PM
To: Adam Thompson ; nanog 
Subject: Re: 10G CPE w/VXLAN - vendors?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

I think you’re probably overthinking this a bit.

Why do you need to extend your vxlan/evpn to the customer premise? There are a 
number of 1G/10G even 100G CPE demarc devices out there that push/pop tags, 
even q-in-q, or 802.1ad. Assuming you have some type of aggregation node you 
bring these back to, tie those tags to the appropriate EVPN instance at the 
aggregation point. Don’t extend anything but a management tag and an S-tag 
essentially to the device at the customer premise.

You can even put that management tagged vlan in it’s own L3 segment, or a 
larger L3 network and impose security. This way you’re not exposing your whole 
service infrastructure to a bad actor that might unplug your cpe device and 
plug into your network directly.



From: NANOG  on behalf of Adam 
Thompson 
Date: Wednesday, June 14, 2023 at 2:52 PM
To: nanog 
Subject: 10G CPE w/VXLAN - vendors?
Hello, all.
I’m having difficulty finding vendors, never mind products, that fit my need.

We have a small but growing number of L2 (bridged) customers that have diverse 
fiber paths available, and, naturally, want to make use of them.
We have a solution for this: we extend the edge of our EVPN VXLAN fabric right 
to the customer premise.  The customer-prem device needs 4x10G SFP+ cages (2 
redundant paths, plus LAG to customer), and the switches we currently use, 
Arista 7020Rs, are quite expensive if I’m deploying one one per customer.  
(Nice switches, but overkill here – I don’t need 40/100G, and I don’t need 24 
SFP+ ports.  And they still take forever to ship.)

We use RFC7438 §6.3 “vlan-aware-bundle” mode, not §6.1 “vlan-based” mode, which 
limits our choices somewhat.  I might be willing to entertain spinning up a 
separate VXLAN mesh using RFC7438 §6.1 (“vlan-based”) and static VTEPs if it 
saves me a lot of pain.

However, I’m having trouble finding small & cheaper 1U (or even 
desktop/wallmount) devices that have 4 SFP+ cages, and can do VXLAN, in the 
first place.
Who even makes CPE gear with SFP+ ports?  (Other than Mikrotik CRS309-1G-8S+IN 
/ CRS317-1G-16S+RM, which are nice, but our policy requires vendor support 
contracts, so… no-go.)

Vendors?  Model#s, if you happen to know any?

Reply here or privately, whatever floats your boat – any pointers appreciated!

Adam Thompson
Consultant, Infrastructure Services
[[MERLIN logo]]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca<https://www.merlin.mb.ca/>
[cid:image002.png@01D99EC2.B891B0A0]Chat with me on 
Teams<https://teams.microsoft.com/l/chat/0/0?users=athomp...@merlin.mb.ca>

Re: IPv4 Subnet 23.151.232.0/24 blackholed?

[Ryan Hamel]

Neel,

Carriers rebuild their prefixes lists once or twice in a 24 hour period. 
Considering that you just got the block today and is in ReliableSite's 
AS-SET, you just got to be patient.


Having announcements propagated immediately either sounds like it 
happened a day after you gave them the LOA, or they have unfiltered 
transit circuits, which is worrisome.


Ryan

-- Original Message --

From "Neel Chauhan" 

To nanog@nanog.org
Date 4/25/2023 7:35:40 PM
Subject IPv4 Subnet 23.151.232.0/24 blackholed?


Hi,

I recently got the IPv4 allocation 23.151.232.0/24 from ARIN. I also had my 
hosting company ReliableSite announce it to the internet.

Right now, I can only access networks that peer with ReliableSite via internet 
exchanges, such as Google, CloudFlare, OVH, Hurricane Electric, et al.

It seems the Tier 1 ISPs (e.g. Lumen, Cogent, AT, et al.) are blackholing the 
IPv4 subnet 23.151.232.0/24. Could someone who works at a Tier 1 NOC please check 
and remove the blackhole if any exists?

Normally when ReliableSite announced my prior (then-leased) IPv4 space it gets 
propagated via BGP almost immediately. This time it's not going through at all.

Best,

Neel Chauhan

RE: Lima, OH Spectrum/Charter Severe Node/Hop Latency Issues

[Ryan Hamel]

Austin,

 

If you run MTRs or traceroutes through the node, is there any other
additional packet loss seen in the path, and at the destination? What does
the reverse MTR or traceroute look like? The attached image was stripped out
by the mailing list system.

 

Bufferbloat is controlled at the firewall level, which is different from
packet loss and disconnects.

 

Ryan

 

From: NANOG  On Behalf Of Austin
Ayers via NANOG
Sent: Tuesday, February 7, 2023 1:49 PM
To: nanog@nanog.org
Subject: Lima, OH Spectrum/Charter Severe Node/Hop Latency Issues

 

Hello all, 

 

One of my NetOps engineers resides in Lima, Ohio and they are receiving
terrible bufferbloat, packet loss, and random disconnects.

 

I have been pinging 24.33.160.213 (Lima, OH Spectrum/Chart Node) and it's
rejecting a ton of packets. This has been going on for weeks.

 

Node having problems: lag-1.limaohid01h.netops.charter.com

 

NOC seems like they don't care, same with OSP in the field.

 

There is no reason why this hop (#13) should have up to 613ms ping times. 

 

Thank you,

Austin

 

RE: GTT blocking IPv4 address 128.31.0.39

[Ryan Hamel]

Confirmed it with a router at AS8100, static routing 128.31.0.39 towards GTT
results in a blackhole and 128.31.0.1 works just fine, which means either
the IP address is null routed on GTT's network at the request of MIT (got to
give them the benefit of the doubt) or they are knowingly blocking Tor.

Ryan Hamel

-Original Message-
From: NANOG  On Behalf Of Neel
Chauhan
Sent: Tuesday, January 3, 2023 7:49 PM
To: nanog@nanog.org
Subject: GTT blocking IPv4 address 128.31.0.39

Hi,

I am a customer of ReliableSite in their New Jersey location, and RS uses
GTT as a transit ISP, along with Tata and Comcast.

GTT appears to be blocking the IPv4 address 128.31.0.39, and RS' BGP uses
GTT for 128.31.0.39.

neel@t1:~ % traceroute 128.31.0.39
traceroute to 128.31.0.39 (128.31.0.39), 64 hops max, 40 byte packets
  1  45.150.XXX.1 (45.150.XXX.1)  4.828 ms  4.557 ms  5.916 ms
  2  * * *
^C
neel@t1:~ %

Hop #2 which is generally the transit provider, GTT (which handles this
route).

Note: 45.150.XXX.1 is because it's a subnet I brought in, this is the only
ReliableSite hop.

The 128.31.0.0/24 doesn't appear to be blocked as a whole, only that
128.31.0.39. See below:

neel@t1:~ % traceroute 128.31.0.1
traceroute to 128.31.0.1 (128.31.0.1), 64 hops max, 40 byte packets
  1  45.150.XXX.1 (45.150.XXX.1)  0.241 ms  0.220 ms  9.362 ms
  2  ae9-300.cr2-nyc4.ip4.gtt.net (209.120.147.121)  1.605 ms  0.853 ms
1.173 ms
  3  ae3.cr1-nyc2.ip4.gtt.net (89.149.129.194)  5.488 ms  6.471 ms  1.451 ms
  4  be3088.ccr31.jfk04.atlas.cogentco.com (154.54.11.57)  1.604 ms
1.726 ms *
  5  be3363.ccr42.jfk02.atlas.cogentco.com (154.54.3.125)  1.802 ms
1.771 ms  1.708 ms
  6  be3472.ccr32.bos01.atlas.cogentco.com (154.54.46.33)  7.082 ms
7.268 ms  7.249 ms
  7  38.104.186.186 (38.104.186.186)  7.017 ms  7.247 ms  6.987 ms
  8  dmz-rtr-1-external-rtr-3.mit.edu (18.0.161.13)  7.010 ms  7.001 ms
6.996 ms
  9  dmz-rtr-2-dmz-rtr-1-2.mit.edu (18.0.162.6)  7.033 ms  7.294 ms
 dmz-rtr-2-dmz-rtr-1-1.mit.edu (18.0.161.6)  7.073 ms
10  guest.default.csail.mit.edu (128.31.0.1)  9.011 ms  7.484 ms  7.551 ms
neel@t1:~ %

As you can see here, GTT handles other 128.31.0.39 IPs fine as seen in hop
#2.

ReliableSite says they don't block the IP address, but I don't have any
contact at GTT or MIT.

My home ISP, Lumen/CenturyLink/Level 3 does not block 128.31.0.39.

128.31.0.39 is a Tor directory authority IP, which is usually a phonebook of
Tor relays. There are 9 in the world and the other 8 are unblocked from
ReliableSite.

Yes, I know Tor is all this 'bad stuff' but the reality is that 99% of Tor
users use it like a VPN, speaking as a Tor exit operator and code
contributor myself. Exit abuse complaints were super common 5-8 years ago
but are now super rare.

If someone works at GTT, can 128.31.0.39 be unblocked?

Best,

-Neel

---

https://www.neelc.org

IP Blocked from Airbnb

[Ryan Hamel]

Hello Everyone,

 

If there is someone on this list from Airbnb who can get an IP address
removed from a block list, please contact me off list.

 

Thanks!

 

Ryan Hamel

RE: AS3356 Announcing 2000::/12

[Ryan Hamel]

I know of a few people in a Discord that filter out anything bigger than /16 
routes, would this be wise to implement as a best practice?

 

From: Warren Kumari  
Sent: Friday, December 9, 2022 9:13 AM
To: Job Snijders 
Cc: r...@rkhtech.org; North American Network Operators' Group 
Subject: Re: AS3356 Announcing 2000::/12

 

 

 

 

 

On Thu, Dec 8 2022 at 12:38 PM, Job Snijders mailto:nanog@nanog.org> > wrote: 

 

Hi all,

On Wed, Dec 07, 2022 at 08:24:54PM -0800, Ryan Hamel wrote:

AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate 
covering over 23K prefixes (just over 25%) of the IPv6 DFZ.

A few months ago I wrote: "Frequently Asked Questions about 2000::/12 and 
related routing errors":

https://www.ripe.net/ripe/mail/archives/routing-wg/2022-July/004588.html

 

Oh, that's a nice write-up. I must admit that it didn't occur to me that e.g 
2000::/12 was likely something much more specific, but that someone missed the 
(probably) 6, 7, or 8 at the end, even though I've done this a few times myself…

 

W

 

 

 

 

Kind regards,

Job

 

RE: AS3356 Announcing 2000::/12

[Ryan Hamel]

These as well:

3257 3356
3491 3356

They probably leaked a hold down route.

Ryan Hamel

-Original Message-
From: Christopher Morrow  
Sent: Wednesday, December 7, 2022 8:48 PM
To: r...@rkhtech.org
Cc: nanog@nanog.org
Subject: Re: AS3356 Announcing 2000::/12

On Wed, Dec 7, 2022 at 11:25 PM Ryan Hamel  wrote:
>
> AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate 
> covering over 23K prefixes (just over 25%) of the IPv6 DFZ.
>
>

interesting that this is leaking outside supposed RPKI OV boundaries as well.
For example:
  6762 3356
  2914 3356
  174 3356 (apologies to 174, I forget if they signed up to the 'doin ov now' 
plan)

AS3356 Announcing 2000::/12

[Ryan Hamel]

AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate
covering over 23K prefixes (just over 25%) of the IPv6 DFZ.

 

Prayers for anyone impacted, the team announcing it, and the team resolving
the issue.

 

Ryan Hamel

RE: Sites blocking ISP Addresses

[Ryan Hamel]

Based on experience, all I can say is good luck. They do not respond to anyone.

Ryan

 

From: NANOG  On Behalf Of James Dexter
Sent: Tuesday, November 29, 2022 8:43 AM
To: nanog@nanog.org
Subject: Sites blocking ISP Addresses

 

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: BCP38 For BGP Customers

[Ryan Hamel]

RPKI and IRR should be part of the prefix-list generation process, from there 
setup rpf-check with a fail-filter pointing to an ACL that allows source 
traffic matching the prefix-list and drops the rest. Although at that point you 
can just apply said ACL to the L3 interfaces supplying the BGP handoff.

 

Ryan

 

From: NANOG  On Behalf Of Mike Hammett
Sent: Monday, November 7, 2022 3:17 PM
To: Charles Rumford 
Cc: nanog@nanog.org
Subject: Re: BCP38 For BGP Customers

 

This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR, 
etc. instead of current BGP feed?

 

 



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

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

 

  _  

From: "Charles Rumford via NANOG" mailto:nanog@nanog.org> >
To: nanog@nanog.org <mailto:nanog@nanog.org> 
Sent: Monday, November 7, 2022 10:47:54 AM
Subject: BCP38 For BGP Customers

Hello -

I'm are currently working on getting BCP38 filtering in place for our BGP 
customers. My current plan is to use the Juniper uRPF feature to filter out 
spoofed traffic based on the routing table. The mentality would be: "If you 
don't send us the prefix, then we don't accept the traffic". This has raised 
some issues amongst our network engineers regarding multi-homed customers.

One of the issues raised was if a multi-homed BGP customer revoked a prefix 
from 
one of their peerings, but continued sending us traffic on the link then we 
would drop the traffic.

I would like to hear what others are doing for BCP38 deployments for BGP 
customers. Are you taking the stance of "if you don't send us the prefix, then 
we don't accept the traffic"? Are you putting in some kind of fall back filter 
in based on something like IRR data?

Thanks!

-- 
Charles Rumford (he/his/him)
Network Engineer | Deft
1-312-268-9342 | charl...@deft.com <mailto:charl...@deft.com> 
deft.com

 

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Ryan Rawdon]

> On Oct 10, 2022, at 6:37 PM, Matthew Petach  wrote:
> 
> 
> 
> On Mon, Oct 10, 2022 at 8:44 AM Mark Tinka  wrote:
> On 10/10/22 16:58, Edvinas Kairys wrote:
> 
> > Hello,
> >
> > We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has 
> > 24x100G, but only 2.2mln route (FIB) memory entries. In a near future 
> > it will be not enough - so we're thinking to deny all /24s to save the 
> > memory. What do you think about that approach - I know it could 
> > provide some misbehavior. But theoretically every filtered /24 could 
> > be routed via smaller prefix /23 /22 /21 or etc. But of course it 
> > could be a situation when denied /24 will not be covered by any 
> > smaller prefix.
> 
> I wouldn't bank on that.
> 
> I am confident I have seen /24's with no covering route, more so for PI 
> space from RIR's that may only be able to allocate a /24 and nothing 
> shorter.
> 
> It would be one heck of an experiment, though :-).
> 
> Mark.
> 
> 
> I may or may not have done something like this at $PREVIOUS_DAY_JOB.
> 
> We (might have) discovered some interesting brokenness on the Internet in 
> doing so; 
> in one case, a peer was sending a /20 across exchange peering sessions with 
> us, 
> along with some more specific /24s.  After filtering out the /24s, traffic 
> rightly flowed 
> to the covering /20.  Peer reached out in an outraged huff; the /24s were 
> being 
> advertised from non-backbone-connected remote sites in their network, that 
> suddenly 
> couldn't fetch content from us anymore.  Traceroutes from our side followed 
> the /20 
> back to their "core", and then died.  They explained the /24s were being 
> advertised 
> from remote sites without backbone connections to the site advertising the 
> /20, and 
> we needed to stop sending traffic to the /20, and send it directly to the /24 
> instead.
> We demurred, and let them know we were correctly following the information in 
> the 
> routing table. 

We encountered similar behavior, but not from a network desegregating their own 
address space like this.  Rather, it was a network (actually a network services 
vendor) who had a PA /24 from a colo provider that they were no longer 
interconnected with.  We had to filter /24s on transit (our network does not 
resell transit) due to issues with spanslogic inefficiency on Nexus 7k.  

When trying to turn up a demo with this vendor, connections were not 
establishing.  We found that they had an older PA /24 in the FIB but we were 
following a /20 or some such route to their old upstream/colo.  We ended up 
doing a bunch of work to find other such “possibly disconnected /24s” based 
mainly on origin ASN, and put in exceptions to our filtering until we could 
complete some hardware upgrades.

In situations like this, we of course did have functioning default routes from 
our upstream — but that doesn’t help since the /20 from a peer was attracting 
and blackholing the traffic.  As IPv4 continues to desegregate and get resold 
and otherwise optimized, I imagine this will become more common.  Not a problem 
for a multi-homed stub network with multiple default routes coming from 
upstream, unless they have peering and don’t micromanage it with this in mind.

Ryan

> They became even more huffy, insisting that we were breaking the internet by 
> not 
> following the correct routing for the more-specific /24s which were no longer 
> present 
> in our tables.  No amount of trying to explain to them that they should not 
> advertise 
> an aggregate route if no connectivity to the more specific constituents 
> existed seemed 
> to get the point across.  In their eyes, advertising the /24s meant that 
> everyone should 
> follow the more specific route to the final destination directly.
> 
> So, even seeing a 'covering route' in the table is no guarantee that you 
> won't create 
> subtle and not-so-subtle breakage when filtering out more specifics to save 
> table space.   ^_^;

+1 

> 
> Having (possibly) done this once in the past, I'd strongly recommend looking 
> for a 
> different solution--or at least be willing to arm your front-end response 
> team with 
> suitable "No, *you* broke the Internet" asbestos suits before running a git 
> commit 
> to push your changes out to all the affected devices in your network.   ;)
> 
> Matt
> 
>  

RE: AS15960 abuse contact?

[Ryan Hamel]

Might as well send it to their upstream abuse contacts and state their
customer is unresponsive.

 

Ryan

 

From: NANOG  On Behalf Of Tim
Burke
Sent: Wednesday, September 7, 2022 1:10 PM
To: nanog@nanog.org list 
Subject: AS15960 abuse contact?

 

Anyone have an abuse contact at AS15960 / bluehornet / mapp.com that doesn't
go to /dev/null? I have been getting a ridiculous amount of political spam
from them, and despite repeatedly unsubscribing and submitting abuse
complaints, the garbage increases exponentially. 

 

V/r

Tim

Are there any DNS POCs from Raytheon on here?

[Stephenson, Ryan M CIV DISA IE (USA) via NANOG]

Please reach out to me.


Ryan Stephenson
Defense Information Systems Agency
DoD NIC IE721
UE: ryan.m.stephenson2@mail.mil

RE: HE.net and BGP Communities

[Ryan Hamel]

Yes.

Ryan

-Original Message-
From: NANOG  On Behalf Of Rubens Kuhl
Sent: Sunday, July 24, 2022 12:36 PM
To: Nanog 
Subject: HE.net and BGP Communities

The last mention I found on NANOG about HE.net and BGP communities for traffic 
engineering is from April 2021 and said they provided none.

Is that still the case a year later ?


Rubens

AWS - IP Address is Blocked?

[Ryan Hamel]

Hello,

 

I have a public IP address in the Dallas area receiving HTTP 403 errors
whenever they visit ANY website powered by AWS, which is impacting quite a
significant chunk of connectivity. If anyone has a way of contacting AWS's
support team about getting this IP address removed from their block list or
explain what is happening, I would greatly appreciate if you could contact
me off list.

 

Thank you very much for your time.

 

Ryan Hamel

Re: Any sign of supply chain returning to normal?

[Ryan Wilkins]

A company I work for designs a lot of our own hardware and we’ve had a number 
of critical components go EOL suddenly and without warning, such as FPGAs, 
ADCs, clock generators, and SOMs just to name a few.  Just a few weeks ago we 
were informed that a large order of FPGAs was not going to be filled at all and 
the order was cancelled.  Of the parts that aren’t EOL (yet), many have 52-week 
lead times which is just a place holder for “we have no idea when we’ll get 
these” and not an actual delivery estimate.  Older product lines and lower 
volume product lines are being cancelled.  We had an ADC go EOL because the 
only factory in Japan making this part burned down so not necessarily related 
to what we think of as supply chain issues, but it is of a different sort.

> On Apr 22, 2022, at 8:50 AM, Joe Freeman  wrote:
> 
> 
> Basically, anything that uses Broadcom or other commodity silicon is 
> currently 55+ weeks out according to most of the vendors I work with. Custom 
> Silicon is a bit better or so I'm told, but I've not had to order much gear 
> with custom silicon lately, so I've not got a clear read on lead times there.
> 
> I wouldn't be surprised to see some recent gear go End of Sales early just 
> because of component shortages and fabs moving to produce the more in-demand 
> parts over older less profitable parts.

RE: Ukraine request yikes

[Ryan Hamel]

It’s already spread to the news - 
https://www.rollingstone.com/politics/politics-news/ukraine-icann-russia-internet-runet-disconnection-1314278/

 

Ryan

 

From: NANOG  On Behalf Of George 
Herbert
Sent: Tuesday, March 1, 2022 12:17 AM
To: Nanog 
Subject: Ukraine request yikes

 

Posted by Bill Woodcock on Twitter… 
https://twitter.com/woodyatpch/status/1498472865301098500?s=21

 

https://pastebin.com/DLbmYahS

 

Ukraine (I think I read as) want ICANN to turn root nameservers off, revoke 
address delegations, and turn off TLDs for Russia.

 

Seems… instability creating…

 

-george

Sent from my iPhone

Re: New minimum speed for US broadband connections

[Ryan Rawdon]

> On Feb 16, 2022, at 4:46 PM, Michael Thomas  wrote:
> 
> 
> On 2/16/22 1:36 PM, Josh Luthman wrote:
>> What is the embarrassment?
> That in the tech center of the world that we're so embarrassingly behind the 
> times with broadband. I'm going to get fiber in the rural Sierra Nevada 
> before Silicon Valley. In fact, I already have it, they just haven't 
> installed the NID. 
> Mike
> 
> 
I will provide another specific example albeit not San Jose but similar enough. 
 I am in  Loudoun County less than 25 minutes from Ashburn, VA.My best 
option is fixed wireless from All Points Broadband (hi Tim) which is 15/3mbit/s 
costing $199/mo (they have cheaper, slower tiers available).  

Verizon FiOS serves a dense developer-built community less than 1 mile down the 
street from me, but everyone else outside of the towns and developer-built 
communities have almost zero options.

Similar to the San Jose examples, we are near some of the most dense 
connectivity in the world.  Travel 20-30 minutes in certain directions from 
Ashburn and you’re quickly seeing farms and limited connectivity.

Ryan
>> 
>> On Wed, Feb 16, 2022 at 4:28 PM Michael Thomas > <mailto:m...@mtcc.com>> wrote:
>> 
>> On 2/16/22 1:13 PM, Josh Luthman wrote:
>>> I'll once again please ask for specific examples as I continue to see the 
>>> generic "it isn't in some parts of San Jose".
>>> 
>>> On the note of the generic area of San Jose, I'm all but certain this has a 
>>> lot to do with California and its extraordinarily complicated and near 
>>> impossible accessibility to obtain CLEC status.  This makes competition 
>>> pretty much impossible and makes the costs of operating one extraordinarily 
>>> high.  I'm obviously not going to be one that claims that government is 
>>> good or bad, just pointing out a certain correlation which could 
>>> potentially be causation.
>> Sonic has been installing fiber in San Francisco and other areas, but they 
>> are really small. Comcast can't be bothered that I've ever heard. The only 
>> other real alternative is things like Monkeybrains which is a WISP. It's 
>> really an embarrassment. 
>> Mike
>>> 
>>> On Wed, Feb 16, 2022 at 12:52 PM Owen DeLong >> <mailto:o...@delong.com>> wrote:
>>> 
>>> 
>>>> On Feb 11, 2022, at 13:14 , Josh Luthman >>> <mailto:j...@imaginenetworksllc.com>> wrote:
>>>> 
>>>> Because literally every case I've seen along these lines is someone 
>>>> complaining about the coax connection is "only 100 meg when I pay for 200 
>>>> meg".  Comcast was the most hated company and yet they factually had 
>>>> better speeds (possibly in part to their subjectively terrible customer 
>>>> service) for years.
>>>> 
>>>> >An apartment building could have cheap 1G fiber and the houses across the 
>>>> >street have no option but slow DSL.
>>>> 
>>>> Where is this example?  Or is this strictly hypothetical?
>>> 
>>> There are literally dozens (if not thousands) of such examples in silicon 
>>> valley alone.
>>> 
>>>> I am not seeing any examples, anywhere, with accurate data, where it's 
>>>> what most consider to be in town/urban and poor speeds.  The only one that 
>>>> was close was Jared and I'm pretty sure when I saw the map I wouldn't 
>>>> consider that in town (could be wrong) but again, there's gig fiber there 
>>>> now.  I don't remember if he actually got his CLEC, or why that matters, 
>>>> but there's fiber there now.
>>> 
>>> Pretty sure you would have a hard time calling San Jose “not in town”. It’s 
>>> literally #11 in the largest 200 cities in the US with a population of 
>>> 1,003,120 (954,940 in the 2010 census) and a population density of 5,642 
>>> people/sq. mile (compare to #4 Houston, TX at 3,632/Sq. Mi.).
>>> 
>>> Similar conditions exist in parts of Los Angeles, #2 on the same list at 
>>> 3,985,516 (3,795,512 in 2010 census) and 8,499/Sq. Mi.
>>> 
>>> I speak of California because it’s where I have the most information. I’m 
>>> sure this situation exists in other states as well, but I don’t have actual 
>>> data.
>>> 
>>> The simple reality is that there are three sets of incentives that 
>>> utilities tend to chase and neither of them provides for the mezzo-urban 
>>> and sub-urban parts of America…
>>> 1.  USF — Mostly supports rural deployments.
>>> 2. 

Re: junos config commit question

[Ryan Hamel]

If it's before committing the changes just run "top" to get back to the
root of the configuration tree, then "rollback 0" to go back to the version
before any changes were made, then just "exit" out.

Ryan


On Fri, Feb 11, 2022, 2:20 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <
lyn...@orthanc.ca> wrote:

> On an EX4300 switch running JunOS 14.1 let's imagine I typed
>
> config
> delete interfaces
>
> before coming to my senses.  How am I supposed to back out of that
> mess?  For the life of me, after a week of reading the 3000 page
> reference manual, and endless DuckDuckGoing, I cannot see a simple
> way of just abandoning the commit.  I've got to be missing something
> stunningly obvious here because it's unthinkable that this functionality
> doesn't exist.  Help?!?
>
> The only way out I can see is to drop into the shell, make an
> uncompressed copy of juniper.conf.gz, then pop back into the config
> editor and load that over top of the editor's config view.  Surely
> there's a saner way of dealing with this.
>
> --lyndon
>

Re: home router battery backup

[Ryan Wilkins]

When I subscribed to Windstream fiber at my house a couple years ago I didn’t 
order voice service but they installed a UPS anyway.  Curiously, they also 
connected the wires meant for voice lines to their outdoor equipment mounted on 
the house.  The guy told me he did that after he hooked it up which I was 
mildly annoyed about since I had planned to use that cable for other reasons.  
He was pushing voice service and said I was hooked up for voice should I want 
to do this in the future.  I’m unsure if this is a standard Windstream install 
or what.

To add to that, I have my own UPS installed on some of my indoor equipment.. 
router, one WiFi AP, Synology file server, x86 linux server.  While we almost 
never lose power at my house, yesterday we lost power for 7 minutes.  I 
maintained Internet connectivity throughout the brief outage.

Ryan Wilkins

> On Jan 12, 2022, at 12:35 PM, Scott T Anderson via NANOG  
> wrote:
> 
> Hi NANOG mailing list,
>  
> I am a graduate student, currently conducting research on how power outages 
> affect home Internet users. I know that the FCC has a regulation since 2015 
> (47 CFR Section 9.20) requiring ISPs to provide an option to voice customers 
> to purchase a battery backup for emergency voice services during power 
> outages. As this is only an option and only applies to customers who 
> subscribe to voice services, I was wondering if anyone had any insights on 
> the prevalence of battery backup for home modem/routers? I.e., what 
> percentage of home users actually install a battery backup in their home 
> modem/router or use an external UPS?
>  
> Thanks.
> Scott
>  
> Reference for 47 CFR Section 9.20: 
> https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-H/section-9.20
>  
> <https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-H/section-9.20>

Re: Cloudflare Abuse Contact

[Tanner Ryan via NANOG]

Hi Mike,

Please reach out to me directly.


Best,

*Tanner Ryan *| Network Engineer
Cloudflare, Inc. | as13335.peeringdb.com


On Fri, Jan 7, 2022 at 2:39 PM Jean St-Laurent via NANOG 
wrote:

> Cloudlfare might be able to help, but dns flood might be spoofed.
>
> It's possible that Cloudflare is not the one sending you that junk.
>
> Is it UDP DNS flood or it's some kind of DNS of TCP/Https?
>
> Jean
>
>
> > On 1/7/2022 11:06 AM, Mike Hale wrote:
> the issue we're seeing (a massive DNS flood).
>
>
>
>

RE: CenturyLink Fiber Latency Issues (Seattle, WA)

[Ryan Hamel]

Neel,

Sounds like buffer bloat.

Run a speed test, whatever is your maximum for your download and upload take
10% away from it, and setup traffic shaping in OPNsense
(https://docs.opnsense.org/manual/shaping.html) with those values. If the
issue goes away, then you're exceeding the buffer of CenturyLink's device
with the bursts of traffic.

Ryan

-Original Message-
From: NANOG  On Behalf Of Neel
Chauhan
Sent: Monday, November 1, 2021 6:44 PM
To: nanog@nanog.org
Subject: CenturyLink Fiber Latency Issues (Seattle, WA)

Hi NANOG Mailing List,

I don't know if any of you work at CenturyLink/Lumen, very less on their
Fiber network in Seattle, WA. However, here's my story.

If I attempt to run certain applications that use 1000, or 1 TCP
connections, I get latency spikes. It is based on how many connections, but
also how much bandwidth is used. This means certain things like Tor relays
are off limits to me (which I wish to run).

On an idle connection, the PingPlotter outputs look like this: 
https://centurylinklatencyissues.com/image-000.png

If I attempt to run BitTorrent with 1000 connections in Deluge, PingPlotter
looks like this: 
https://centurylinklatencyissues.com/image-002.png

Getting support, or even executive contacts to admit the issue hasn't
worked. They all love to blame my equipment or applications, when CL routers
also show the issue when I run the same things whereas my same exact
OPNsense box on Google Fiber Webpass running Tor at another address had no
issues whatsoever, and I can ping other Tor relays on CenturyLink AS209 just
fine (from a VPS).

The most competent person I dealt with was actually one tech. He told me
there was "capacity issues" in our neighborhood, and that's the reason for
the issues. However, nothing was done about it afterwards, I'm guessing
since I turned off my Tor relay after the visit to avoid complaints from
family members.

On an AT forum, people have said GPON gives latency spikes/packet loss on
congestion: 
https://www.dslreports.com/forum/r33242889-How-rare-is-GPON-XGSPON-saturatio
n

The capacity managers in Seattle are literally dragging their feet: it's
100x worse than AT's 802.1X. I know AT and CenturyLink don't compete,
but if I had to choose between AT Fiber and CenturyLink, I'll take AT in
a heartbeat, no ifs, no buts, even if I have to use AT's crappy router
instead of my OPNsense box.

Going back, do any of you who work at CenturyLink/Lumen can get me to the
right people, hopefully the capacity managers in Seattle?

I could go with Comcast, but it's either (a) 35 Mbps uploads or (b) $329/mo
for "Gigabit Pro" with a 2-year contract and a steep install fee. I am
seriously considering Gigabit Pro even if it breaks the bank, but hope I
won't have to go there.

I don't need 2 Gbps and would rather pay $65 than $329. 300-500 Mbps uploads
when I need it is the sweet spot for me (even without Tor) which CL GPON
should easily handle without a sweat. I also don't exactly
**trust** Comcast, they're a horrible company in many metrics, but in some
ways Comcast is more competent than CenturyLink.

Best,

Neel Chauhan

Re: Facebook post-mortems...

[Ryan Brooks]

> On Oct 5, 2021, at 10:32 AM, Jean St-Laurent via NANOG  
> wrote:
> 
> If you have some DNS working, you can point it at a static “we are down and 
> we know it” page much sooner,

At the scale of facebook that seems extremely difficult to pull off w/o most of 
their architecture online.  Imagine trying to terminate >billion sessions.

When they started to come back up and had their "We're sorry" page up- even 
their static png couldn't make it onto the wire.

Re: Facebook post-mortems...

[Ryan Landry]

Niels, you are correct about my initial tweet, which I updated in later
tweets to clarify with a hat tip to Will Hargrave as thanks for seeking
more detail.

Cheers,
Ryan

On Tue, Oct 5, 2021 at 08:24 Niels Bakker  wrote:

> * telescop...@gmail.com (Lou D) [Tue 05 Oct 2021, 15:12 CEST]:
> >Facebook stopped announcing the vast majority of their IP space to
> >the DFZ during this.
>
> People keep repeating this but I don't think it's true.
>
> It's probably based on this tweet:
> https://twitter.com/ryan505/status/1445118376339140618
>
> but that's an aggregate adding up prefix counts from many sessions.
> The total number of hosts covered by those announcements didn't vary
> by nearly as much, since to a significant extent it were more specifics
> (/24) of larger prefixes (e.g. /17) that disappeared, while those /17s
> stayed.
>
> (There were no covering prefixes for WhatsApp's NS addresses so those
> were completely unreachable from the DFZ.)
>
>
> -- Niels.
>

Re: facebook outage

[Ryan Brooks]

> On Oct 4, 2021, at 4:30 PM, Bill Woodcock  wrote:
> 
> 
> 
>> On Oct 4, 2021, at 11:21 PM, Bill Woodcock  wrote:
>> 
>> 
>> 
>>> On Oct 4, 2021, at 11:10 PM, Bill Woodcock  wrote:
>>> 
>>> They’re starting to pick themselves back up off the floor in the last two 
>>> or three minutes.  A few answers getting out.  I imagine it’ll take a while 
>>> before things stabilize, though.
>> 
>> nd we’re back:
>> 
>> WoodyNet-2:.ssh woody$ dig www.facebook.com @9.9.9.9
> 
> So that was, what…  15:50 UTC to 21:05 UTC, more or less…  five hours and 
> fifteen minutes.
> 
> That’s a lot of hair burnt all the way to the scalp, and some third-degree 
> burns beyond that.
> 
> Maybe they’ll get one or two independent secondary authoritatives, so this 
> doesn’t happen again.  :-)
> 

DNS was a victim in this outage, not the cause.

>-Bill

Re: IPv6 woes - RFC

[Ryan Hamel]

Jeroen,

> You people keep on giving money to ISPs that are not providing the
service you want.

Not everyone has the luxury of picking their ISP, and the common consumer
doesn't know or care about IPv6. They want Netflix to work and that's it.

Ryan


On Sat, Sep 4, 2021, 1:47 PM Jeroen Massar via NANOG 
wrote:

>
> > On 20210904, at 22:26, Grant Taylor via NANOG  wrote:
> >
> > Hi,
> >
> > Does anyone have any recommendation for a viable IPv6 tunnel broker /
> provider in the U.S.A. /other/ /than/ Hurricane Electric?
>
> SixXS shut down 4 years ago, to get ISPs to move their butts... as long as
> there are tunnels, they do not have a business case.
>
> See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6"
> thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along
> with plans.
>
> You people keep on giving money to ISPs that are not providing the service
> you want.
>
> > I reluctantly just disabled IPv6 on my home network, provided by
> Hurricane Electric, because multiple services my wife uses are objecting to
> H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO
> Max, Pandora, and other services that I can't remember at the moment have
> all objected to H.E
>
> Tunnels are VPNs
>
> So, that makes sense that services that need to 'protect their IP' (silly
> property) because they did not figure out people might live anywhere in the
> world might want to pay for things and receive service... [sic]
>
>
> IPv6 tunnels where meant as a transition mechanism, as a way for engineers
> to test IPv6 before it was wide spread.
>
> Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave
> monopoly money and can just buy 2% of the address space), you could have
> spent the last 25 years getting ready for this day. And especially in the
> last 5 - 10 years, deploying IPv6 has been easy, due to all the work by
> many many many people around the world in testing and actively deploying
> IPv6. Of course there are still platforms that don't support DHCPv6 for
> instance, but things are easy, stable and often properly battle tested.
>
> >
> > Disabling IPv6 feels *SO* *WRONG*!  But fighting things; hacking DNS,
> null routing prefixes, firewalling, etc., seems even more wrong.
> >
> > Is there a contemporary option for home users like myself who's ISP
> doesn't offer native IPv6?
>
> As this is NANOG and people on the list are ISPs and it is 2021, thus
> IPv6 being 25+ years old, the best that is left to do is:
>
> https://www.youtube.com/watch?v=ASXJgvy3mEg
>
> Go Jared!
>
> Greets,
>  Jeroen
>
>

RE: Microsoft peering contact

[Ryan Hamel]

Tomas,

 

In the bottom left corner, there is an escalation matrix based on priority, 
depending on the issue you can work up the chain at a reasonable pace.

 

Ryan



From: NANOG  On Behalf Of Tomas Lynch
Sent: Monday, August 30, 2021 10:21 AM
To: NANOG 
Subject: Microsoft peering contact

 

Hi,

 

We have sent emails to Microsoft AS8075 peeringdb contacts but we have not 
received any answer yet. Can someone share a contact, in unicast, who can 
answer some issues with the Azure API?

 

Thanks,

 

Tomas Lynch

BGP - Traffic Management

[Ryan Hamel]

Hello,

 

Does anyone know of any US carriers that will accept more specific routes
other than what's required for the DFZ, like "le 31" or "upto /31" (junos
speak) ? I know Zayo supports this internally but would like to know of
other carriers for redundancy.

 

I am currently dealing with a network that has per region assigned public IP
blocks. I would like to see about moving to announcing aggregates to the
carriers across the MPLS network and redistributing more specifics from iBGP
to the carriers to get the traffic where it needs to be. In a failover
situation these more specifics are also visible on an MPLS backbone where
other transit routers will prepend the AS path upstream based on specific
communities to prevent anycast routing.

 

Thanks,

 

Ryan

Equinix Sales Rep

[Ryan Finnesey via NANOG]

I know this might flood my inbox on a Friday, but I am looking for 
recommendations on  sales rep at Equinix that understand the carrier space.  I 
need to find out more information about their Equinix Fabric product and it has 
been about 10 years since I have worked with Equinix

Verizon’s ESInet

[Ryan Finnesey via NANOG]

Would someone from Verizon or someone familiar with Verizon’s ESInet please 
contact me off list .

Ryan

RE: VoP regulatory consultant

[Ryan Finnesey via NANOG]

Thanks Tim.  I have been a member of that listserv for years.  It is very US 
focused.  That’s why I thought I would ask the larger NANOG community.  

Ryan


-Original Message-
From: Tim Nelson  
Sent: Friday, July 9, 2021 9:28 AM
To: Ryan Finnesey 
Cc: nanog@nanog.org
Subject: Re: VoP regulatory consultant

Check the VoiceOps mailing list:  http://voiceops.org/

--Tim

On Fri, Jul 9, 2021 at 8:06 AM Ryan Finnesey via NANOG  wrote:
>
> Would anyone have any recommendations on regulatory consultants for VoIP 
> within North America but markets outside the US?
>
> Get Outlook for iOS

RE: SITR/SHAKEN implementation in effect today (June 30 2021)

[Ryan Finnesey via NANOG]

This should help with Robo calls a lot.

-Original Message-
From: NANOG  On Behalf Of 
Sean Donelan
Sent: Wednesday, June 30, 2021 2:31 PM
To: nanog@nanog.org
Subject: SITR/SHAKEN implementation in effect today (June 30 2021)


STIR/SHAKEN Broadly Implemented Starting Today 
https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today

WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel today 
announced that the largest voice service providers are now using STIR/SHAKEN 
caller ID authentication standards in their IP networks, in accordance with the 
deadline set by the FCC. This widespread implementation helps protect consumers 
against malicious spoofed robocalls and helps law enforcement track bad actors. 
The STIR/SHAKEN standards serve as a common digital language used by phone 
networks, allowing valid information to pass from provider to provider which, 
among other things, informs blocking tools of possible suspicious calls.

RE: Email and Web Hosting

[Ryan Finnesey via NANOG]

If the client base wants to stick with basic IMAP/POP3 email Tucows/OpenSRS has 
a good platform.  Also a few years ago my company migrated business email 
accounts and domains from an ISP and moved them to Office 365 and did a revenue 
share with the ISP.  They where happy still got a bit of revenue  but did not 
have to support it.

Ryan


From: NANOG  On Behalf Of 
Steve Saner
Sent: Tuesday, July 6, 2021 10:42 AM
To: nanog@nanog.org
Subject: Email and Web Hosting

I hope this isn't too far off topic for this list.

We acquired a small ISP a couple years ago that has its roots in the "local 
ISPs" of the 90s. This ISP is still hosting email and web services for 
customers both on company domains as well as customer domains. There is some 
decent revenue coming from these services, but cost of maintenance is becoming 
a challenge. We are looking at migrating to another platform or completely 
discontinuing those services.

I'm wondering if others here have gone through that process and have any advice 
as to how to go about it.

--

Steve Saner | Senior Network Engineer

ideatek INTERNET FREEDOM FOR ALL

Cell: 620-860-9433 | 111 Old Mill Lane, Buhler, KS 67522 | 
ideatek.com<http://www.ideatek.com/>

This email transmission and any documents, files or previous email messages 
attached to it may contain confidential information. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you are not or believe you may not be the intended recipient, 
please advise the sender immediately by return email or by calling 
620.543.5026. Then, please take all steps necessary to permanently delete the 
email and all attachments from your computer system. No trees were affected by 
this transmission – though a few billion photons were mildly inconvenienced.

RE: Email and Web Hosting

[Ryan Finnesey via NANOG]

Tucows/OpenSRS works well for “ISP email”

From: NANOG  On Behalf Of 
K. Scott Helms
Sent: Tuesday, July 6, 2021 11:14 AM
To: Steve Saner 
Cc: NANOG list 
Subject: Re: Email and Web Hosting

Two decent options, one on prem and the other fully hosted.

Tucows/OpenSRS has a fully hosted email offering that was built for ISPs to 
resell.  (They also have domain registration and some other ISP focused 
services.)

https://opensrs.com/services/hosted-email/

MagicMail is an email (including webmail) suite that you run on prem.  It is 
comparatively inexpensive but also fully supported.  It's built largely on 
qmail, but they replaced some of the components to deal with spam and virus 
filtering more efficiently.

https://www.magicmail.com/

I have direct experience with both and have used them both for ISPs 
specifically.

Scott Helms


On Tue, Jul 6, 2021 at 10:44 AM Steve Saner 
mailto:ssa...@ideatek.com>> wrote:
I hope this isn't too far off topic for this list.

We acquired a small ISP a couple years ago that has its roots in the "local 
ISPs" of the 90s. This ISP is still hosting email and web services for 
customers both on company domains as well as customer domains. There is some 
decent revenue coming from these services, but cost of maintenance is becoming 
a challenge. We are looking at migrating to another platform or completely 
discontinuing those services.

I'm wondering if others here have gone through that process and have any advice 
as to how to go about it.

--

Steve Saner | Senior Network Engineer

ideatek INTERNET FREEDOM FOR ALL

Cell: 620-860-9433 | 111 Old Mill Lane, Buhler, KS 67522 | 
ideatek.com

This email transmission and any documents, files or previous email messages 
attached to it may contain confidential information. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you are not or believe you may not be the intended recipient, 
please advise the sender immediately by return email or by calling 
620.543.5026. Then, please take all steps necessary to permanently delete the 
email and all attachments from your computer system. No trees were affected by 
this transmission – though a few billion photons were mildly inconvenienced.

VoP regulatory consultant

[Ryan Finnesey via NANOG]

Would anyone have any recommendations on regulatory consultants for VoIP within 
North America but markets outside the US?

Get Outlook for iOS

RE: MPLS/MEF Switches and NIDs

[Ryan Hamel]

At a few sites of mine, I’ve seen Cisco NCS 520 devices for local in-rack 
deployments, and NCS 540’s for aggregation and extension handoffs. Looking at 
their datasheets real fast, MPLS + EVPN support come in on the 540 series.

 

Ryan

 

From: NANOG  On Behalf Of Shawn L via 
NANOG
Sent: Friday, May 28, 2021 11:50 AM
To: aar...@gvtc.com
Cc: 'NANOG' 
Subject: RE: MPLS/MEF Switches and NIDs

 

The Accedian boxes are nice, as long as you remember they're not switches or 
routers.  We've used them for specific use cases, but have to remember that 
there's things you just can't do on them.  Though things may have changed on 
them since we used them.

 

 

 

-Original Message-
From: aar...@gvtc.com <mailto:aar...@gvtc.com> 
Sent: Friday, May 28, 2021 1:31pm
To: "'Colton Conor'" mailto:colton.co...@gmail.com> >, 
"'NANOG'" mailto:nanog@nanog.org> >
Subject: RE: MPLS/MEF Switches and NIDs

Wow, ciena has the means to implement SR and MPLS services?  I mean they run 
the underlying LS IGP to signal those SID’s ??  I didn’t know that.  I may look 
at them in the future then.  I thought Ciena just did some sort of static 
mpls-tp or something…

 

We use Accedian as NID’s with SkyLight director for PAA (SLA stuff)…and uplink 
those into our network at (yester-year, Cisco ME3600’s and ASR9000’s), but now, 
ACX5048 and MX204

 

-Aaron

 

Re: MPLS/MEF Switches and NIDs

[Ryan Gasik]

I've been deploying the 7210 SAS S and Sx for a while now as MPLS PEs.
I haven't had any major issues. Mixes well with our existing Juniper
infrastructure.
--ryan

On Thu, May 27, 2021 at 6:26 AM Thomas Scott  wrote:
>
> Second vote for the Nokia 7200 line, their price points are hard to beat. The 
> 7250 was originally designed (per the Nokia reps I've talked to) to be a data 
> center switch, but I've seen more than one MSO deploy them in the field to 
> great effect. They also make fantastic satellite boxes for their 7750 
> chassis. The 7210 is definitely older, but is a fantastic little MPLS PE 
> router.
>
> SRoS is also easy to pickup, considering it was written by ex-Juniper and 
> Cisco employees (TiMetra/TiMos if I recall correctly?)
>
> - Thomas Scott | mr.thomas.sc...@gmail.com
>
>
> On Thu, May 27, 2021 at 7:10 AM Brandon Martin  
> wrote:
>>
>> On 5/26/21 12:39 PM, Colton Conor wrote:
>> > Ciena seems to have multiple options available with Segment Routing,
>> > MPLS, and streaming telemetry support. I am probably most interested
>> > in what Ciena has to offer. Has anyone deployed the 3000 or 5000
>> > product line of Ciena? How does it compare to Juniper? The Ciena 3924
>> > is sub $1000 for example, and has 4 10G ports on it.
>>
>> I've used the Ciena 3000 series switches as NIDs a fair bit and have no
>> real complaints about them aside from TAC being a bit loathe to give out
>> new versions of SAOS even when the version you've got deployed is going
>> EOL.  I've not used the MPLS functionality mostly because it's a pricey
>> software license add-on and I can get by without, but the MEF and
>> associated carrier-oriented Ethernet functionality seems to be pretty
>> much top notch in terms of feature set, stability, and configurability.
>> I mostly use the 3928 though partially because the 3924 is new enough it
>> didn't make it into my standard build-out BOM.  The 3928 does also have
>> redundant PSU (fixed, but there are two) if that matters to you.  At
>> sub-$1000, the 3924 is a good deal in comparison if it'll do what you need.
>>
>> If you've never used them, you might find the config language a bit
>> annoying in that it's more Yoda syntax than Cisco, but it's also more
>> consistent than Cisco (what isn't?), so it's got that going for it.
>> Documentation is alright.  TAC is responsive to inquiries.
>>
>> --
>> Brandon Martin
>>

any POCs for cicimar.ipn.mx available?

[Stephenson, Ryan M CIV DISA IE (USA) via NANOG]

There are some DNSSEC issues with ipn.mx. 
https://dnsviz.net/d/cicimar.ipn.mx/dnssec/

 Are there any POCs available to inform of the errors?

Ryan Stephenson 
Defense Information Systems Agency
DoD NIC IE721
COM: 614-692-5284 | DSN: 312-850-5284
UE: ryan.m.stephenson2@mail.mil
CE: ryan.m.stephenson2@mail.smil.mil
iPhone: (614) 769-1921

RE: Juniper hardware recommendation

[Ryan Hamel]

Hello!

 

We wouldn’t be able to give any sort of answer without knowing your current and 
future requirements. Each model has its own throughput classes, and sometimes a 
full on MX router isn’t required.

 

From: NANOG  On Behalf Of Javier 
Gutierrez Guerra
Sent: Friday, May 7, 2021 1:55 PM
To: nanog@nanog.org
Subject: Juniper hardware recommendation

 

Hi, 

Just out of curiosity, what would you recommend using for a core router/switch 
from Juniper?

MX208,480,10K

Datasheets show them all as very nice and powerful devices (although they do 
use a lot of rack space and side to side airflow is painful) but I’m just 
wondering here what most people use and how good or bad of an experience you 
have with it 

Thanks,

 

Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email:   guer...@westmancom.com

  

 



 

RE: DoD IP Space

[Ryan Hamel]

Mel,

I hope you're not implementing this in an ISP network, it's not net neutral if 
a carrier is making a (political) route/filtering decision. (Points to The 
Great Firewall of China)

Ryan

-Original Message-
From: NANOG  On Behalf Of Mel Beckman
Sent: Saturday, April 24, 2021 4:17 PM
To: William Herrin 
Cc: nanog@nanog.org
Subject: Re: DoD IP Space

Bill,

It’s the INTERNET that is civilian, not the IP space. As long as that IP space 
was isolated to the .mil network, it was private space, as far as the Internet 
was concerned. Now DoD has moved it into the civilian Internet, and I treat 
them as potentially malicious as I do any other organization that lies, cheats, 
and steals the public trust.

 -mel

> On Apr 24, 2021, at 3:45 PM, William Herrin  wrote:
> 
> On Sat, Apr 24, 2021 at 8:26 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.
> 
> You do understand that the addresses in question are not and have 
> never been "civilian." They came into DoD's possession when this was 
> all still a military project funded by what's now DARPA.
> 
> Personally, I think we may have an all time record for the largest 
> honeypot ever constructed. I'd love to be a fly on that wall.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

RE: Twitter is down (What a shame)

[Ryan Hamel]

Twitter works for me on desktop and mobile.

 

From: NANOG  On Behalf Of ADNS NetBSD 
List Subscriber
Sent: Friday, April 16, 2021 5:23 PM
To: nanog@nanog.org
Subject: Twitter is down (What a shame)

 

Looks like backend is down – main page loads, no content.

 

Does this mean we return to a normal life?

RE: Suspicious IP reporting

[Ryan Hamel]

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 mailto:administra...@rkhtech.org> > 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 anything malicious about an IP address on the Internet, unless it 
does harm to us specifically, otherwise it is false reporting and does create 
more noise at the ISP, and waste more time getting to the underlying issue.

 

Ryan

 

From: NANOG mailto:rkhtech@nanog.org> > On Behalf Of JoeSox
Sent: Thursday, February 4, 2021 4:41 PM
To: TJ Trout mailto:t...@pcguys.us> >
Cc: NANOG mailto:nanog@nanog.org> >
Subject: Re: Suspicious IP reporting

 

Do others see this online bully started by Tom? The leader has spoken so the 
minions follow :)

This list  sometimes 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 mailto:t...@pcguys.us> 
> 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 mailto:joe...@gmail.com> > 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 <mailto:ab...@4cloud.mobi> ; ab...@fiberinternet.bg 
<mailto:ab...@fiberinternet.bg> 

 

https://en.asytech.cn/check-ip/79.124.62.25#gsc.tab=0

 

--

Thank You,

Joe

RE: Suspicious IP reporting

[Ryan Hamel]

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 anything malicious about an IP address on the Internet, unless it 
does harm to us specifically, otherwise it is false reporting and does create 
more noise at the ISP, and waste more time getting to the underlying issue.

 

Ryan

 

From: NANOG  On Behalf Of JoeSox
Sent: Thursday, February 4, 2021 4:41 PM
To: TJ Trout 
Cc: NANOG 
Subject: Re: Suspicious IP reporting

 

Do others see this online bully started by Tom? The leader has spoken so the 
minions follow :)

This list  sometimes 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 mailto:t...@pcguys.us> 
> 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 mailto:joe...@gmail.com> > 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 <mailto:ab...@4cloud.mobi> ; ab...@fiberinternet.bg 
<mailto:ab...@fiberinternet.bg> 

 

https://en.asytech.cn/check-ip/79.124.62.25#gsc.tab=0

 

--

Thank You,

Joe

Re: Any2 Los Angeles down again

[Ryan Landry]

If you haven't already, I encourage you to subscribe to Coresite's
maintenance notifications. Not sure it needs to be duplicated as a
notification service to nanog@.

//
Status: Scheduled
Risk: Interruption to primary connectivity
MaintenanceType: Emergency Maintenance
Reason for Work: Network Engineering will be performing emergency linecard
reloads on our core switches in the LA market in order to alleviate issues
caused by software bugs. When the reloads complete, we will bring the route
server interfaces back online. We disabled the route server interfaces in
attempt to mitigate any potential traffic blackholing due to the MAC
learning bug.

Risk Mitigation: Best practice and procedures will be employed throughout
this event and we would like to ensure that all relevant tenants are aware
of the activity.
//

On Wed, Jan 27, 2021 at 2:53 AM Siyuan Miao  wrote:

> Down again.
>
> On Wed, Jan 27, 2021 at 12:19 AM Mike Lyon  wrote:
>
>> Isn’t ANY2 LA collapsing  VLANs today? They sent a notice out about it
>> yesterday AM.
>>
>> -Mike
>>
>> On Jan 26, 2021, at 04:55, Mike Hammett  wrote:
>>
>> 
>> And instead of building out in LA where there's an obvious need, DE-CIX
>> chose Chicago, where there are already several IXes running.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Bob Purdon" 
>> *To: *"Siyuan Miao" , "North American Network
>> Operators' Group" 
>> *Sent: *Tuesday, January 26, 2021 5:59:58 AM
>> *Subject: *Re: Any2 Los Angeles down again
>>
>> On 26/01/2021 22:51, Siyuan Miao wrote:
>> > Does anybody know if there's an alternative to Any2 Los Angeles
>> > with predictable uptime and enough members in LA?
>> >
>> > It's the second outage this month and we've observed at least 7
>> > outages in the past year and we didn't even receive any maintenance
>> > notice or RFO.
>>
>> Likewise, I wouldn't be adverse to exploring options - I noticed a
>> handful of peers disappear about an hour ago (most are still up).  A
>> week or so back we lost most if not all...
>>
>> Then again, we had a different IX in San Francisco stop talking LACP
>> with us out of the blue yesterday, for reasons still unknown but since
>> fixed.
>>
>>
>>

RE: Verizon FiOS/Google Peering Issues in Northeast?

[Ryan Hamel]

They’re saying it’s a fiber cut in Brooklyn. 
https://twitter.com/VerizonSupport/status/1354109889572982786 Would be 
interesting to see the RFO on this.

 

Ryan

 

From: NANOG  On Behalf Of Robert Webb
Sent: Tuesday, January 26, 2021 9:14 AM
To: Brian Loveland 
Cc: North American Network Operators Group 
Subject: Re: Verizon FiOS/Google Peering Issues in Northeast?

 

Looks like our emails crossed. Getting lots of employees, all on Verizon, 
complaining about internet drops.

 

On Tue, Jan 26, 2021 at 12:08 PM Brian Loveland mailto:br...@bloveland.com> > wrote:

Is this well known?  Getting lots of reports of 50% packet loss to anything 
behind AS15169 from FiOS, including 8.8.8.8

RE: Verizon FiOS/Google Peering Issues in Northeast?

[Ryan Hamel]

Brian,

It’s an overall Verizon issue, they say it’s a fiber cut in Brooklyn 
https://twitter.com/VerizonSupport/status/1354109889572982786?s=20, but that 
would be a single point of failure. Quite a discussion on the outages mailing 
list.

 

Ryan

 

From: NANOG  On Behalf Of Brian 
Loveland
Sent: Tuesday, January 26, 2021 9:07 AM
To: North American Network Operators Group 
Subject: Verizon FiOS/Google Peering Issues in Northeast?

 

Is this well known?  Getting lots of reports of 50% packet loss to anything 
behind AS15169 from FiOS, including 8.8.8.8

Re: Global Peer Exchange

[Ryan Hamel]

That's Cogent for ya.

Ryan

On Mon, Nov 30, 2020, 10:14 AM Paul Emmons  wrote:

>
> You take down a 10g connection and they bill each side $.2 a meg, 95th
>> percintile billing.  VLAN between the two sites. Both sites have to have a
>> different AS number.  So if you want to move 1g of data, 95th percentile,
>> between 2 datacenters I guess it has some utility at $400 a gig effective
>> pricing.   I can't beleive it is a great money maker for them. Oh and it's
>> Cogent and they say they can't give you above 1500 mtu.
>
> ~P
>

Re: Telia Not Withdrawing v6 Routes

[Ryan Hamel]

This same issue happened in Los Angeles a number of years ago, but for IPv4 and 
v6. They need to setup sane BGP timers, and/or advocate the use of BFD for BGP 
sessions both customer facing and internal.

Ryan
On Nov 15 2020, at 5:58 pm, Matt Corallo  wrote:
> Has anyone else experienced issues where Telia won't withdraw (though will 
> happily accept an overriding) prefixes for
> the past week, at least?
>
> eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, 
> has not been announced for a few days at
> least, but shows up in Telia's LG and RIPE RIS as transiting Telia. Telia's 
> LG traceroute doesn't of course, go
> anywhere, traces die immediately after a hop or with a !N.
>
> Wouldn't be a problem except that I needed to withdraw another route due to a 
> separate issue which wouldn't budge out of
> Telia's tables until it was replaced with something else of higher pref.
>
> Matt

Re: Asus wifi AP re-writing DNS packets

[Ryan Hamel]

I'm curious to know why they would add such a thing, and how you got the 
iptables rules from the device. Do these Asus routers provide SSH directly into 
the shell?

Ryan
On Oct 28 2020, at 11:33 am, Anurag Bhatia  wrote:
> Hello,
>
> Wondering anyone from Asus here or anyone who could connect me to the 
> developers there?
>
> Using Asus RT-AC58U in Access Point(AP) mode and expect it to simply bridge 
> wired with wireless but seems like it's re-writing DNS packets source as well 
> as the destination.
>
> DNS port 53 traffic going out, the source is re-written with the management 
> IP of the AP on the LAN. So virtually all DNS traffic hits the router from 
> the (management) IP of the Asus AP instead of real clients.
> If I define DNS as x.x.x.x on DHCP, the Asus AP picks that up and re-writes 
> destination to x.x.x.x and hence even if any client uses y.y.y.y, the packets 
> are simply re-written.
>
> I see the rule in iptables on Asus AP. All these issues give an idea that 
> someone created AP mode (besides regular routing mode) and missed to disable 
> the DNS related NATing features in the AP mode. So far my discussions with 
> their support have been going quite slow and would greatly appreciate if 
> someone could connect me to right folks in there so they can release a 
> firmware fix for it.
>
>
>
> Thanks.
>
> --
> Anurag Bhatia
>
> anuragbhatia.com (http://anuragbhatia.com)
>
>
>
>
>
>
>

Amazon Prime Video Contact?

[Ryan Gard]

Hello,

I'm looking to catch someone off list who could look into some issues we're
noticing since yesterday evening with some of our residential IP blocks
being marked as a VPN or Proxying service.

Unfortunately, our old contact for this may no longer be with the company.

Alternatively, if anybody has dealt with this more recently and has had
success in resolving this issue quickly, I'm all ears!

Regards,

-- 
Ryan Gard

Re: Looking for a contact at Twitter

[Ryan Sommers]

Feel free to send me an email, rsomm...@twitter.com!

(off the top of my head, we use an external vendor for some geolocation,
not sure if it's applicable to this situation though.)

R

On Fri, Oct 16, 2020 at 9:12 AM Mike Hammett  wrote:

> If you get a response from Twitter with where to go, let me know so I can
> add it to our list.
>
> http://thebrotherswisp.com/index.php/geo-and-vpn/
>
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
> <https://www.facebook.com/ICSIL>
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
> <https://www.linkedin.com/company/intelligent-computing-solutions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
> *From: *"Ariën Vijn via NANOG" 
> *To: *nanog@nanog.org
> *Sent: *Wednesday, October 14, 2020 3:44:58 PM
> *Subject: *Looking for a contact at Twitter
>
> Greetings,
>
> I am looking for somebody working for Twitter. I am working for a small
> ISP in the Netherlands (AS 206238).
>
> Our problem is that Twitter's geolocation database still situates some our
> IPv4 blocks in the United Arab Emirates. This renders Twitter unusable for
> some of our customers.
>
> We are looking for somebody that can help us with this Please contact me
> outside the ML.
>
> Thanks in advance,
>
> -- Ariën
>
>
>
>
>

-- 
Ryan P Sommers
ry...@rpsommers.com

Re: cheap MPLS router recommendations

[Ryan Hamel]

It can handle a few full tables, but the performance of an MX80/MX104 is nearly 
the same as the EX4200 switch.

Ryan
On Oct 16 2020, at 4:41 pm, Tony Wicks  wrote:
> Well, there is always the MX104 (if you want redundancy) or MX80 if you 
> don’t. That will give you 80gig wire speed just don’t load it up with more 
> than one full table.
>
>
> From: adamv0...@netconsultings.com 
> Sent: Saturday, 17 October 2020 10:57 am
> To: 'Tony Wicks' 
> Cc: nanog@nanog.org
> Subject: RE: cheap MPLS router recommendations
>
>
>
>
>
> For this particular gig even the MX204 would be overkill in terms of price as 
> well as performance.
> Ideally something like 204 but with only those 8 10/1G ports (i.e. without 
> the 4x100G ports)
>
> adam
> From: Tony Wicks mailto:t...@wicks.co.nz)>
> Sent: Friday, October 16, 2020 10:36 PM
> To: adamv0...@netconsultings.com (mailto:adamv0...@netconsultings.com)
> Cc: nanog@nanog.org (mailto:nanog@nanog.org)
> Subject: RE: cheap MPLS router recommendations
>
>
>
>
>
> Juniper MX204, easy

Re: Cogent Layer 2

[Ryan Hamel]

> Do you want your martini emulated backbone link to fail when operator 
> reroutes their own LSR-LSR link failure?
As I said, it's an acceptable loss for my employers network, as we have a BGP 
failover mechanism in place that works perfectly.

> So you're dropping in every edge all UDP packets towards these three ports? 
> Your customers may not appreciate.
You must not be familiar with JUNOS' ACL handling. This would be applied to 
interface lo0, which is specifically for control planes. No data plane traffic 
to customers would be hit.

Ryan
On Oct 15 2020, at 1:03 am, Saku Ytti  wrote:
> On Thu, 15 Oct 2020 at 10:28, Ryan Hamel  wrote:
>
> > My experience with multiple carriers is that reroutes happen in under a 
> > minute but rarely happen, I also have redundant backup circuits to another 
> > datacenter, so no traffic is truly lost. If an outage lasts longer than 5 
> > minutes, or it's flapping very frequently, then I call the carrier. Last 
> > mile carriers install CPE equipment at the sites, which makes BFD a 
> > requirement to account for the fiber uplink on it going down, or an issue 
> > upstream.
> I think I may have spoken ambiguously and confusingly based on that
> statement. Rerouting inside operator network, such as their LSR-LSR
> link dropping is ostensibly invisible to the customer, can be tens of
> milliseconds outage can be 10s outage.
> Do you want your martini emulated backbone link to fail when operator
> reroutes their own LSR-LSR link failure?
>
> > As for security vulnerabilities, none can be leveraged if they are using 
> > internal IPs, and if not, a quick ACL can drop BFD traffic from unknown 
> > sources the same way BGP sessions are filtered.
> > In Juniper speak, the ACL would look like:
> > term deny_bfd {
> > from {
> > protocol udp;
> > destination-port [ 3784 3785 4784 ];
> > }
> > then discard;
>
> So you're dropping in every edge all UDP packets towards these three
> ports? Your customers may not appreciate.
>
> --
> ++ytti
>

Re: Cogent Layer 2

[Ryan Hamel]

Saku,

My experience with multiple carriers is that reroutes happen in under a minute 
but rarely happen, I also have redundant backup circuits to another datacenter, 
so no traffic is truly lost. If an outage lasts longer than 5 minutes, or it's 
flapping very frequently, then I call the carrier. Last mile carriers install 
CPE equipment at the sites, which makes BFD a requirement to account for the 
fiber uplink on it going down, or an issue upstream.
As for security vulnerabilities, none can be leveraged if they are using 
internal IPs, and if not, a quick ACL can drop BFD traffic from unknown sources 
the same way BGP sessions are filtered.
In Juniper speak, the ACL would look like:
(under policy-options)
prefix-list bgp_hosts {
apply-path "protocols bgp group <*> neighbor <*>";
}

(under firewall family inet(6) filter mgmt_acl)
term allow_bfd {
from {
protocol udp;
destination-port [ 3784 3785 4784 ];
source-prefix-list bgp_hosts;
}
then accept;
}
term deny_bfd {
from {
protocol udp;
destination-port [ 3784 3785 4784 ];
}
then discard;
}

Ryan
On Oct 14 2020, at 11:29 pm, Saku Ytti  wrote:
> On Thu, 15 Oct 2020 at 09:11, Ryan Hamel  (mailto:r...@rkhtech.org)> wrote:
>
>
> > Yep. Make sure you run BFD with your peering protocols, to catch outages 
> > very quickly.
>
> Make sure you get higher availability with BFD than without it, it is easy to 
> get this wrong and end up losing availability.
>
> First issue is that BFD has quite a lot of bug surface, because unlike most 
> of your control-plane protocols, BFD is implemented in your NPU ucode when 
> done right.
> We've had the entire linecard down on ASR9k due to BFD, their BFD-of-death 
> packet you can send over the internet to crash JNPR FPC.
> When done in a control-plane, poor scheduling can cause false positives more 
> often than it protects from actual outages (CISCO7600).
>
> In a world where BFD is perfect you still need to consider what you are 
> protecting yourself from, so you bought Martini from someone and run your 
> backbone over that Martini. What is an outage? Is your provider IGP rerouting 
> due to backbone outage an outage to you? Or would you rather the provider 
> convergees their network and you don't converge, you take the outage?
> If provider rerouting is not an outage, you need to know what their SLA is 
> regarding rerouting time and make BFD less aggressive than that. If provider 
> rerouting is an outage, you can of course run as aggressive timers as you 
> want, but you probably have lower availability than without BFD.
>
> Also, don't add complexity to solve problems you don't have. If you don't 
> know if BFD improved your availability, you didn't need it.
> Networking is full of belief practices, we do things because we believe they 
> help and faux data is used often to dress the beliefs as science. The problem 
> space tends to be complex and good quality data is sparse to come by, we do 
> necessarily fly a lot by the seat of our pants, if we admit or not.
> My belief is the majority of BFD implementations in real life on average 
> reduce availability, my belief is you need frequently failing link which does 
> not propagate link-down to reliability improve availability by deploying BFD.
>
>
>
>
>
> --
> ++ytti
>

Re: Cogent Layer 2

[Ryan Hamel]

Yep. Make sure you run BFD with your peering protocols, to catch outages very 
quickly.

On Oct 14 2020, at 12:47 pm, Mike Hammett  wrote:
> I haven't heard any concerns with reliability, on-net performance (aside from 
> 2 gig flow limit) or other such things. Do they generally deliver well in 
> those regards?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions (http://www.ics-il.com/)
>
>
>
>
>
> Midwest Internet Exchange (http://www.midwest-ix.com/)
>
>
>
>
> The Brothers WISP (http://www.thebrotherswisp.com/)
>
>
>
> From: "Mike Hammett" 
> To: nanog@nanog.org
> Sent: Wednesday, October 14, 2020 12:36:39 PM
> Subject: Cogent Layer 2
>
> Are any legitimate beefs with Cogent limited to their IP policies, BGP 
> session charges, and peering disputes? Meaning, would using them for layer 2 
> be reasonable?
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions (http://www.ics-il.com/)
>
>
>
>
>
> Midwest Internet Exchange (http://www.midwest-ix.com/)
>
>
>
>
> The Brothers WISP (http://www.thebrotherswisp.com/)
>
>
>
>
>
>

Re: Cogent Layer 2

[Ryan Hamel]

Hibernia's implementation must of made scaling in terms of VLAN allocations, 
and programming all the equipment in path (with possibly no redundancy), very 
difficult to manage. Any link can be saturated no matter if it is layer 2 or 3. 
If you want dedicated bandwidth with an SLA, you have to pay for it.

Ryan
On Oct 14 2020, at 11:28 am, Rod Beck  wrote:
>
> Hibernia was offering Switched Ethernet 'everywhere' long before it had a 
> Layer 3 network. So I am a bit skeptical. In fact, in the 'old days' 
> 2006-2011 we had a nice packet over SDH service that has all the performance 
> of SDH with all the functionality of Ethernet. Very popular service. 
> Unfortunately, management replaced with Switched Ethernet, which many 
> customers distrusted because of potential overbooking issues.
>
>
> From: Ryan Hamel 
> Sent: Wednesday, October 14, 2020 8:22 PM
> To: Rod Beck 
> Cc: Mike Hammett ; nanog@nanog.org 
> Subject: Re: Cogent Layer 2
>
>
> All carrier Ethernet services are tunnels provided by VPLS Psuedowire or 
> VXLAN services. Did you really expect a VLAN to be layer 2 switched 
> everywhere?
>
> Ryan
> On Oct 14 2020, at 11:03 am, Rod Beck  wrote:
> >
> > I always heard this service was really Layer 3 disguised as Layer 2.
> >
> >
> > From: NANOG  on 
> > behalf of Ryan Hamel 
> > Sent: Wednesday, October 14, 2020 7:54 PM
> > To: Mike Hammett 
> > Cc: nanog@nanog.org 
> > Subject: Re: Cogent Layer 2
> >
> >
> > Mike,
> >
> > Layer 2 is fine once it works.
> > You will have to put up with whatever VLAN tags they pick, if you plan on 
> > having multiple virtual circuits on a 10G hub.
> > They do like to see into the flows of traffic, as they only allow up to 
> > 2Gbits/flow, per there legacy infrastructure.
> >
> > If the circuit doesn't work on turn up (which is more than likely), you'll 
> > have to be abrasive with their NOC and demand escalations.
> >
> >
> > IMO, if it's 1Gbit or less per circuit and can deal with ^, you're fine, 
> > otherwise look for another carrier.
> >
> > -
> > Below is what I got from Cogent about their layer 2:
> > We offer Ethernet over MPLS transport utilizing Cisco FAT Pseudowire (Flow 
> > Aware Transport). Our service is a fully protected service, so if we suffer 
> > a fiber cut or other disruption along the primary path, our IS-IS IP 
> > fast-reroute enabled MPLS backbone will swing all traffic over to another 
> > pre-determined path across our backbone with usually no packet loss or 
> > disruption in service.
> > In order for our service to work correctly and provide the automatic 
> > redundancy, we need to verify that the traffic traversing the network can 
> > be hashed correctly by our routers. For this to happen, Cogent has to see 
> > the src-dst IP address or if you are running MPLS over the circuit, we need 
> > to see your MPLS labels. The hashing works by placing each flow of data on 
> > a separate 10GE or 100GE interface between the routers, so that traffic is 
> > evenly dispersed across all available capacity along the path. A flow is 
> > defined as a src-dst IP pair or a customer MPLS label, so the more IP pairs 
> > or MPLS labels, the better the traffic load-balances. Cogent has decided to 
> > impose a 2Gbps/flow restriction for our own traffic engineering purposes, 
> > which aim to make sure that no single customer can overrun a 10GE interface 
> > anywhere on our network (since we do not sell 10GE Wave services).
> > The reason we have the limitation in place is for our own traffic 
> > engineering purposes, which aims to make sure that no single customer can 
> > overrun a 10GE interface anywhere on our network (since we do not sell 10GE 
> > Wave services). Since most uplinks between routers are Nx10GE or Nx100GE, 
> > we want to make sure that all customer traffic can be load-balanced across 
> > the uplink capacity evenly, which makes it easier to reroute traffic in the 
> > event of a fiber cut or other disruption. One would think that with 100GE 
> > interfaces, it would not be possible to overrun the interface if we allowed 
> > full 10Gbps/flow, however most 100GE interfaces, at the chip level are 
> > broken down into 10Gbps lanes and the interfaces do not have a way to 
> > easily determine that a lane through the interface is at capacity, so as 
> > new flows enter the interface, they could get allocated to a lane that is 
> > already full and therefore experience packet loss.
> > So that we can complete our technical review for this request, need the 
> > following questions answered:
>

Re: Cogent Layer 2

[Ryan Hamel]

All carrier Ethernet services are tunnels provided by VPLS Psuedowire or VXLAN 
services. Did you really expect a VLAN to be layer 2 switched everywhere?

Ryan
On Oct 14 2020, at 11:03 am, Rod Beck  wrote:
>
> I always heard this service was really Layer 3 disguised as Layer 2.
>
>
> From: NANOG  on 
> behalf of Ryan Hamel 
> Sent: Wednesday, October 14, 2020 7:54 PM
> To: Mike Hammett 
> Cc: nanog@nanog.org 
> Subject: Re: Cogent Layer 2
>
>
> Mike,
>
> Layer 2 is fine once it works.
> You will have to put up with whatever VLAN tags they pick, if you plan on 
> having multiple virtual circuits on a 10G hub.
> They do like to see into the flows of traffic, as they only allow up to 
> 2Gbits/flow, per there legacy infrastructure.
>
> If the circuit doesn't work on turn up (which is more than likely), you'll 
> have to be abrasive with their NOC and demand escalations.
>
>
> IMO, if it's 1Gbit or less per circuit and can deal with ^, you're fine, 
> otherwise look for another carrier.
>
> -
> Below is what I got from Cogent about their layer 2:
> We offer Ethernet over MPLS transport utilizing Cisco FAT Pseudowire (Flow 
> Aware Transport). Our service is a fully protected service, so if we suffer a 
> fiber cut or other disruption along the primary path, our IS-IS IP 
> fast-reroute enabled MPLS backbone will swing all traffic over to another 
> pre-determined path across our backbone with usually no packet loss or 
> disruption in service.
> In order for our service to work correctly and provide the automatic 
> redundancy, we need to verify that the traffic traversing the network can be 
> hashed correctly by our routers. For this to happen, Cogent has to see the 
> src-dst IP address or if you are running MPLS over the circuit, we need to 
> see your MPLS labels. The hashing works by placing each flow of data on a 
> separate 10GE or 100GE interface between the routers, so that traffic is 
> evenly dispersed across all available capacity along the path. A flow is 
> defined as a src-dst IP pair or a customer MPLS label, so the more IP pairs 
> or MPLS labels, the better the traffic load-balances. Cogent has decided to 
> impose a 2Gbps/flow restriction for our own traffic engineering purposes, 
> which aim to make sure that no single customer can overrun a 10GE interface 
> anywhere on our network (since we do not sell 10GE Wave services).
> The reason we have the limitation in place is for our own traffic engineering 
> purposes, which aims to make sure that no single customer can overrun a 10GE 
> interface anywhere on our network (since we do not sell 10GE Wave services). 
> Since most uplinks between routers are Nx10GE or Nx100GE, we want to make 
> sure that all customer traffic can be load-balanced across the uplink 
> capacity evenly, which makes it easier to reroute traffic in the event of a 
> fiber cut or other disruption. One would think that with 100GE interfaces, it 
> would not be possible to overrun the interface if we allowed full 
> 10Gbps/flow, however most 100GE interfaces, at the chip level are broken down 
> into 10Gbps lanes and the interfaces do not have a way to easily determine 
> that a lane through the interface is at capacity, so as new flows enter the 
> interface, they could get allocated to a lane that is already full and 
> therefore experience packet loss.
> So that we can complete our technical review for this request, need the 
> following questions answered:
> 1 - What equipment will be directly connected to Cogent interface?
> 2 - How are the servers/equipment behind the edge device connected, GE or 
> 10GE interfaces?
> 3 - Will you be doing any type of tunneling or load-balancing that would hide 
> the src-dst IP addresses or MPLS labels of the servers/equipment?
> 4 - Will any single data flow (src-dst IP pair or MPLS label) be more than 
> 2Gbps?
> 5 – What is the purpose of the connection? (Internet traffic backhaul, data 
> center connectivity, replication, extending point-of-presence, etc..)
> 6 – Will you be running MACSec over our L2 service?
> 7 – Will you need to pass multiple VLANs and/or Jumbo frames?
> --
> Ryan
> On Oct 14 2020, at 10:36 am, Mike Hammett  wrote:
> > Are any legitimate beefs with Cogent limited to their IP policies, BGP 
> > session charges, and peering disputes? Meaning, would using them for layer 
> > 2 be reasonable?
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions (http://www.ics-il.com/)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Midwest Internet Exchange (http://www.midwest-ix.com/)
> >
> >
> >
> >
> >
> >
> >
> > The Brothers WISP (http://www.thebrotherswisp.com/)
> >
> >
> >
> >
> >
> >
>
>
>

Re: Cogent Layer 2

[Ryan Hamel]

Mike,

Layer 2 is fine once it works.
You will have to put up with whatever VLAN tags they pick, if you plan on 
having multiple virtual circuits on a 10G hub.
They do like to see into the flows of traffic, as they only allow up to 
2Gbits/flow, per there legacy infrastructure.

If the circuit doesn't work on turn up (which is more than likely), you'll have 
to be abrasive with their NOC and demand escalations.

IMO, if it's 1Gbit or less per circuit and can deal with ^, you're fine, 
otherwise look for another carrier.

-
Below is what I got from Cogent about their layer 2:
We offer Ethernet over MPLS transport utilizing Cisco FAT Pseudowire (Flow 
Aware Transport). Our service is a fully protected service, so if we suffer a 
fiber cut or other disruption along the primary path, our IS-IS IP fast-reroute 
enabled MPLS backbone will swing all traffic over to another pre-determined 
path across our backbone with usually no packet loss or disruption in service.
In order for our service to work correctly and provide the automatic 
redundancy, we need to verify that the traffic traversing the network can be 
hashed correctly by our routers. For this to happen, Cogent has to see the 
src-dst IP address or if you are running MPLS over the circuit, we need to see 
your MPLS labels. The hashing works by placing each flow of data on a separate 
10GE or 100GE interface between the routers, so that traffic is evenly 
dispersed across all available capacity along the path. A flow is defined as a 
src-dst IP pair or a customer MPLS label, so the more IP pairs or MPLS labels, 
the better the traffic load-balances. Cogent has decided to impose a 2Gbps/flow 
restriction for our own traffic engineering purposes, which aim to make sure 
that no single customer can overrun a 10GE interface anywhere on our network 
(since we do not sell 10GE Wave services).
The reason we have the limitation in place is for our own traffic engineering 
purposes, which aims to make sure that no single customer can overrun a 10GE 
interface anywhere on our network (since we do not sell 10GE Wave services). 
Since most uplinks between routers are Nx10GE or Nx100GE, we want to make sure 
that all customer traffic can be load-balanced across the uplink capacity 
evenly, which makes it easier to reroute traffic in the event of a fiber cut or 
other disruption. One would think that with 100GE interfaces, it would not be 
possible to overrun the interface if we allowed full 10Gbps/flow, however most 
100GE interfaces, at the chip level are broken down into 10Gbps lanes and the 
interfaces do not have a way to easily determine that a lane through the 
interface is at capacity, so as new flows enter the interface, they could get 
allocated to a lane that is already full and therefore experience packet loss.
So that we can complete our technical review for this request, need the 
following questions answered:
1 - What equipment will be directly connected to Cogent interface?
2 - How are the servers/equipment behind the edge device connected, GE or 10GE 
interfaces?
3 - Will you be doing any type of tunneling or load-balancing that would hide 
the src-dst IP addresses or MPLS labels of the servers/equipment?
4 - Will any single data flow (src-dst IP pair or MPLS label) be more than 
2Gbps?
5 – What is the purpose of the connection? (Internet traffic backhaul, data 
center connectivity, replication, extending point-of-presence, etc..)
6 – Will you be running MACSec over our L2 service?
7 – Will you need to pass multiple VLANs and/or Jumbo frames?
--
Ryan
On Oct 14 2020, at 10:36 am, Mike Hammett  wrote:
> Are any legitimate beefs with Cogent limited to their IP policies, BGP 
> session charges, and peering disputes? Meaning, would using them for layer 2 
> be reasonable?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions (http://www.ics-il.com/)
>
>
>
>
>
> Midwest Internet Exchange (http://www.midwest-ix.com/)
>
>
>
>
> The Brothers WISP (http://www.thebrotherswisp.com/)
>
>
>
>

Re: Hurricane Electric AS6939

[Ryan Hamel]

You would get better peering from Equinix IX, which includes free HE IPv4 
Peering + IPv6 Transit

Ryan
On Oct 13 2020, at 4:29 pm, Aaron Gould  wrote:
> Do y’all like HE for Internet uplink? I’m thinking about using them for 
> 100gig in Texas. It would be for my eyeballs ISP. We currently have Spectrum, 
> Telia and Cogent.
>
> -Aaron

Re: Juniper configuration recommendations/BCP

[Ryan Hamel]

There is linux happening in some devices.

https://www.juniper.net/documentation/en_US/junos/topics/concept/evo-overview.html

Ryan

On Thu, Oct 8, 2020, 4:16 PM Matt Harris  wrote:

> Matt Harris​
> | Infrastructure Lead Engineer
> 816‑256‑5446
> | Direct
> Looking for something?
> *Helpdesk Portal* <https://help.netfire.net/>
> | *Email Support* 
> | *Billing Portal* <https://my.netfire.net/>
> We build and deliver end‑to‑end IT solutions.
> On Thu, Oct 8, 2020 at 5:51 PM Chris Boyd  wrote:
>
>>
>>
>> > On Oct 8, 2020, at 10:55 AM,   wrote:
>> >
>> > JunOS is so linux based
>>
>> Um, my MX-204 says FreeBSD amd64.
>>
>
> Junos has always had a large basis coming from FreeBSD way back when.
>
> There's no Linux going on in Junos itself as far as I know, however
> Juniper does utilize Wind River Linux as an intermediary virtualization
> step for some of their virtualized products like the vSRX.
>
>

Re: IPv4 Mismanagement

[Ryan Wilkins]

I have the same thing with a service that was disconnected a couple years ago.  
Four IP blocks of /24 size are still swipped to us and we’re announcing them.  
I don’t put any customers on them and just use them for temporary things for 
fear that some day someone will want them back.

> On Oct 2, 2020, at 2:50 PM, Matt Brennan  wrote:
> 
> 
> A service I disconnected more than 2 years ago still has a /24 of their space 
> SWIPED to me. Their NOC closed the ticket I opened to remove. Unknown if it's 
> actually in use for another customer. 
> 
> I also had a conversation last week with another ISP (we were renegotiating 
> our contract) about this. The order form they sent me had multiple /28's we 
> had "given back" years ago still listed. Turns out they're still being routed 
> to us as well. 
> 
> I would bet it happens all over the place. 
> 
> -Matt
> 
> On Fri, Oct 2, 2020 at 2:00 PM Matt Hoppes  > wrote:
> I'm sitting here in the office on a Friday performing some IP 
> maintenance and I see that one of our upstreams is still filtering an IP 
> range we haven't used in years.   I dig into it a bit more and it turns 
> out a major carrier still has them SWIPed to us.
> 
> This got me curious and I dug more into IPs from back in our early days 
> and discovered there are two Tier-1 carriers we no longer do business 
> with that still have large blocks of their own IPs SWIPED and allocated 
> to us.
> 
> This is really confusing and concerning.   I know it's not the 
> end-all-be-all, but I wonder how much IPv4 exhaustion is being caused by 
> this type of IPv4 mis-management, where IPs are still shown as 
> "allocated" to a customer who hasn't used them in years.
> 
> I've seen this behavior from Frontier and CenturyLink to name just a few.
> 
> Any thoughts on this?

Re: BFD for routes learned trough Route-servers in IXPs

[Ryan Hamel]

> "How can I check if my communication against the NextHop of the routes that I 
> learn from the route-servers are OK? If it is not OK, how can I remove it 
> from my FIB?"

Install a route optimizer that constantly pings next hops, when the drop 
threshold is met, remove the routes. No one is going to open BFD to whole 
subnets, especially those they don't have peering agreements with, making this 
pointless.
> - ARP Resolution issues (CPU protection and lunatic Mikrotiks with 30 seconds 
> ARP timeout is a bombastic recipe)
CoPP is always important, and it's not just Mikrotik's with default low ARP 
timeouts.
Linux - 1 minute
Brocade - 10 minutes
Cumulus - 18 minutes
BSD distros - 20 minutes
Extreme - 20 minutes
HP - 25 minutes

> - MAC-Address Learning limitations on the transport link of the participants 
> can be a pain in the a..rm.
As you said, this issue doesn't seem important enough to warrant significant 
action. For transport, colo a switch that can handles BGP announcements, 
routes, and ARPs, then transport that across with only 2 MACs and internal 
point-to-point IP assignments.
Ryan
On Sep 15 2020, at 5:55 pm, Douglas Fischer  wrote:
> Time-to-time, in some IXP in the world some issue on the forwarding plane 
> occurs.
> When it occurs, this topic comes back.
>
> The failures are not big enough to drop the BGP sessions between IXP 
> participants and route-servers.
>
> But are enough to prejudice traffic between participants.
>
> And then the problem comes:
> "How can I check if my communication against the NextHop of the routes that I 
> learn from the route-servers are OK?
> If it is not OK, how can I remove it from my FIB?"
>
> Some other possible causes of this feeling are:
> - ARP Resolution issues
> (CPU protection and lunatic Mikrotiks with 30 seconds ARP timeout is a 
> bombastic recipe)
> - MAC-Address Learning limitations on the transport link of the participants 
> can be a pain in the a..rm.
>
>
> So, I was searching on how to solve that and I found a draft (8th release) 
> with the intention to solve that...
> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
>
>
> If understood correctly, the effective implementation of it will depend on 
> new code on any BGP engine that will want to do that check.
> It is kind of frustrating... At least 10 years after the release of RFC until 
> the refresh os every router involved in IXPs in the world.
>
>
> Some questions come:
> A) There is anything that we can do to rush this?
> B) There is any other alternative to that?
>
>
> P.S.1: I gave up of inventing crazy BGP filter polices to test reachability 
> of NextHop. The effectiveness of it can't even be compared to BFD, and almost 
> kill de processing capacity of my router.
>
> P.S.2: IMHO, the biggest downside of those problems is the evasion of 
> route-servers from some participants when issues described above occurs.

Re: Cogent emails

[Ryan Wilkins]

All I did was express interest a few years ago and ever since then they’ve 
called and emailed me pretty regularly.  Just got one yesterday.  I’m probably 
on the fourth sales guy now since I first asked.

Ryan Wilkins

> On Sep 14, 2020, at 3:00 PM, Jesse DuPont  
> wrote:
> 
> We started getting emails the moment we got our own AS (earlier this year).

Re: Level3 DNS Issues

[Ryan O’Shea]

Thanks Rob...

Albeit intermittent, I am still seeing timeouts when trying to reach this host. 
Admittedly, it may be a transit / routing issue via BGP neighbor 3356. Yet, I’m 
not seeing any other layer 2 anomalies. I’m still investigating. I may tear 
down the peer and see if the behavior persists...

Thanks again...


Ryan O'Shea | Director of Technology | VCP6 - RHCE

CISP
419.724.5314 office
419.810.0270 cell
419.724.3547 24x7 support


From: Rob Duffy 
Sent: Thursday, September 10, 2020 9:59 AM
To: Ryan O’Shea
Cc: nanog@nanog.org
Subject: Re: Level3 DNS Issues

It works fine for me.

~ % dig google.com<http://google.com> @209.244.0.3<http://209.244.0.3> +short
172.217.5.110

On Thu, 10 Sep 2020 at 14:20, Ryan O’Shea 
mailto:ros...@cisp.com>> wrote:
Is anyone experiencing timeouts when querying 209.244.0.3?

Thanks,

Ryan O’Shea

Level3 DNS Issues

[Ryan O’Shea]

Is anyone experiencing timeouts when querying 209.244.0.3?

Thanks,

Ryan O’Shea

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ryan Hamel]

Matt,

Why are you blaming the ease of use on the vendor, for the operators lack of 
knowledge regarding BGP? That is like blaming a vehicle manufacturer for a 
person pressing the gas pedal in a car and not giving a toss about the rules of 
the road. The base foundation regarding the rules of the road mostly apply the 
same for driving a car, truck, bus, and semi/lorry truck. There is no excuse 
for ignorance just because the user interface is different (web browser vs. SSH 
client).
Adding a take on this, there are kids born after 9/11, with IP allocations and 
ASNs experimenting in the DFZ right now. If they can make it work, and not 
cause harm to other members in this community, it clearly demonstrates a lack 
of knowledge, or honest human error (which will never go away).
Anything that can be used, can be misused. With that said, why shouldn't ALL 
BGP software implementations encourage best practice? They decided RPKI 
validation was a good thing.
Ryan
On Aug 1 2020, at 4:12 pm, Matt Erculiani  wrote:
> Ryan,
>
> The reason Noction is being singled out here as opposed to other BGP speakers 
> is that it inherently breaks several BGP protection mechanisms as a means to 
> achieve its purpose. BGP was never intended to be "optimized", it was 
> intended to be stable and scalable. While i'm sure there are hundreds of 
> operators that use these optimizers without incident, they are a significant 
> paint point for the rest of the internet.
>
> They have created a platform that has the ease of use of a residential CPE, 
> but with the consequences of misuse of any DFZ platform. This allows users 
> who have little experience speaking BGP with the world to make these mistakes 
> because they don't know any better, whereas the other platforms you mention 
> require some knowledge to configure. It's not a perfect filter, but it does 
> create a barrier for the inept.
>
> Since Noction has made it easy enough to configure their software so that 
> anyone can do it, with or without experience on the DFZ, they have SOME 
> responsibility to keep their software from accidentally breaking the internet.
>
> -Matt
>
>
> On Sat, Aug 1, 2020 at 2:30 PM Ryan Hamel  (mailto:r...@rkhtech.org)> wrote:
> > Job,
> >
> > I disagree on the fact that it is not fair to the BGP implementation 
> > ecosystem, to enforce a single piece of software to activate the no-export 
> > community by default, due to ignorance from the engineer(s) implementing 
> > the solution. It should be common sense that certain routes that should be 
> > advertised beyond the local AS, just like RFC1918 routes, and more. Also, 
> > wasn't it you that said Cisco routers had a bug in ignoring NO_EXPORT? 
> > Would you go on a rant with Cisco, even if Noction add that enabled 
> > checkbox by default?
> > Why are you not on your soap box about BIRD, FRrouting, OpenBGPd, Cisco, 
> > Juniper, etc... about how they can possibly allow every day screw ups to 
> > happen, but the same options like the NO_EXPORT community are available for 
> > the engineer to use? One solution would be to implement "BGP Group/Session 
> > Profiles" (ISP/RTBH/DDOS Filtering/Route Optimizers/etc) or a "BGP Session 
> > Wizard" (ask the operator questions about their intentions), then 
> > automatically generate import and export policies based on known accepted 
> > practices.
> > Another solution could be having the BGP daemon disclose the make, model 
> > family, and exact model of hardware it is running on, to BGP peers, and add 
> > more knobs into policy creation to match said values, and take action 
> > appropriately. That would be useful in getting around vendor specific 
> > issues, as well as belt & suspenders protection.
> > Ryan
> > On Aug 1 2020, at 9:58 am, Job Snijders  > (mailto:j...@instituut.net)> wrote:
> > > On Sat, Aug 01, 2020 at 06:50:55AM -0700, Ca By wrote:
> > > > I am not normally supporting a heavy hand in regulation, but i think it 
> > > > is
> > > > fair to say Noction and similar BGP optimizers are unsafe at any speed 
> > > > and
> > > > the FTC or similar should ban them in the USA. They harm consumers and 
> > > > are
> > > > a risk to national security / critical infrastructure
> > > >
> > > > Noction and similar could have set basic defaults (no-export, only 
> > > > create
> > > > /25 bogus routes to limit scope), but they have been clear that their 
> > > > greed
> > > > to suck up traffic does not benefit from these defaults and they wont do
> > > > it.
> > >
> > > Foll

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ryan Hamel]

Job,

I disagree on the fact that it is not fair to the BGP implementation ecosystem, 
to enforce a single piece of software to activate the no-export community by 
default, due to ignorance from the engineer(s) implementing the solution. It 
should be common sense that certain routes that should be advertised beyond the 
local AS, just like RFC1918 routes, and more. Also, wasn't it you that said 
Cisco routers had a bug in ignoring NO_EXPORT? Would you go on a rant with 
Cisco, even if Noction add that enabled checkbox by default?
Why are you not on your soap box about BIRD, FRrouting, OpenBGPd, Cisco, 
Juniper, etc... about how they can possibly allow every day screw ups to 
happen, but the same options like the NO_EXPORT community are available for the 
engineer to use? One solution would be to implement "BGP Group/Session 
Profiles" (ISP/RTBH/DDOS Filtering/Route Optimizers/etc) or a "BGP Session 
Wizard" (ask the operator questions about their intentions), then automatically 
generate import and export policies based on known accepted practices.
Another solution could be having the BGP daemon disclose the make, model 
family, and exact model of hardware it is running on, to BGP peers, and add 
more knobs into policy creation to match said values, and take action 
appropriately. That would be useful in getting around vendor specific issues, 
as well as belt & suspenders protection.
Ryan
On Aug 1 2020, at 9:58 am, Job Snijders  wrote:
> On Sat, Aug 01, 2020 at 06:50:55AM -0700, Ca By wrote:
> > I am not normally supporting a heavy hand in regulation, but i think it is
> > fair to say Noction and similar BGP optimizers are unsafe at any speed and
> > the FTC or similar should ban them in the USA. They harm consumers and are
> > a risk to national security / critical infrastructure
> >
> > Noction and similar could have set basic defaults (no-export, only create
> > /25 bogus routes to limit scope), but they have been clear that their greed
> > to suck up traffic does not benefit from these defaults and they wont do
> > it.
>
> Following a large scale BGP incident in March 2015, noction made it
> possible to optionally set the well-known NO_EXPORT community on route
> advertisements originated by IRP instances.
>
> "In order to further reduce the likelihood of these problems
> occurring in the future, we will be adding a feature within Noction
> IRP to give an option to tag all the more specific prefixes that it
> generates with the BGP NO_EXPORT community. This will not be enabled
> by default [snip]"
> https://www.noction.com/blog/route-optimizers
> Mar 27, 2015
>
> Due to NO_EXPORT not being set in the default configuration, there are
> probably if not certainly many unsuspecting network engineers who end up
> deploying this software - without ever even considering - to change that
> one setting in the configuration.
>
> Fast forward a few years and a few incidents, on the topic of default
> settings, following the Cloudflare/DQE/Verizon incident:
>
> "We do have no export community support and have done for many
> years. The use of more specifics is also optional. Neither replaces
> the need for filters."
> https://twitter.com/noction/status/1143177562191011840
> Jun 24, 2019
>
> Community members responded:
> "Noction have been facilitating Internet outages for years and
> years and the best thing they can say in response is that it is
> technically possible to use their product responsibly, they just
> don't ship it that way."
> https://twitter.com/PowerDNS_Bert/status/1143252745257979905
> June 24, 2019
>
> Last year Noction stated:
> "Nobody found this leak pleasant."
> https://www.noction.com/news/incident-response
> June 26, 2019
>
> Sentiment we all can agree with, change is needed!
> As far as I know, Noction IRP is the ONLY commercially available
> off-the-shelf BGP route manipulation software which - as default - does
> NOT set the BGP well-known NO_EXPORT community on the product's route
> advertisements. This is a product design decision which causes
> collateral damage.
>
> I would like to urge Noction to reconsider their position. Seek to
> migrate the existing users to use NO_EXPORT, and release a new version
> of the IRP software which sets NO_EXPORT BY DEFAULT on all generated
> routes.
>
> Kind regards,
> Job