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: 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 
 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]
  
Virus-free.www.avast.com

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 
Cc: nanog@nanog.org; Chen, Abraham Y. 

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]

Virus-free.www.avast.com

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]
  
Virus-free.www.avast.com

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: 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: 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
>
> 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
> 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: 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
>
>   "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

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
[cid:image002.png@01D99EC2.B891B0A0]Chat with me on 
Teams

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  
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  
deft.com

 

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

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: 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: 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: 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: 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

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  
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: 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  ; ab...@fiberinternet.bg 
 

 

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

 

--

Thank You,

Joe

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)
>
>
>
>
>
>
>

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* 
> | *Email Support* 
> | *Billing Portal* 
> 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: 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: 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

Re: Curious Cloudflare DNS behavior

[Ryan Hamel]

Hey Constantine,

John came in with a technical issue. If you have nothing worthy to say about it 
specifically, it's best to keep quiet.
Thanks!
Ryan
On May 30 2020, at 11:52 am, Constantine A. Murenin  wrote:
> When you're not paying for service, you're not the customer, you're the 
> product.
>
> I don't understand why anyone, especially anyone frequenting NANOG, would use 
> Cloudflare for their DNS.
>
> Cloudflare runs a racket business, and their whole business model depends on 
> them being a monopoly; plus people buying into the vapourware that they 
> offer. When have monopolies been good for any industry? There's plenty of 
> evidence of Cloudflare 1.1.1.1 not working correctly; I'm sure one of their 
> employees (or the CTO!) will show up shortly to say otherwise!
>
> C.
> On Fri, 29 May 2020 at 12:31, John Sage  (mailto:js...@finchhaven.com)> wrote:
> > FULL DISCLOSURE: this is an end-user issue, but one that might have some
> > operational relevance, particularly if anyone from Cloudflare DNS is on
> > the list
> >
> > EXECUTIVE SUMMARY: twice in six weeks Cloudflare DNS on my new Netgear
> > Orbi cable modem/mesh WiFi hotspot has completely lost track of one (and
> > only one that I know of) prominent US domain: usbank dot com
> >
> > Internet provider: Comcast/Xfinity "Extreme Pro+"
> > Dynamic IP address via Comcast that hasn't changed in six-seven years
> > New Netgear Orbi cable modem, configured with DNS through Cloudflare
> > (1.1.1.1 and 1.0.0.1)
> >
> > Again, twice in 6 weeks Cloudflare DNS seems to loose complete track of
> > usbank dot com as a domain
> >
> > Symptoms: Firefox on Ubuntu Linux returns that little puzzled dinosaur
> > cartoon thing and "We can't seem to find this website right now"
> >
> > BUT ALSO:
> > Each one of ping, traceroute, dig and host returns
> > Host usbank . com not found: 2(SERVFAIL)
> > or some variant thereof
> > Everything else works "just fine" as the saying goes
> > And the Cloudflare DNS drop lasted for days the first time around
> > I can switch over to Google DNS (8.8.8.8 and 8.4.4.8) in the Orbi and
> > immediately fix the problem
> >
> > So. Seems odd that Cloudflare DNS would apparently loose complete track
> > of a major US domain name like usbank dot com
> >
> > Or am I missing something?
> >
> > - John
> > --
> > John Sage
> > FinchHaven Digital Photography
> > Email: js...@finchhaven.com (mailto:js...@finchhaven.com)
> > Web: https://finchhaven.smugmug.com/
> > Old web: http://www.finchhaven.com/
>
>
>

Re: Contact at Ubiquiti Networks?

[Ryan Hamel]

> Apparently EX2300/EX3400 doesn't support STP when using Virtual Chassis

Where did you find this? I'm only able to find the EX4300 mentioned in 
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/virtual-chassis-ex4300-configuring.html
I see the following listed on the feature explorer for the EX2300-VC and 
EX3400-VC at 
https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching=1
BPDU protection for spanning-tree protocols - Junos OS 15.1X53-D50
Global configuration of spanning-tree protocols - Junos OS 15.1X53-D50
Loop protection for spanning-tree protocols - Junos OS 15.1X53-D50
Root protection for spanning-tree protocols - Junos OS 15.1X53-D50

Ryan Hamel
On May 26 2020, at 11:09 pm, Phil Lavin  wrote:
> > Even the big guys like Juniper fail at basic functionality. Our brand new 
> > MX204 fails to select the correct source address when doing ARP requests 
> > and apparently that is a known will not fix.
>
> Apparently EX2300/EX3400 doesn't support STP when using Virtual Chassis and 
> QFX51XX don't support firewall filters when using VXLAN. Both cannot/will not 
> fix. How I long to be in the spend category that makes vendors care about 
> fundamental issues.

Re: RIPE NCC Executive Board election

[Ryan Hamel]

Elad,

It's those kinds of quick accusations that are damaging your reputation.
To boil your three ideas down to a sentence, they're throwing pixie dust on top 
of existing technologies, instead of embracing the current feature set that has 
existed for decades.
I mentioned BCP38 as a method around spoofed DDOS attacks on RIPE, and your 
IPv4+ idea is only keeping IPv4 around longer than it should.
IPv6 has been around for decades, and battle tested with major companies like 
Digital Equipment Corporation in the 90's. If you want your ideas to gain any 
sort of foothold, write the code demonstrating a proof of concept with a couple 
of Linux VMs, showing off the client and router changes, and release it for the 
community to play around with.
Actions speak louder than words. Just like RIPE votes, and listing your email 
address as spam.
Have a good one.
Ryan Hamel
On May 13 2020, at 2:39 pm, Christopher Morrow  wrote:
>
> On Wed, May 13, 2020 at 5:35 PM Elad Cohen  wrote:
> >
> > Another member of the illegal anonymous organization "The Spamhaus Project".
> wait, what?
> > 
> > From: Christopher Morrow 
> > Sent: Thursday, May 14, 2020 12:34 AM
> > To: Elad Cohen 
> > Cc: David Hubbard ; nanog@nanog.org 
> > 
> > Subject: Re: RIPE NCC Executive Board election
> >
> > admins, can we can this worm can back and .. get back to work ?
> > kthxbi.
> >
> > On Wed, May 13, 2020 at 5:29 PM Elad Cohen  wrote:
> > >
> > > LOL so much heat and lies from IPv6 fans that don't want IPv4+ to be 
> > > deployed.
> > > 
> > > From: NANOG  on behalf of David Hubbard 
> > > 
> > > Sent: Thursday, May 14, 2020 12:10 AM
> > > To: nanog@nanog.org 
> > > Subject: Re: RIPE NCC Executive Board election
> > >
> > >
> > > I suspect he’d want to slow adoption and push his frankestein IPv4 
> > > because any extension of IPv4 use makes the netblocks’s he’s obtained 
> > > questionable ‘ownership’ of more valuable, in theory.
> > >
> > >
> > > From: NANOG  on 
> > > behalf of Baldur Norddahl 
> > > Date: Wednesday, May 13, 2020 at 5:02 PM
> > > To: "nanog@nanog.org" 
> > > Subject: Re: RIPE NCC Executive Board election
> > >
> > >
> > >
> > > Akamai already has 15% peak IPv6 traffic:
> > >
> > >
> > > https://blogs.akamai.com/2020/02/at-21-tbps-reaching-new-levels-of-ipv6-traffic.html
> > >
> > >
> > > Some internet service providers may have more than half of their traffic 
> > > as IPv6.
> > >
> > >
> > > Some countries are now crossing more than 50% IPv6 availability:
> > >
> > >
> > > https://www.google.com/intl/en/ipv6/statistics.html
> > >
> > >
> > > Why do you think you can overtake the IPv6 train? Why would we want to 
> > > abandon the work already done?

