RE: Juniper hardware recommendation

2021-05-07 Thread 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

2021-04-24 Thread 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)

2021-04-16 Thread 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

2021-02-04 Thread 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

2021-02-04 Thread 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?

2021-01-26 Thread 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?

2021-01-26 Thread 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

2020-11-30 Thread 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

2020-11-15 Thread 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

2020-10-28 Thread 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

2020-10-16 Thread 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

2020-10-15 Thread 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

2020-10-15 Thread 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

2020-10-15 Thread 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

2020-10-14 Thread 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

2020-10-14 Thread 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

2020-10-14 Thread 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

2020-10-13 Thread 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

2020-10-08 Thread 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

2020-09-15 Thread 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)

2020-08-01 Thread 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)

2020-08-01 Thread 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

2020-05-30 Thread 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?

2020-05-27 Thread 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

2020-05-13 Thread 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

2020-02-25 Thread 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

2020-02-25 Thread 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

2020-02-25 Thread 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

2020-02-03 Thread 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

2019-12-31 Thread 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

2019-12-30 Thread 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

2019-12-17 Thread 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?

2019-11-17 Thread 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”

2019-08-14 Thread 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

2019-08-04 Thread 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

2019-08-02 Thread 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

2019-07-16 Thread 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

2019-07-16 Thread 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

2019-07-08 Thread 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

2019-07-07 Thread 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

2019-04-13 Thread 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

2019-02-08 Thread 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?

2018-12-06 Thread 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

2018-11-06 Thread 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

2018-11-06 Thread 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

2018-10-31 Thread 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

2018-10-31 Thread 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

2018-10-03 Thread 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

2018-10-01 Thread 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

2018-09-30 Thread 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

2018-09-18 Thread 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

2018-09-02 Thread 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

2018-09-01 Thread 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

2018-08-31 Thread 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 

RE: automatic rtbh trigger using flow data

2018-08-30 Thread Ryan Hamel
Exactly Aaron. No provider will allow a customer to null route a source IP 
address. I could only assume that a null route on Michel's network is tanking 
the packets at their edge to 192.0.2.1 (discard/null0).

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

-Original Message-
From: NANOG  On Behalf Of Aaron Gould
Sent: Thursday, August 30, 2018 1:38 PM
To: 'Michel Py' ; Nanog@nanog.org
Subject: RE: automatic rtbh trigger using flow data

Thanks, but what if the attacker is many... like thousands ?  ...isn't that 
typically what we see, is tons and tons of sources (hence
distributeddos) ?

-Aaron

-Original Message-
From: Michel Py [mailto:michel...@tsisemi.com]
Sent: Thursday, August 30, 2018 3:17 PM
To: Aaron Gould; Nanog@nanog.org
Subject: RE: automatic rtbh trigger using flow data 

> Aaron Gould wrote :
> Hi, does anyone know how to use flow data to trigger a rtbh (remotely
triggered blackhole) route using bgp ?  ...I'm thinking we could use
> quagga or a script of some sort to interact with a router to advertise 
> to
bgp the /32 host route of the victim under attack.

Look at Exabgp : https://github.com/Exa-Networks/exabgp
That's what I use in here : https://arneill-py.sacramento.ca.us/cbbc/ to inject 
the prefixes in BGP.
I block the attacker's addresses, not the victim but if you are willing to 
write your own scripts it does the job.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...



RE: automatic rtbh trigger using flow data

2018-08-30 Thread Ryan Hamel
There are software that combine your needs altogether. I'm sure there are 
others.