Re: Hi-Rise Building Fiber Suggestions

[Ryan Hamel]

I do not recommend doing that, it's 30 members in a single stack. Mine was only 
two, directly connected to each other.

Treat your control plane like your L2, don't extend it farther than necessary.
Ryan
On Feb 25 2020, at 9:00 pm, Tim Požár  wrote:
>
> Also, Juniper switches will stack over fiber. I have deployed Virtual
> Chassis over multiple IDFs. The VC ports can be (and highly suggested)
> to be in a ring.
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/virtual-chassis-ex4200-overview.html
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/virtual-chassis-ex4300-configuring.html
> On 2/25/20 6:32 PM, Norman Jester wrote:
> > I’m in the process of choosing hardware
> > for a 30 story building. If anyone has experience with this I’d appreciate 
> > any tips.
> >
> > There are two fiber pairs running up the building riser. I need to put a 
> > POE switch on each floor using this fiber.
> > The idea is to cut the fiber at each floor and insert a switch and daisy 
> > chain the switches together using one pair, and using the other pair as the 
> > failover side of the ring going back to the source so if one device fails 
> > it doesn’t take the whole string down.
> > The problem here is how many switches can be strung together and I would 
> > not try more than 3 to 5. This is not something I typically do (stacking 
> > switches). I have fears of STP and/or RSTP issue stacking past Ethernet 
> > switch to switch limits (if they still exist??)
> > Is there a device with a similar protocol as the old 3com (now HP IDF) 
> > stacking capability via fiber?
> > I’d like to use something inexpensive as its to power ubiquiti wifi on each 
> > floor. Ideally if you know something I don’t about ubiquiti switches that 
> > can do this I’d appreciate knowing.
> > Norman

Re: Hi-Rise Building Fiber Suggestions

[Ryan Hamel]

How would that work to solve Norman's problem? That sounds like a lot of money 
spending, and setup time, for nothing.

Ryan
On Feb 25 2020, at 8:21 pm, Bradley Burch  wrote:
>
> Should consider DWDM or GPON and in those look at passive optical 
> technologies that can benefit the project.
> > On Feb 25, 2020, at 9:33 PM, Norman Jester  wrote:
> > I’m in the process of choosing hardware
> > for a 30 story building. If anyone has experience with this I’d appreciate 
> > any tips.
> >
> > There are two fiber pairs running up the building riser. I need to put a 
> > POE switch on each floor using this fiber.
> > The idea is to cut the fiber at each floor and insert a switch and daisy 
> > chain the switches together using one pair, and using the other pair as the 
> > failover side of the ring going back to the source so if one device fails 
> > it doesn’t take the whole string down.
> > The problem here is how many switches can be strung together and I would 
> > not try more than 3 to 5. This is not something I typically do (stacking 
> > switches). I have fears of STP and/or RSTP issue stacking past Ethernet 
> > switch to switch limits (if they still exist??)
> > Is there a device with a similar protocol as the old 3com (now HP IDF) 
> > stacking capability via fiber?
> > I’d like to use something inexpensive as its to power ubiquiti wifi on each 
> > floor. Ideally if you know something I don’t about ubiquiti switches that 
> > can do this I’d appreciate knowing.
> > Norman

Re: Hi-Rise Building Fiber Suggestions

[Ryan Hamel]

I'd say a pair of Juniper switches on each floor, with their virtual-chassis 
capability. Terminate the top/bottom floor of fiber 1 into switch 1, and the 
other into switch two. Create an LACP bond between each floors switches, tag 
the necessary VLANs, and put the VLAN SVIs onto the first pair of switches at 
the building electrical/telecom room.

The same thing can be done with MLAG across many switch vendors, but that will 
require additional configuration.
On Feb 25 2020, at 6:32 pm, Norman Jester  wrote:
>
> I’m in the process of choosing hardware
> for a 30 story building. If anyone has experience with this I’d appreciate 
> any tips.
>
> There are two fiber pairs running up the building riser. I need to put a POE 
> switch on each floor using this fiber.
> The idea is to cut the fiber at each floor and insert a switch and daisy 
> chain the switches together using one pair, and using the other pair as the 
> failover side of the ring going back to the source so if one device fails it 
> doesn’t take the whole string down.
> The problem here is how many switches can be strung together and I would not 
> try more than 3 to 5. This is not something I typically do (stacking 
> switches). I have fears of STP and/or RSTP issue stacking past Ethernet 
> switch to switch limits (if they still exist??)
> Is there a device with a similar protocol as the old 3com (now HP IDF) 
> stacking capability via fiber?
> I’d like to use something inexpensive as its to power ubiquiti wifi on each 
> floor. Ideally if you know something I don’t about ubiquiti switches that can 
> do this I’d appreciate knowing.
> Norman

Re: Jenkins amplification

[Ryan Hamel]

Jean,

Do you have facts to support this claim?

Signed,

A happy pfSense user.


On Mon, Feb 3, 2020, 12:42 PM Jean | ddostest.me via NANOG 
wrote:

> Netgate bought Pfsense and they already started to destroy it.
>
> You should consider to switch to Opnsense.
>
> On 2020-02-03 14:34, Matt Harris wrote:
> > fSense on a VM with relatively minimal resources running your VPNs
> > works very well
>

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Ryan Hamel]

Just let the old platforms ride off into the sunset as originally planned
like the SSL implementations in older JRE installs, XP, etc. You shouldn't
be holding onto the past.

Ryan

On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin 
wrote:

> On Tue, 31 Dec 2019 at 02:29, Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
>
>> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t
>> work why not either let it fall back to 1.0 or to HTTP.
>>
>> This seems like security for no valid reason.
>
>
> Exactly.  I used the wording from their own page; but I think it's
> actually misleading.  They're actually going out of their way to prevent
> users of "old Android smartphones" from accessing Wikipedia; if they did
> nothing, everyone would still be able to read happily over HTTP.
>
> C.
>

Re: Holiday route leak

[Ryan Hamel]

On Mon, Dec 30, 2019, 12:44 PM Job Snijders  wrote:

> Dear all,
>
> On Fri, Dec 27, 2019 at 04:06:24PM -0500, Christopher Morrow wrote:
> > If there are AS46844 folk listening around their eggnog ... it'd be
> > nice if you would stop leaking prefixes: https://imgur.com/a/Js0YvP2
> >
> > this from the current view at: https://bgp.he.net/AS15169#_graph6
> >
> > I believe at least: 2620:0:1000::/40
> >
> > was leaking around your noction filters.
> >
> > It is also possible that AS11878 should check their in/out filtering
> > as well, since thats' the path I see in the he.net data...
> >
> > thanks!
> > -chris
> >
> > it looks like this is a noction box doing some internal TE things and
> > leaking around filters...though normally that appears as a subnet, not
> > an exact route match, so perhaps not this time?
>
> Can anyone offer ground-truth confirmation that the Noction IRP software
> actually supports IPv6?
>
> Kind regards,
>
> Job
>

It does.

https://www.noction.com/news/noction_irp_release_14_ipv6

Ryan

>

PayPal - IP Address Blocked

[Ryan Hamel]

Hey everyone,

Can someone from PayPal who manages their IP ACLs to reach out to me,
offlist? I have an IP address that is acting like its blocked but support
is saying it's not.

Thank you in advance for your time.

Ryan Hamel

Re: Recommended DDoS mitigation appliance?

[Ryan Hamel]

Rob,