WANGuard from Andrisoft (https://www.andrisoft.com/software/wanguard)
Fastnetmon (https://fastnetmon.com/)

From: NANOG  On Behalf Of Aaron Gould
Sent: Thursday, August 30, 2018 12:53 PM
To: Nanog@nanog.org
Subject: automatic rtbh trigger using flow data

Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered 
blackhole) route using bgp ?  ...I'm thinking we could use quagga or a script 
of some sort to interact with a router to advertise to bgp the /32 host route 
of the victim under attack.

Btw, I already have nfsen running and we receive real-time alters of various 
types of attacks, high volume, high ports, etc... and then we telnet into a 
cisco trigger router and drop a few lines of code into it and then bgp does the 
rest within seconds, the upstream providers learn of this route via communities 
and they rtbh it in their cloud, BUT, I would like my alerts to do this 
automatically... that would be very nice.  Any guidance would be appreciated.

-Aaron



RE: Web UI DHCP Option 82

2018-08-19 Thread Ryan Hamel
I just had a brain fart a moment ago, PHPMyAdmin is an option if you want to 
create a number of MySQL users that have access to the same table.

-Original Message-
From: NANOG  On Behalf Of daveb
Sent: Sunday, August 19, 2018 6:30 AM
To: NANOG 
Subject: Re: Web UI DHCP Option 82


There's no GUI but I'll second the Kea recommendation.

At 09:36 AM 8/18/2018, Colton Conor wrote:
>Mike, I am looking for the same thing. Does Mikrotik have the ability 
>to do what you are requesting?Â
>
>On Fri, Aug 17, 2018 at 5:11 PM Ryan Hamel 
><<mailto:ryan.ha...@quadranet.com>ryan.ha...@quadranet.com> wrote:
>
>Mike,
>
>Take a look into Kea from ISC. The config is JSON based, which allows 
>for nearly any scripting language to make changes, or you can dig into 
>how it works with MySQL for dynamic operation 
>(<https://kea.isc.org/wiki/HostReservationsHowTo>https://kea.isc.org/wiki/HostReservationsHowTo).
>
>Â
>
>Ryan
>
>Â
>
>From: NANOG
><<mailto:nanog-boun...@nanog.org>nanog-boun...@nanog.org>
>On Behalf Of Mike Hammett
>Sent: Friday, August 17, 2018 1:51 PM
>To: <mailto:nanog@nanog.org>nanog@nanog.org list 
><<mailto:nanog@nanog.org>nanog@nanog.org>
>Subject: Web UI DHCP Option 82
>
>Â
>
>Are there any web interfaces out there for DHCP servers that 
>accommodate management of DHCP option 82 configs? Neither webmin nor 
>Glass seem to handle ISC's agent.circuit-id outside of presenting the 
>raw config file. I can do that just fine in nano, but I'm looking at 
>something more user-friendly so I'm not the only one that can work on 
>it.
>
>I'm also cheap, so not looking at Infoblox or anything like that.
>
>
>
>-
>Mike Hammett
>Intelligent Computing Solutions
><http://www.ics-il.com>http://www.ics-il.com
>
>Midwest-IX
><http://www.midwest-ix.com>http://www.midwest-ix.com



RE: Web UI DHCP Option 82

2018-08-17 Thread Ryan Hamel
Mike,

Take a look into Kea from ISC. The config is JSON based, which allows for 
nearly any scripting language to make changes, or you can dig into how it works 
with MySQL for dynamic operation 
(https://kea.isc.org/wiki/HostReservationsHowTo).

Ryan

From: NANOG  On Behalf Of Mike Hammett
Sent: Friday, August 17, 2018 1:51 PM
To: nanog@nanog.org list 
Subject: Web UI DHCP Option 82

Are there any web interfaces out there for DHCP servers that accommodate 
management of DHCP option 82 configs? Neither webmin nor Glass seem to handle 
ISC's agent.circuit-id outside of presenting the raw config file. I can do that 
just fine in nano, but I'm looking at something more user-friendly so I'm not 
the only one that can work on it.

I'm also cheap, so not looking at Infoblox or anything like that.


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

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


RE: unwise filtering policy on abuse mailboxes

2018-07-27 Thread Ryan Hamel
All,

My colleague has already contacted their friend at Psychz when I received the 
first message. Not everyone has to be on the list to get the message relayed to 
them.

Rich, shall we all drop your email? It would achieve the same effect, and make 
this email thread more productive.

Ryan

-Original Message-
From: NANOG  On Behalf Of Rich Kulawiec
Sent: Friday, July 27, 2018 5:36 AM
To: nanog@nanog.org
Subject: Re: unwise filtering policy on abuse mailboxes

On Tue, Jul 24, 2018 at 04:19:22PM -0700, Dan Hollis wrote:
> can we please just stop this nonsense?

An excellent way to stop this particular nonsense is to firewall out every 
network allocation under the control of Psychz.  This achieves lossless 
compression of incoming data.

---rsk



RE: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3

2018-06-27 Thread Ryan Hamel
Why would we need an RFC for Comic Sans?

-Original Message-
From: NANOG  On Behalf Of Alain Hebert
Sent: Wednesday, June 27, 2018 1:50 PM
To: nanog@nanog.org
Subject: Re: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and 
Level3

     I ain't friday, but: There is no RFC for the Sarcastica font yet?

     PS:  Our little adventure in BGP who-done-it (a few weeks back) burned 
about 25-30h man hours estimated.  Should have been sub 5 hours if 1 guy would 
have cooperated instead of ignoring the issue.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 06/27/18 03:25, Mark Tinka wrote:
>
> On 27/Jun/18 04:18, Suresh Ramasubramanian wrote:
>
>> Oh dear. The problem with sarcasm is that it falls flat if people don't 
>> realize you're being sarcastic.
> Text-based messaging is terribly reliable at helping miss the point...
>
> It's a good things our kids of today call each other on the phone to 
> avoid that :-)...
>
> Mark.
>



Intuit - IP Block - Connection Timed Out

2018-05-09 Thread Ryan Hamel
Greetings,

If someone from Intuit can contact me off list, I would highly appreciate it. 
We have a client that is not able to access QuickBooks Online from one of our 
specific IP blocks. The IP for https://qbo.intuit.com/ responds to ping, but 
any web request results in a connection timed out.

Thanks!

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



Re: Attacks on BGP Routing Ranges

2018-04-18 Thread Ryan Hamel
Saku,

The attacks are definitely inbound on the border router interface. I have 
tracked outbound attacks before and wish it was this simple, but its not.

> a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp 
> are sent (policed) to infrastructure addresses

While I can implement an edge filter to drop such traffic, it's impacting our 
clients traffic as well.

> b) do not advertise link networks in iBGP

This has never been an issue.

> c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255

 Could you explain how this can resolve my issue? I am not sure how this would 
work.

Thanks for your input!

Ryan Hamel

From: Saku Ytti <s...@ytti.fi>
Sent: Wednesday, April 18, 2018 3:48 AM
To: Ryan Hamel
Cc: nanog@nanog.org
Subject: Re: Attacks on BGP Routing Ranges

Hey Ryan,


I'm assuming edge link in your network facing another administrative domain.

You'll have two scenarios

1) attack coming from your side
2) attack coming from far side