I am going to assume you want it to spit out 10G clean, what size dirty traffic 
are you expecting it to handle?
Ryan
On Nov 17 2019, at 2:18 pm, Rabbi Rob Thomas  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Hello, NANOG!
> I'm in the midst of rebuilding/upgrading our backbone and peering -
> sessions cheerfully accepted :) - and am curious what folks recommend
> in the DDoS mitigation appliance realm? Ideally it would be capable
> of 10Gbps and circa 14Mpps rate of mitigation. If you have a
> recommendation, I'd love to hear it and the reasons for it. If you
> have an alternative to an appliance that has worked well for you
> (we're a mix of Cisco and Juniper), I'm all ears.
>
> Private responses are fine, and I'm happy to summarize back to the
> list if there is interest.
>
> Thank you!
> Rob.
> - --
> Rabbi Rob Thomas Team Cymru
> "It is easy to believe in freedom of speech for those with whom we
> agree." - Leo McKern
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAl3Rx08ACgkQQ+hhYvqF
> 8o0snw/8CxTOujcodNh/huMXZaUNlMNoNRz3IoPqBiAP9BZomMz9xqlpDW/qvWBF
> xhoJ07C0O0mo5ilNjnPR308uifIBu6ylw02PshOCU06dV0afgtndxGg5AoG9npUV
> 7uCi2afWaf22dq5TwKLut8QPNNQJTRzndX88xJw9MzzoBTemxRtM7ft4H3UhJ0hv
> oKo83FCNZQt36I+GZA9GBJeXM+o0f5h0w6fhRqARzttf6brJZdXgROyIQ7jptGuZ
> N3Yrjk/8RM4XKMnYbtIwl8NS3c0nEGN3ndn+Bz7p2FE7QJrZKonk/o03dvr2kU0Y
> 7gUQliOOzV9EsptVGyLCVyDJSElvXTBaps0giEVZhdmEIDJPWvBc+93j1g7xbmti
> 27lT6+5qBmEN0oKJWxXgtw9/n1yX9vsc7tXlgYDoXGhIlszdB3baRao1tYEp8BBQ
> hTGAULRfHe94tRzvOOQUQIuhzNcK1Q4E2jU6kzBB1wJsBD4zuHk+QIJLSHBmmnka
> VNKlQ+5zP8dmSMBp6k4feqAtt3hy0Bj+34FbdQZYPutIe3VXHEjpWI3jI9vKjhtC
> g7U/9CQIjVUl2APn1IllArpUpETBlNq7dSeJNUN/4Xh+eHglUnEn/m2kFG5mizmP
> d0YvLEVe0/+WzDUz+y3KxDVP5tdJT1VM46FHIgeiB4KrWNGRPUo=
> =uuel
> -END PGP SIGNATURE-
>

Re: new BGP hijack & visibility tool “BGPalerter”

[Ryan Hamel]

Job,

I appreciate the effort and the intent behind this project, but why should
the community contribute to an open source project on GitHub that is mainly
powered by a closed source binary?

Ryan

On Wed, Aug 14, 2019, 10:55 AM Job Snijders  wrote:

> Dear NANOG,
>
> Recently NTT investigated how to best monitor the visibility of our own
> and our subsidiaries’ IP resources in the BGP Default-Free Zone. We were
> specifically looking how to get near real-time alerts funneled into an
> actionable pipeline for our NOC & Operations department when BGP hijacks
> happen.
>
> Previously we relied on a commercial “BGP Monitoring as a Service”
> offering, but with the advent of RIPE NCC’s “RIS Live” streaming API [1] we
> saw greater potential for a self-hosted approach designed specifically for
> custom integrations with various business processes. We decided to write
> our own tool “BGPalerter” and share the source code with the Internet
> community.
>
> BGPalerter allows operators to specify in great detail how to distribute
> meaningful information from the firehose from various BGP data sources (we
> call them “connectors”), through data processors (called “monitors”),
> finally outputted through “reports” into whatever mechanism is appropriate
> (Slack, IRC, email, or a call to your ticketing system’s API).
>
> The source code is available on Github, under a liberal open source
> license to foster community collaboration:
>
> https://github.com/nttgin/BGPalerter
>
> If you wish to contribute to the project, please use Github’s “issues” or
> “pull request” features. Any help is welcome! We’d love suggestions for new
> features, updates to the documentation, help with setting up a CI
> regression testing pipeline, or packaging for common platforms.
>
> Kind regards,
>
> Job & Massimo
> NTT Ltd
>
> [1]: https://ris-live.ripe.net/
>

Re: What can ISPs do better? Removing racism out of internet

[Ryan Hamel]

> could network operators do anything to make these sites “not so easy” to be 
> found, reached, and used to end innocent lives?

Nope. If they follow the word of the providers and services they use, there is 
no reason to terminate the service. CloudFlare terminating 8chan's service was 
a one off thing. Search rankings have nothing to do with the hosting or proxy 
provider. If 8chan is coloed, the only options are feds seizing hardware or 
tapping their connectivity.
Ryan

Re: Spam due to new ARIN allocation

[Ryan Hamel]

>
> Do it. I'd name and shame all of them.

Ryan

On Fri, Aug 2, 2019, 4:33 PM Tim Burke  wrote:
>
>> We recently received a new ASN from ARIN - you know what that means...
>> the sales vultures come out to play!
>>
>> So far, it has resulted in spam from Cogent (which is, of course, to be
>> expected), and now another company called "CapCon Networks" -
>> http://www.capconnetworks.com. As far as I am aware, this practice is
>> against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's
>> worth creating a List of People To Never Do Business With™, complete with
>> these jokers, and other vultures that engage in similar tactics?
>>
>> Regards,
>> Tim Burke
>> t...@burke.us
>>
>

RE: Performance metrics used in commercial BGP route optimizers

[Ryan Hamel]

Nowhere near the number as an engineer fat fingering a route. There are ISPs 
that accept routes all the way to /32 or /128, for traffic engineering with 
ease, and/or RTBH.

Ryan

-Original Message-
From: NANOG  On Behalf Of Nick Hilliard
Sent: Tuesday, July 16, 2019 11:04 AM
To: Job Snijders 
Cc: NANOG 
Subject: Re: Performance metrics used in commercial BGP route optimizers

Job Snijders wrote on 16/07/2019 18:41:
> I consider it wholly inappropriate to write-off the countless hours 
> spend dealing with fallout from "BGP optimizers" and the significant 
> financial damages we've sustained as "religious arguments".

it would be interesting to see research into the financial losses experienced 
by people and organisations across the internet caused by routing outages 
relating to bgp optimisers.

Nick

Re: Performance metrics used in commercial BGP route optimizers

[Ryan Hamel]

The answers which you seek would be considered secret sauce to these vendors.

But you can start at running MTRs through a VRF per carrier only containing a 
default route, and looking at the results.

Ryan



On Tue, Jul 16, 2019 at 6:11 AM -0700, "Dimeji Fayomi" 
mailto:o...@students.waikato.ac.nz>> wrote:

Hi,
I'm doing a research on BGP route optimisation and the performance metrics used 
by commercial route optimizer appliances to select better path to a prefix.

I would appreciate any information about the performance metrics used in 
commercial BGP route optimizers, white papers or any other document that 
describes how these metrics are measured and collected by commercial route 
optimizers.

Thanks
--
Dimeji Fayomi

RE: Must have ISP Open Source & tools

[Ryan Hamel]

Java as a dependency this day and age…

-Ryan

From: Jason Kuehl 
Sent: Monday, July 08, 2019 6:41 AM
To: Mehmet Akcin 
Cc: Ryan Hamel ; Niels Bakker 
; nanog@nanog.org
Subject: Re: Must have ISP Open Source & tools

We use https://cbackup.me/en/ over Rancid

--
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com<mailto:jason.w.ku...@gmail.com>

RE: Must have ISP Open Source & tools

[Ryan Hamel]

My List:

Oxidized as a replacement for RANCID
Telegraf + InfluxDB = Tons of Grafana Dashboards
(Open Source Slack Alternative)
Ansible or Python Knowledge with Paramiko or netmiko for network automation.

BGP:

FRRouting - Mimics Cisco CLI
BIRD - Programming style config format.
Exabgp - Mostly used for API driven applications, monitoring with heartbeat 
scripts.
(many others)

DDoS detection and/or filtering:

Fastnetmon - Supports many methods for packet processing.
Ddosdetector (IPv4 Only) - Uses netmap for packet processing.

Top Talkers + Other Creativeness (like fib compressing, or route optimization):

pmacct - sflow/netflow combined with BGP, and a database backend

Servers:

Sensu or LibreNMS for Nagios type monitoring.

Diagnostics:

MTR - ...and knowing how to interpret it's output.

-Ryan

RE: Sflow billing or usage calculation software

[Ryan Hamel]

Tony,

Take a look at pmacct, it will be able to handle your needs with a number of 
modifications. The section I linked below should give you a good starting 
point. Change the traffic dump to a MySQL database, add some indexes, craft 
some SQL queries, then you're off to the races. As for billing notifications, a 
cron script would need to calculate the usages, and alert based on your set 
thresholds.

http://wiki.pmacct.net/OfficialExamples - XVII. Using pmacct as traffic/event 
logger

For added bonus points, combine it with a BGP feed, and know where your traffic 
is going outbound, that way intelligent routing changes can be made much 
quicker.

--
Ryan Hamel
Network Administrator
ryan.ha...@quadranet.com | +1 (888) 578-2372
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud

From: NANOG  On Behalf Of Tony C
Sent: Friday, April 12, 2019 8:22 PM
To: nanog@nanog.org
Subject: Sflow billing or usage calculation software

Hi All
I am looking for Sflow analytical software that can tell me automatically over 
say a period of 24 hours (or any time period I select) the average mbit of data 
consumed for any IP address within our entire AS.
(Without configuring a rule or billing group for each IP address or customer 
within our network)
The purpose is to help quickly work out IP addressees which are using more 
bandwidth (in or out) than what we consider to be acceptable usage.
For example, I would like to review a report or be automatically alerted to any 
IP address using more than an average of 50mbit within the past 24 hour plus 
have the capability to review data say over a month.
Any names of software of suggestions would be great which I can investigate, 
happy to look at both commercial software and open source or if you have a 
Sflow billing solution for data consumption which is simple and easy to use 
please let me know
Thanks
Tony

RE: VPS providers contacts

[Ryan Hamel]

Mehmet,

On our network automation, we “drive” each product through SSH/telnet and use 
the native terminal or netconf. This automation has been around before netconf 
was a concept, anything new is simple as writing the configuration snippets, 
creating the functions in the abstracted automation classes, and overriding it 
in vendor model specific classes.

This same template idea could be used to generate BIRD configurations that can 
go into a pre-defined folder from the main config file, and trigger a soft 
reload. I personally can’t wrap my head around BIRD since I came from the 
traditional network hardware background, but it certainly does have its place 
in the automation sector.

Just make sure your system has a way to log each step from the device and 
program functions for checks and balances, and combine it all in a transaction 
like process, along with throwing an exception on data it doesn’t know to 
expect, and rolling back the changes if it’s possible.

--
Ryan Hamel
Network Administrator
ryan.ha...@quadranet.com | +1 (888) 578-2372
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud

RE: Should ISP block child pornography?

[Ryan Hamel]

When I receive a report, we follow our procedures with the Cyber Tip Line, and 
then immediately null route the IP address until the content is removed.

From: NANOG  On Behalf Of Suresh Ramasubramanian
Sent: Thursday, December 06, 2018 10:49 PM
To: Mark Seiden 
Cc: nanog@nanog.org
Subject: Re: Should ISP block child pornography?

In the USA, you need to contact NCMEC - http://www.missingkids.com/home or the 
FBI.

From: Mark Seiden mailto:m...@seiden.com>>
Date: Friday, 7 December 2018 at 12:16 PM
To: Suresh Ramasubramanian mailto:ops.li...@gmail.com>>
Cc: "Lotia, Pratik M" 
mailto:pratik.lo...@charter.com>>, 
"nanog@nanog.org" 
mailto:nanog@nanog.org>>
Subject: Re: Should ISP block child pornography?

thanks, suresh. what it seems to say is get in touch with the ncb in your 
country to sign an nda and get instructions.  (but it's actually quite hard to 
figure out how to do that, no email address or phone numbers apparent for 
interpol dc)

RE: Switch with high ACL capacity

[Ryan Hamel]

I would see if you can get your upstream providers to apply rules to a 
dedicated interface upstream (drop NTP, memcache, LDAP, rate limit SSDP), and 
connect that to your switch, which would announce the /32’s or /128’s to pull 
the traffic over. You would of course have to announce the /24 or /48 through 
the carrier that has the filters in place to ensure they get all the traffic. 
After post processing the spoofed traffic, it should leave you with flooding to 
take care of.

--
Ryan Hamel
Network Administrator
ryan.ha...@quadranet.com | +1 (888) 578-2372
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud

From: NANOG  On Behalf Of Tim Jackson
Sent: Tuesday, November 06, 2018 11:52 AM
To: na...@ics-il.net
Cc: nanog list 
Subject: Re: Switch with high ACL capacity

Juniper QFX1(including 12) supports ~64k ACL entries + FlowSpec

--
Tim

On Tue, Nov 6, 2018 at 1:49 PM Mike Hammett 
mailto:na...@ics-il.net>> wrote:
The intent is to see if I can construct a poor man's DDOS scrubber. There are 
low cost systems out there for the detection, but they just trigger something 
else to do the work. Obviously there is black hole routing, but I'm looking for 
something with a bit more finesse.

If I need to get a switch anyway, might as well try to take advantage of it for 
other uses.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP

- Original Message -
From: Lotia, Pratik M 
mailto:pratik.lo...@charter.com>>
To: Mike Hammett mailto:na...@ics-il.net>>, 'nanog list' 
mailto:nanog@nanog.org>>
Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST)
Subject: Re: Switch with high ACL capacity

Mike,

Can you shed some light on the use case? Looks like you are confusing ACLs and 
BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a 
different use case. ACLs cannot be configured using Flowspec announcements. 
Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot 
more to it than just L4). I doubt if a there is a Switch which can hold a large 
number of Flowspec entries.


~Pratik Lotia
“Improvement begins with I.”


On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett" 
mailto:nanog-boun...@nanog.org> on behalf of 
na...@ics-il.net<mailto:na...@ics-il.net>> wrote:

I am looking for recommendations as to a 10G or 40G switch that has the 
ability to hold a large number of entries in ACLs.

Preferred if I can get them there via the BGP flow spec, but some sort of 
API or even just brute force on the console would be good enough.

Used or even end of life is fine.

-Mike HammettIntelligent Computing SolutionsMidwest Internet 
ExchangeThe Brothers WISP


E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Switch with high ACL capacity

[Ryan Hamel]

Mike,

Are you sure you have enough inbound capacity to setup such a thing? Do you 
have RTBH setup for the final means of killing the attack?

If you could get another set of circuits to feed this switch from your same 
providers, and they accept more specific announcements, you could use this to 
swing /32's or /128's to said dedicated links so it won't affect your clients 
traffic.

--
Ryan Hamel
Network Administrator
ryan.ha...@quadranet.com | +1 (888) 578-2372
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud


-Original Message-
From: NANOG  On Behalf Of 
Mike Hammett
Sent: Tuesday, November 06, 2018 11:47 AM
To: Lotia, Pratik M 
Cc: 'nanog list' 
Subject: Re: Switch with high ACL capacity

The intent is to see if I can construct a poor man's DDOS scrubber. There are 
low cost systems out there for the detection, but they just trigger something 
else to do the work. Obviously there is black hole routing, but I'm looking for 
something with a bit more finesse.

If I need to get a switch anyway, might as well try to take advantage of it for 
other uses.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP

- Original Message -
From: Lotia, Pratik M 
To: Mike Hammett , 'nanog list' 
Sent: Tue, 06 Nov 2018 12:29:15 -0600 (CST)
Subject: Re: Switch with high ACL capacity

Mike,

Can you shed some light on the use case? Looks like you are confusing ACLs and 
BGP Flowspec. ACLs and Flowspec rules are similar in some ways but they have a 
different use case. ACLs cannot be configured using Flowspec announcements. 
Flowspec can be loosely explained as 'Routing based on L4 rules' (there's a lot 
more to it than just L4). I doubt if a there is a Switch which can hold a large 
number of Flowspec entries.

 
~Pratik Lotia
“Improvement begins with I.”
 