You can easily stop 1, obviously.
But for 2, you really need to have far-side who is cooperative and
understanding of best practices and there isn't any magic you alone
can do with entirely uncooperative far-end.

Things to consider at both ends:

a) edge filter, on all edge interfaces ensure that only udp
traceroute, icmp are sent (policed) to infrastructure addresses
b) do not advertise link networks in iBGP
c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255




On 18 April 2018 at 13:37, Ryan Hamel <ryan.ha...@quadranet.com> wrote:
> Hello,
>
> I wanted to poll everyones thoughts on how to deal with attacks directly on 
> BGP peering ranges (/30's, /127's).
>
> I know that sending an RTBH for our side of the upstream routing range does 
> not resolve the issue, and it would actually make things worse by blackholing 
> all inbound traffic on the carrier I send the null to. What are my options 
> for carriers that are not willing to help investigate the situation or write 
> up a firewall rule to mitigate it on the circuit? I am not a fan of naming 
> and shaming because it has unintended consequences.
>
> Thanks in advance for everyone's suggestions.
>
> Ryan Hamel



--
  ++ytti





Re: Attacks on BGP Routing Ranges

2018-04-18 Thread Ryan Hamel
Job,

Unfortunately, with my current situation, we have stopped exporting our 
prefixes with the tier-1 carrier and still use the outbound bandwidth. I highly 
doubt they will implement such a solution, but is something to keep in mind for 
the future.

Thanks for the tip!

Ryan Hamel



From: Job Snijders <j...@instituut.net>
Sent: Wednesday, April 18, 2018 3:44 AM
To: Ryan Hamel
Cc: nanog@nanog.org
Subject: Re: Attacks on BGP Routing Ranges

Hi,

On Wed, 18 Apr 2018 at 11:39, Ryan Hamel 
<ryan.ha...@quadranet.com<mailto:ryan.ha...@quadranet.com>> wrote:
I wanted to poll everyones thoughts on how to deal with attacks directly on BGP 
peering ranges (/30's, /127's).

I know that sending an RTBH for our side of the upstream routing range does not 
resolve the issue, and it would actually make things worse by blackholing all 
inbound traffic on the carrier I send the null to. What are my options for 
carriers that are not willing to help investigate the situation or write up a 
firewall rule to mitigate it on the circuit? I am not a fan of naming and 
shaming because it has unintended consequences.

Thanks in advance for everyone's suggestions.


Some carriers offer "unreachable linknets", linknets that are carved from 
netblocks that aren't announced in the DFZ or are firewalled off.