On 11/6/18, 10:39, "NANOG on behalf of Mike Hammett"  wrote:

I am looking for recommendations as to a 10G or 40G switch that has the 
ability to hold a large number of entries in ACLs.

Preferred if I can get them there via the BGP flow spec, but some sort of 
API or even just brute force on the console would be good enough.

Used or even end of life is fine.

-Mike HammettIntelligent Computing SolutionsMidwest Internet 
ExchangeThe Brothers WISP


E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Brocade SLX Internet Edge

[Ryan Hamel]

+1 SecureCRT in general, and don’t buy Brocade,

I was happy when I got to pull out the last Foundry.

--
Ryan Hamel
Network Engineer
ryan.ha...@quadranet.com<mailto:ryan.ha...@quadranet.com> | +1 (888) 578-2372 
x201
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud

From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
Sent: Wednesday, October 31, 2018 3:38 PM
To: Ryan Hamel 
Cc: lists.na...@monmotha.net; nanog list 
Subject: Re: Brocade SLX Internet Edge

If you buy brocade, be sure to also by a license for securecrt so that 
backspace works over ssh...
also, just don't do brocade... ever.

On Thu, Nov 1, 2018 at 9:31 AM Ryan Hamel 
mailto:ryan.ha...@quadranet.com>> wrote:
140K IPv6 equates to about 560K IPv4 routes, leaving the end user with 940K 
IPv4, which is not a lot of ceiling space considering we're at 741K IPv4 + and 
60K IPv6 (240k IPv4 equivalent) now (941K total). This will leave you with 
559K. I am not sure what the OP has for peering but with trying to keep 20% of 
TCAM space free, and keeping up with the current rate of rise according to 
CIDR-report, I'd say 4 years product lifetime if the OS has excellent TCAM 
management.

Considering how the device looks like a switch and the SLX9850 uses Broadcom 
sillicon, I'm thinking it must use the Jericho chipset or some variant to get 
that kind of performance. In the end, your mileage may vary.

--
Ryan Hamel
Network Engineer
ryan.ha...@quadranet.com<mailto:ryan.ha...@quadranet.com> | +1 (888) 578-2372 
x201
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org<mailto:nanog-boun...@nanog.org>] On 
Behalf Of Brandon Martin
Sent: Wednesday, October 31, 2018 3:08 PM
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: Brocade SLX Internet Edge

On 10/31/18 4:56 PM, Aaron wrote:
> It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes.

That was changed earlier this year AFAIK.  The website was slow to get updated 
but has been updated now.  Current claim is 1.5M IPv4 and 140k IPv6.  You need 
the "advanced feature license" to get access to that.
--
Brandon Martin

RE: Brocade SLX Internet Edge

[Ryan Hamel]

140K IPv6 equates to about 560K IPv4 routes, leaving the end user with 940K 
IPv4, which is not a lot of ceiling space considering we're at 741K IPv4 + and 
60K IPv6 (240k IPv4 equivalent) now (941K total). This will leave you with 
559K. I am not sure what the OP has for peering but with trying to keep 20% of 
TCAM space free, and keeping up with the current rate of rise according to 
CIDR-report, I'd say 4 years product lifetime if the OS has excellent TCAM 
management.

Considering how the device looks like a switch and the SLX9850 uses Broadcom 
sillicon, I'm thinking it must use the Jericho chipset or some variant to get 
that kind of performance. In the end, your mileage may vary.

-- 
Ryan Hamel
Network Engineer
ryan.ha...@quadranet.com | +1 (888) 578-2372 x201
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brandon Martin
Sent: Wednesday, October 31, 2018 3:08 PM
To: nanog@nanog.org
Subject: Re: Brocade SLX Internet Edge

On 10/31/18 4:56 PM, Aaron wrote:
> It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes.

That was changed earlier this year AFAIK.  The website was slow to get updated 
but has been updated now.  Current claim is 1.5M IPv4 and 140k IPv6.  You need 
the "advanced feature license" to get access to that.
--
Brandon Martin

RE: Oct. 3, 2018 EAS Presidential Alert test

[Ryan Hamel]

Confirmed Verizon - Android - Los Angeles.

-- 
Ryan Hamel
Network Engineer
ryan.ha...@quadranet.com | +1 (888) 578-2372 x201
QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Milt Aitken
Sent: Wednesday, October 3, 2018 12:24 PM
To: 'Andy Ringsmuth' ; nanog@nanog.org
Subject: RE: Oct. 3, 2018 EAS Presidential Alert test

I got it on a Verizon Android.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Andy Ringsmuth
Sent: Wednesday, October 03, 2018 2:53 PM
To: nanog@nanog.org
Subject: Oct. 3, 2018 EAS Presidential Alert test

Did anyone on AT or an iPhone receive the test today? I believe it was 
supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT.

I’m in CDT, so 1:18 and 1:20 p.m. CDT.

Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of 
this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT iPhones 
and not a single one of them alerted.

FEMA says https://www.fema.gov/emergency-alert-test

"Cell towers will broadcast the WEA test for approximately 30 minutes beginning 
at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are 
switched on, within range of an active cell tower, and whose wireless provider 
participates in WEA should be capable of receiving the test message. Some cell 
phones will not receive the test message, and cell phones should only receive 
the message once."

My wife, with a Sprint iPhone, received the test.



Andy Ringsmuth
5609 Harding Drive
Lincoln, NE 68521-5831
(402) 304-0083
a...@andyring.com

RE: NANOG Security Track: Route Security

[Ryan Hamel]

Ryan, what does the track moderator have to do with the presenter? All I here 
is an excuse to do a disservice to fellow members of this community.

Do you really want to have future meetings with everyone holding out their 
phones, cameras, or other recording devices, to spread the wealth of knowledge? 
That's crazy.

Ryan Hamel

-Original Message-
From: NANOG  On Behalf Of Ryan Woolley
Sent: Monday, October 01, 2018 11:48 AM
To: NANOG 
Subject: Re: NANOG Security Track: Route Security

On Mon, Oct 1, 2018 at 8:16 AM Netravnen  wrote:
>
> On Mon, 1 Oct 2018 at 14:01, John Kristoff  wrote:
> >
> > On Mon, 1 Oct 2018 03:27:49 +0000
> > Ryan Hamel  wrote:
> >
> > > Just like how all the email threads on NANOG are archived, all 
> > > talks should be archived as well.
> >
> > Whether to record a session or not is up to the presenter and track 
> > coordinator.
>
> I would prefer if NANOG would record sessions by default! (And allow 
> presenters to opt-out if they really feel like it.)
>
> Other conferences I have had participated to in the past. Had the 
> option of allowing opt-out of being recorded on stage.

This is in fact how it works now at NANOG.  As John points out, the decision is 
left up to the submitter, but almost all talks are webcast and recorded.  
(Historically, the security track has not been
recorded.)

Anyone is welcome to submit talks, including tracks, for consideration, and to 
make this choice as submitter.  In this case, the track moderator believes that 
it's better that the the talk to not be recorded and so we are honoring that 
request.

Aside from the security track and one other submission, the remainder of the 
3-day program will be available for viewing and recorded.

Regards,

Ryan Woolley
NANOG PC Chair

RE: NANOG Security Track: Route Security

[Ryan Hamel]

Just like how all the email threads on NANOG are archived, all talks should be 
archived as well.

Ryan Hamel

From: NANOG  On Behalf Of Krassimir Tzvetanov
Sent: Sunday, September 30, 2018 3:31 PM
To: Sam Oduor 
Cc: NANOG mailing list 
Subject: Re: NANOG Security Track: Route Security

Sam,

To ensure unimpeded information sharing and discussion, the Security Track will 
not be broadcast or recorded.

I apologise for the inconvenience.

Regards,
Krassimir


On Sun, Sep 30, 2018, 1:05 PM Sam Oduor 
mailto:sam.od...@gmail.com>> wrote:
Hi

Any online link available for remote participation or viewing ?

On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov 
mailto:mailli...@krassi.biz>> wrote:
Hello Everyone,

I wanted to attract your attention to the Security Track this coming NANOG. 
We'll be meeting on Tuesday morning and the line up looks like this:
* Andre Toonk - examples of hijacks, other ideas
* Alexander Azimov - State of BGP Security
* David Wishnick - ARIN TAL
* Job Snijders - Routing security roadmap
* Chris Morrow - So I need to start filtering routes from peers...' and 'hey 
guess who needs to update their IRR data?'

Time permitting at the end of the time slot we'll have a panel and time for 
duscussion as well.

Regards,
Krassi



--
Samson Oduor

RE: Console Servers

[Ryan Hamel]