If the carrier doesn't want to help, your best course of action may be to 
disconnect the circuit to stop the attack traffic.

Kind regards,

Job


Attacks on BGP Routing Ranges

2018-04-18 Thread Ryan Hamel
Hello,

I wanted to poll everyones thoughts on how to deal with attacks directly on BGP 
peering ranges (/30's, /127's).

I know that sending an RTBH for our side of the upstream routing range does not 
resolve the issue, and it would actually make things worse by blackholing all 
inbound traffic on the carrier I send the null to. What are my options for 
carriers that are not willing to help investigate the situation or write up a 
firewall rule to mitigate it on the circuit? I am not a fan of naming and 
shaming because it has unintended consequences.

Thanks in advance for everyone's suggestions.

Ryan Hamel


Re: Question about great firewall of China

2018-03-23 Thread Ryan Hamel
On Mar 23 2018, at 12:28 am, Jean-Francois Mezei  
wrote:
>
> Asking in a sanity check context.
>
> As you may have heard, Bell Canada has gathered a group called Fairplay
> Canada to force all ISPs in Canada to block web sites Fairplay has
> decided infringe on copyright. (ironically, Fairplay is copyright by
> Apple, and used without permission :-)
>
> Canada has hundreds of separate ISPs, each using a combination of one or
> more transit providers (and there are many that have POPs in Canada).
>
> (so the following question makes it relevant to the NA in NAnog).
> 1-
> Does anyone have "big picture" details on how China implements its
> website blocks?
>
> Is this implemented in major trunks that enter China from the outside
> world? Is there a governmenmt onwed transit provider to whom any/all
> ISPs must connect (and thus that provider can implemnent the blocks), or
> are the blocks performed closer to the edges with ISPs in charge of
> implementing them ?
>
> I assume they are some blocked ports, and fake authoritative DNS zone
> files to redirect sites like bbc.co.uk to something else? Would DPI, on
> a national scale work to look at HTTP and HTTPS transactions to kill TCP
> sessione to IPs where the HTTP transaction has a banned work (such as
> "Host: www.bbc.co.uk"
>
The state owns China Unicom, China Telecom, and China Mobile, which is what 
everyone eventually connects into. PCCW is in Hong Kong and is not under the 
same scruitiny.
A lot of your questions about the great firewall of China can be answered by 
reading: https://en.wikipedia.org/wiki/Great_Firewall 
(https://link.getmailspring.com/link/local-56496eae-d14e-v1.1.4-22d9f20d@RKHTech-Laptop/0?redirect=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGreat_Firewall=Nanog%40nanog.org)
>
> 2-
> Bell Canada used to use DPI on 1gbps Ellacoya on its wireline Internet
> to detect and slow bittorrent flows down to dialup speeds. When it
> started to upgrade its core network to support FTTH in 2010, the upgrade
> of the BRAS routers to 10GBPS ports would have required Bell buy a
> totally new fleet of DPI boxes and keep buying whenever there were
> capacity upgrades. The math favoured increasing capacity instead of
> limiting use via DPI throttling, especially since traffic growth was
> with youtube and netflix , not bittorrent.
>
>
> fast forward 7-8 years to today: Is the deployment of dedicated DPI,
> capable of wire speed control of individual flows be economically
> feasable for wireline internet services? (DOCSIS and FTTH speeds).
>
> When Rogers and Comcast wanted to slow Netflix, underprovisioning links
> from the Netflix appliances/CDN is much cheaper than deploying DPI. Just
> curious if there is still an apetite for DPI for wireline ISPs that
> deploy at modern DOCSIS/FTTH speeds.
>
>
> Does the rapid move from HTTP to HTTPS render DPI for wire speed live
> control useless? ( I realise that blind collection of netflow data to
> be batch processed into billing systems to implement zero rating schemes
> is possible with normal routers and may not require dedicated DPI.
>
>
DPI will be useless, but that doesn't mean traffic patterns can be observed in 
other ways, resulting in QoS policies being applied at border routers.
> 3-
> In the case of the USA with ISPs slated to become AOL-like information
> providers, is there an expectation of widespread deployment of DPI
> equipment to "manage" the provision of information, or is the
> expectation that the ISPs will focus more on using netflow to impact the
> billing system and usage limits?
>
Netflow is not the only way to get usage stats, one can also measure the tx/rx 
bit differentiation at client facing interface with set intervals.
> 4-
> Or is DPI being deployed anyways to protect the networks from DDOS
> attacks, so adding website blocking would be possible?
>

I am not sure of any ISP using DPI on inbound to block traffic outbound.


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
> At some point, some chucklehead  is going to look at that .0.0 and mentally 
> think /16, and things will go pear-shaped pretty quickly

Same for a /12, which is RFC1918.

 Original message 
From: valdis.kletni...@vt.edu
Date: 12/8/17 1:46 PM (GMT-08:00)
To: Ryan Hamel <ryan.ha...@quadranet.com>
Cc: nanog@nanog.org
Subject: Re: Static Routing 172.16.0.0/32

On Fri, 08 Dec 2017 03:13:57 +, Ryan Hamel said:
> Greetings,

> A colleague of mine has static routed 172.16.0.0/32 to a usable IP address,
> to have a single known IP address be static routed to a regions closest 
> server.
> While I understand the IP address does work (pings and what not), I don't feel
> this should be the proper IP address used, but something more feasible like a
> usable IP in a dedicated range (172.31.0.0/24 for example).

Probably depends on what your colleague is trying to do.  Nothing in the
rules says the .0 address on a subnet is reserved (though you're in for a
surprise if there's any gear still on the net with a 4.2BSD stack).

> I would to hear everyone's thoughts on this, as this the first IP address in
> an RFC1918 range.

> At some point, some chucklehead  is going to look at that .0.0 and mentally 
> think /16, and things will go pear-shaped pretty quickly


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
I'm not implying HTTP, I'm implying a static route at each sites private layer 
3 router (it'll move to BGP in the future). The repository server listens on 
the IP as well.

My original question was the fact of using 172.16.0.0/32 as a usable IP address 
(not even caring about anycast).


 Original message 
From: William Herrin <b...@herrin.us>
Date: 12/8/17 1:45 PM (GMT-08:00)
To: Ryan Hamel <ryan.ha...@quadranet.com>
Cc: nanog@nanog.org
Subject: Re: Static Routing 172.16.0.0/32

On Fri, Dec 8, 2017 at 4:37 PM, Ryan Hamel 
<ryan.ha...@quadranet.com<mailto:ryan.ha...@quadranet.com>> wrote:
> 1. A single known ip address that redirects to the closest internal repo 
> server. 172.16.0.0/32<http://172.16.0.0/32> redirects to a usable subnet ip 
> in 172.16.xx.xx by static route.

Hi Ryan,

Maybe if would help if you write the extended version because that's about as 
clear as mud. First you asked about routing. Now you imply HTTP.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com<mailto:her...@dirtside.com> 
 b...@herrin.us<mailto:b...@herrin.us>
Dirtside Systems . Web: <http://www.dirtside.com/>


Re: Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
1. A single known ip address that redirects to the closest internal repo 
server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by static 
route.

2. Internal private network that is reachable by clients.

 Original message 
From: William Herrin <b...@herrin.us>
Date: 12/8/17 1:34 PM (GMT-08:00)
To: Ryan Hamel <ryan.ha...@quadranet.com>
Cc: nanog@nanog.org
Subject: Re: Static Routing 172.16.0.0/32



On Thu, Dec 7, 2017 at 10:13 PM, Ryan Hamel 
<ryan.ha...@quadranet.com<mailto:ryan.ha...@quadranet.com>> wrote:
A colleague of mine has static routed 172.16.0.0/32<http://172.16.0.0/32> to a 
usable IP address, to have a single known IP address be static routed to a 
regions closest server. While I understand the IP address does work (pings and 
what not), I don't feel this should be the proper IP address used, but 
something more feasible like a usable IP in a dedicated range 
(172.31.0.0/24<http://172.31.0.0/24> for example).

Hi Ryan,

Some clarifications:

1. You say, "static routed to a regions closest server." What do you mean by 
that? A static-routed anycast address?

2. In what reachability context? Is this a private network? An ISP network 
where the reachability should be the ISP and its customers?

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com<mailto:her...@dirtside.com> 
 b...@herrin.us<mailto:b...@herrin.us>
Dirtside Systems . Web: <http://www.dirtside.com/>


Static Routing 172.16.0.0/32

2017-12-08 Thread Ryan Hamel
Greetings,

A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, to 
have a single known IP address be static routed to a regions closest server. 
While I understand the IP address does work (pings and what not), I don't feel 
this should be the proper IP address used, but something more feasible like a 
usable IP in a dedicated range (172.31.0.0/24 for example).

I would to hear everyone's thoughts on this, as this the first IP address in an 
RFC1918 range.

Thanks,

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