I just use a Raspberry Pi with USB to Serial adapters or old servers with 
PCI(-E) 8 port serial cards. They make it so easy to adapt to any environment, 
and it phones home to my conserver (https://www.conserver.com/) gateway. The 
total cost for hardware is less than $150.

Ryan

From: NANOG  On Behalf Of Christopher Morrow
Sent: Tuesday, September 18, 2018 9:04 AM
To: Sameer Khosla 
Cc: nanog list 
Subject: Re: Console Servers

a vote for (so far so good) the nodegrid ZPE devices.

On Tue, Sep 18, 2018 at 8:54 AM Sameer Khosla 
mailto:skho...@neutraldata.com>> wrote:
My favorite are the lantronix SLC console servers.  Fairly bullet-proof, they 
are one of those devices that just work.  Can usually be picked up used ~$300 
for 32 or 48 port varieties in good condition if you aren’t in the biggest 
hurry.

Sk.


From: NANOG mailto:nanog-boun...@nanog.org>> On Behalf 
Of Alan Hannan
Sent: Tuesday, September 18, 2018 9:37 AM
To: NANOG mailto:nanog@nanog.org>>
Subject: Console Servers

I'd like your input on suggestions for an alternate serial port manager.

Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I used 
portmaster and was less so.  Recently I've been using Opengear and they work 
fairly well but the price is fairly high.   I use the CM7100 and IM7100.

General specs I'm looking for are:

 * 8 to 48 or more rs232 serial ports on rj45
 * nice-to-have software selectable pinouts (cisco v. straight)
 * gig-e ethernet port (100mbps ok)
 * 1U form factor
 * redundant AC power
 * access physical serial connections via local port #
 * access physical serial connections via local IP alias (nice to have)

Can you recommend a serial port server/concentrator that I could use in place 
of opengear for a better value and/or lower cost?

I'm just ignorant about the current market for serial port concentrators and so 
far web searches have not revealed ideas, so your input is appreciated!

Thanks!

-alan

RE: automatic rtbh trigger using flow data

[Ryan Hamel]

Baldur,

Modifying the routing table with a next-hop change from a community, is 
different than having a line card filtering packets at layer 4, of course most 
if not all carriers will support it. Instead of doing normal TCAM route 
lookups, you’re getting into packet inspection territory, which is something 
completely different.

Just quickly reading the ASR 9K documentation, it can only support 3K rules per 
system. Juniper – 8K, Alcatel-Lucent – 512. That’s pretty low considering I can 
put many /32s into a routing table very easily and without hassle.

As I said before, no ISP is going to offer such filtering services for free 
when DDoS mitigation is a cash cow.

Ryan Hamel

From: NANOG  On Behalf Of Baldur Norddahl
Sent: Sunday, September 02, 2018 1:42 AM
To: nanog@nanog.org
Subject: Re: automatic rtbh trigger using flow data

This is not true. Some of our transits do RTBH for free. For example Cogent.

They will not do FlowSpec. Maybe their equipment can not do it or for some 
other reason.

However RTBH is a simple routing hack that can be implemented on any router. 
The traffic is dropped right at the edge and is never transported on the 
transit provider network. In that sense it also protects the transit network.

RTBH only for UDP would also be a very simple hack on many routers.

It might not be FlowSpec, but it may have most of the benefit, in a much 
simplified way.

Regards

Baldur


søn. 2. sep. 2018 02.39 skrev Ryan Hamel 
mailto:ryan.ha...@quadranet.com>>:
No ISP is in the business of filtering traffic unless the client pays the hefty 
fee since someone still has to tank the attack.

I also don’t think there is destination prefix IP filtering in flowspec, which 
could seriously cause problems.

From: NANOG mailto:nanog-boun...@nanog.org>> On Behalf 
Of Baldur Norddahl
Sent: Saturday, September 01, 2018 5:18 PM
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: automatic rtbh trigger using flow data


fre. 31. aug. 2018 17.16 skrev Hugo Slabbert 
mailto:h...@slabnet.com>>:


I would love an upstream that accepts flowspec routes to get granular about
drops and to basically push "stateless ACLs" upstream.

_keeps dreaming_


We just need a signal to drop UDP for a prefix. The same as RTBH but only for 
UDP. This would prevent all volumetric attacks without the end user being cut 
off completely.

Besides from some games, VPN and VoIP, they would have an almost completely 
normal internet experience. DNS would go through the ISP servers and only be 
affected if the user is using a third party service.

Regards

Baldur

RE: automatic rtbh trigger using flow data

[Ryan Hamel]

No ISP is in the business of filtering traffic unless the client pays the hefty 
fee since someone still has to tank the attack.

I also don’t think there is destination prefix IP filtering in flowspec, which 
could seriously cause problems.

From: NANOG  On Behalf Of Baldur Norddahl
Sent: Saturday, September 01, 2018 5:18 PM
To: nanog@nanog.org
Subject: Re: automatic rtbh trigger using flow data


fre. 31. aug. 2018 17.16 skrev Hugo Slabbert 
mailto:h...@slabnet.com>>:


I would love an upstream that accepts flowspec routes to get granular about
drops and to basically push "stateless ACLs" upstream.

_keeps dreaming_


We just need a signal to drop UDP for a prefix. The same as RTBH but only for 
UDP. This would prevent all volumetric attacks without the end user being cut 
off completely.

Besides from some games, VPN and VoIP, they would have an almost completely 
normal internet experience. DNS would go through the ISP servers and only be 
affected if the user is using a third party service.

Regards

Baldur

RE: automatic rtbh trigger using flow data

[Ryan Hamel]

From experience, sflows are horribly inaccurate for DDoS detection, since the 
volume could disrupt the control plane and render the process useless, thus not 
giving data to the external system to act upon it. You can't get any better 
than mirroring your inbound transit, and sampling the output to a sensor.

I have also spent some time on a spare server running netmap and influxdb, it 
simply could not keep up, nor could I write any useful queries against it. 
Which is why I'm deciding on using pf_ring ft (flow table) and just let it 
calculate all the data to be dumped into a MySQL memory table, and also 
harvesting ntop's NDPI protocol decoding, to enhance the detection rules. My 
ideal setup is to break things down into dedicated programs like flow exporter, 
detection, and response.

I also want to make clear to Michel, that colo'ing a router at an ISP is no 
different than plugging it into your local router, your uplink will get 
saturated beyond what it can physically handle with only the ACLs protecting 
the other side, but if your clients are also receiving traffic on the same 
uplink as the attack, it's a denial of service to them.

-Original Message-
From: NANOG  On Behalf Of H I Baysal
Sent: Friday, August 31, 2018 2:09 AM
To: Michel Py ; Aaron Gould ; 
mic...@arneill-py.sacramento.ca.us
Cc: Nanog@nanog.org
Subject: Re: automatic rtbh trigger using flow data

Most of the solutions mentioned are paid, or fastnetmon is partially paid. And 
the thing you want is paid i believe
Nice tool though, not saying anything against it. However

My personal view is, as long as you can store your flow info in a timeseries 
database (like influxdb and NOT SQL LIKE!!!) you can do whatever you want 
with the (raw) data. And create custom triggers for different calculations.

Flows are on the fly and are coming in constantly, you could have a calculation 
like group by srcip and whatever protocol you want or just srcip, and make a 
calculation for every x seconds or minutes. As i mentioned the flow data is a 
constant stream, so you could have it triggered as fast as you want.

(and the nice thing is, with sflow, you also get as path, peer as, 
localpref,community (if enabled). You could group by anything.. :)

I admit it takes a bit more time to setup but the outcome is amazing ;) 
(especially if you graph it then with grafana) And in your case it would be a 
script that does a influxdb command to make the calculations and if the outcome 
shows an IP meeting the thresholds you have set in the calculation, you trigger 
a script that adjusts the route to be announced to your upstream with the 
correct
(rtbh) community.
( as i mentioned, as long as you have the "raw" flows, you can do anything )


Good luck, whatever you choose :)


On 31-08-18 02:14, Michel Py wrote:
>> Aaron Gould wrote :
>> I'm really surprised that you all are doing this based on source ip, 
>> simply because I thought the distribution of botnet members around the world 
>> we're so extensive that I never really thought it possible to filter based 
>> on sources, if so I'd like to see the list too.
> I emailed you. For years I ran it at home on a Cisco 1841, 100,000 BGP 
> prefixes is nothing these days. I am not surprised that Joe pushes that to 
> some CPEs.
>
>> Even so, this would not stop the attacks from hitting my front door, 
>> my side of my Internet uplink...when paying for a 30 gigs CIR and 
>> paying double for megabits per second over that, up to the ceiling of 100 
>> gig every bit that hits my front door over 30 gig would cost me extra, 
>> remotely triggering based on my victim IP address inside my network would be 
>> my solution to saving money.
> I agree. If you want to get a real use of source blacklisting, to save 
> bandwidth, you probably went to rent a U in a rack at your upstream(s) to 
> block it there.
> I never did it past 1GE, and I have never measured seriously the bandwidth it 
> would save, would be curious to know.
> I think the two approaches are complementary to each other though.
>
> Michel.
>
>
> On Aug 30, 2018, at 6:43 PM, Michel Py  wrote:
>
>>> Joe Maimon wrote :
>>> I use a bunch of scripts plus a supervisory sqlite3 database process 
>>> all injecting into quagga
>> I have the sqlite part planned, today I'm using a flat file :-( I 
>> know :-(
>>
>>> Also aimed at attacker sources. I feed it with honeypots and live servers, 
>>> hooked into fail2ban and using independent host scripts. Not very 
>>> sophisticated, the remotes use ssh executed commands to add/delete. I also 
>>> setup a promiscuous ebgp RR so I can extend my umbrella to CPE with diverse 
>>> connectivity.
>> I would like to have your feed. How many attacker prefixes do you currently 
>> have ?
>>
>>> Using flow data, that sounds like an interesting direction to take this 
>>> into, so thank you!
>> The one thing we can share here is the attacker prefixes. The victim 
>> prefixes are unique to each of us but I expect