Re: Hurricane Electric AS6939

[John Kristoff]

On Tue, 13 Oct 2020 23:29:55 +
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.

The price is usually amongst the lowest you'll find.  I've found them
very easy to work with. They have a pretty capable tools development
team in house.  They don't do communities other than RTBH. They are
doing ROV, which I think helped clean up some BGP noise I used to see,
but I've not checked lately.  They also know a thing or two about IPv6,
plus carry traffic for all those IPv6 tunnel broker setups and probably
at least if not more of the 6to4 traffic for whatever is left of that
if it matters to you (and I might argue you might want to consider not
accepting the 6to4 associated prefixes nor carry that traffic). Make
sure you maintain another way to get to Cogent-only prefixes.

John

RE: Hurricane Electric AS6939

[aaron1]

Don’t you have to be there to join?

 

I’m in Austin and San Antonio

 

-Aaron

 

From: Mike Hammett  
Sent: Tuesday, October 13, 2020 7:20 PM
To: Aaron Gould 
Cc: nanog@nanog.org
Subject: Re: Hurricane Electric AS6939

 

https://bgp.he.net/AS16527

 

You don't appear to be on any IXes. Definitely join some IXes before buying 
another 100G of transit.

 

DFW has a couple and there are some more that are starting up.

 



-
Mike Hammett
  Intelligent Computing Solutions
   
  
  
 
  Midwest Internet Exchange
   
  
 
  The Brothers WISP
   
 

  _  

From: "Aaron Gould" mailto:aar...@gvtc.com> >
To: nanog@nanog.org  
Sent: Tuesday, October 13, 2020 6:29:55 PM
Subject: Hurricane Electric AS6939

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: Hurricane Electric AS6939

[aaron1]

I have to be in Dallas for that right?

 

I’m in Austin (Data Foundry) and San Antonio (100 Taylor)

 

-Aaron

 

From: Ryan Hamel  
Sent: Tuesday, October 13, 2020 6:34 PM
To: Aaron Gould 
Cc: nanog@nanog.org
Subject: Re: Hurricane Electric AS6939

 

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 mailto:aar...@gvtc.com> > 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: Ingress filtering on transits, peers, and IX ports

[Seth Mattinen]

On 10/13/20 8:04 PM, Eric Kuhnke wrote:
If I had a dollar for every 'scary security alert' email received in a 
NOC email inbox from a 'security researcher group' that is the results 
of a port scan, or some small subset of trojan infected residential 
endpoint computers attempting outbound connections on 
($common_service_port), or similar...





I get stupid automated "abuse" notices all the time about being an evil 
haxx0r, which is actually just having egress proxy enabled on GGC.


The most crazy email I've had so far was saying that I "breached Section 
4 of the Terms and Conditions of the domain" and that my as (the AS the 
GGC nodes are behind) is "to immediately cease and desist" followed by a 
bunch of BS about how their IP addresses are restricted and no crawl 
rights have been granted blah blah blah.

Re: Ingress filtering on transits, peers, and IX ports

[Eric Kuhnke]

If I had a dollar for every 'scary security alert' email received in a NOC
email inbox from a 'security researcher group' that is the results of a
port scan, or some small subset of trojan infected residential endpoint
computers attempting outbound connections on ($common_service_port), or
similar...



On Tue, Oct 13, 2020 at 7:50 PM Chris Adams  wrote:

> Once upon a time, Eric Kuhnke  said:
> > Considering that one can run an instance of an anycasted recursive
> > nameserver, under heavy load for a very large number of clients, on a
> $600
> > 1U server these days... I wonder what exactly the threat model is.
>
> A customer forwarded one of these notices to us - looked like it's about
> recursive DNS cache poisoning.  It's been a while since I looked
> closely, but I thought modern recursive DNS software was pretty
> resistant to that, and anyway, the real answer to that is DNSSEC.
>
> I could be wrong, but getting a scary-sounding OMG SECURITY ALERT email
> from some group I've never heard of (and haven't AFAIK engaged the
> community about their "new" attack, scans, or notices)... seems more
> like shameless self promotion.
>
> --
> Chris Adams 
>

Re: Ingress filtering on transits, peers, and IX ports

[Chris Adams]

Once upon a time, Eric Kuhnke  said:
> Considering that one can run an instance of an anycasted recursive
> nameserver, under heavy load for a very large number of clients, on a $600
> 1U server these days... I wonder what exactly the threat model is.

A customer forwarded one of these notices to us - looked like it's about
recursive DNS cache poisoning.  It's been a while since I looked
closely, but I thought modern recursive DNS software was pretty
resistant to that, and anyway, the real answer to that is DNSSEC.

I could be wrong, but getting a scary-sounding OMG SECURITY ALERT email
from some group I've never heard of (and haven't AFAIK engaged the
community about their "new" attack, scans, or notices)... seems more
like shameless self promotion.

-- 
Chris Adams 

Re: Residential GPON last mile for network engineers (Telus AS852 and others)

[Daniel Dent]

On 2020-10-13 6:38 p.m., Eric Kuhnke wrote:


Any insights as to what the configuration of the Telus AS852 GPON 
network looks would be helpful. Or other observations in general on 
technically-oriented persons who are doing similar with other ILECs.


I have heard rumors that Telus's GPON deployment is a little bit 
different depending on when the location was connected to GPON, although 
I think they've been working towards having a single unified 
provisioning system. I'm unclear if there are user-impacting 
differences, I haven't noticed any.


I deal with several sites that are connected to Telus's consumer GPON 
network. Here are three samples:


1. Telus GPON is terminated to a Telus-provided media converter that 
provides a copper gigabit ethernet switch. The Telus-supported 
deployment involves some magic wifi gateway that speaks both DSL and 
Ethernet for WAN connectivity. Removing the magic box and using standard 
DHCP from my own networking equipment works fine. This site was amongst 
Telus's very first GPON deployments.


2. Telus GPON is terminated to a magic GPON SFP. The Telus-supported 
deployment involves an SFP being provided to CPE they deploy which has 
an SFP port (in addition to the DSL & Ethernet WAN uplink ports which 
are also present on that CPE). That SFP instead goes into my own 
equipment, and standard DHCP works fine. I specifically requested an 
SFP-based deployment when I ordered the service, and again from the 
technician that did the install. While the tech was confused why I would 
care, he was happy to oblige.


3. For a site that was deployed after I was familiar with how it went, I 
had my equipment at that site pre-configured to do DHCP on my SFP port 
prior to the technician arriving. The technician was quite happy to dash 
off to his next appointment when after plugging in the SFP I was able to 
confirm that everything was working. At that site I don't have any 
Telus-owned CPE other than their SFP, the technician had reason to 
provide any.


I have heard rumours that if you want their "Optik TV" service that it 
simply requires standard-but-undocumented VLAN tagging, but I've never 
had reason to care to find out.


Telus happily provides >1 IPv4 over DHCP to multiple devices on the 
interface, and their equipment also happily allocates a /56 in IPv6 
land. While there's lot to be unhappy about with Telus, they do a very 
good job with some of the important basics.


Regards,

Daniel Dent

https://www.danieldent.com/

Re: Virginia voter registration down due to cable cut

[Valdis Klētnieks]

On Tue, 13 Oct 2020 17:11:53 -0400, Christopher Morrow said:

> sorry I meant that: 1) yes clearly it's still the middle of
> roadwork/backhoe season, 2) i'm surprised that a single path failure
> for their production datacenter was enough to take the system offline.
> 'spof' there meant: "Wow, a single point of failure in their outside
> plant?"

Given that back in 2010, they suffered a *disastrous* outage when
a storage array failed and took multiple agencies with it

https://www.computerworld.com/article/2515423/northrop-grumman-takes-blame-for-va--it-services-outage.html

my reaction was more like

Surprise, surprise, surprise...


That one started when one storage array had a failed memory card, and
the backup array encountered issues as well.  There were a number of state
agencies and universities that had fought for increased self-governance, and
a *huge* part of that was "not be forced to outsource their internal IT to 
VITA",
and those units were very glad they had won that fight


pgpXflcrjyFc3.pgp
Description: PGP signature

Re: Residential GPON last mile for network engineers (Telus AS852 and others)

[Eric Kuhnke]

Very interesting. Looks like the intention is to bypass the ONT entirely
and use a GPON ONT SFP in ones own choice of small home router. If the ISP
wants to do some weird TR069 provisioning or other stuff it could be seen
as interfering with the proper management of their network if you remove
the CPE entirely.

In an ideal world, personally I would be totally fine with keeping a telco
provided small ONT configured as a dumb L2 bridge, with one optical
interface single strand (SC/APC) going to the ISP, and 1000BaseT to my own
router.

On Tue, Oct 13, 2020 at 6:51 PM Eric Dugas  wrote:

> I don't have any particular insights for Telus, but there is a huge thread
> about bypassing Bell ONTs on DSLReports:
> https://www.dslreports.com/forum/r32230041-Internet-Bypassing-the-HH3K-up-to-2-5Gbps-using-a-BCM57810S-NIC
> Cheers,
> Eric
> On Oct 13 2020, at 9:38 pm, Eric Kuhnke  wrote:
>
> With the growth of gigabit class single fiber GPON last mile services, I
> imagine a number of people reading the list must have subscribed to such by
> now.
>
> Something that I have observed, and shared observations with a number of
> colleagues, is that very often a person who works for ($someAS) lives in a
> location where you are effectively singlehomed to ($someotherAS). Maybe you
> bought your house before you got a job with your current employer, or maybe
> the network you work for doesn't do residential last mile service at all.
> Perhaps you work remotely for a regional sized entity that's a long
> distance away from where you live.
>
> Therefore necessitating a choice of service from whatever facilities based
> consumer-facing ISP happens to service your home.
>
> For example, in Seattle, a number of people discovered that they could
> keep the Centurylink GPON ONT, and remove the centurylink-provided
> router/modem combo device. Provided that they were able to configure their
> own router (small vyatta, pfsense box, mikrotik, whatever) to speak a
> certain VLAN tag on its WAN interface and be a normal PPPoE / DHCP client.
>
> I'm sure there are a lot of people who prefer to run their own home router
> and wifi devices, and not rely upon a ($big_residential_isp) provided
> all-in-one router/nat/wifi box with opaque configuration parameters, or no
> ability to change configuration at all.
>
> Any insights as to what the configuration of the Telus AS852 GPON network
> looks would be helpful. Or other observations in general on
> technically-oriented persons who are doing similar with other ILECs.
>
>

Re: Residential GPON last mile for network engineers (Telus AS852 and others)

[Eric Dugas via NANOG]

I don't have any particular insights for Telus, but there is a huge thread 
about bypassing Bell ONTs on DSLReports: 
https://www.dslreports.com/forum/r32230041-Internet-Bypassing-the-HH3K-up-to-2-5Gbps-using-a-BCM57810S-NIC
Cheers,
Eric
On Oct 13 2020, at 9:38 pm, Eric Kuhnke  wrote:
> With the growth of gigabit class single fiber GPON last mile services, I 
> imagine a number of people reading the list must have subscribed to such by 
> now.
>
> Something that I have observed, and shared observations with a number of 
> colleagues, is that very often a person who works for ($someAS) lives in a 
> location where you are effectively singlehomed to ($someotherAS). Maybe you 
> bought your house before you got a job with your current employer, or maybe 
> the network you work for doesn't do residential last mile service at all. 
> Perhaps you work remotely for a regional sized entity that's a long distance 
> away from where you live.
>
> Therefore necessitating a choice of service from whatever facilities based 
> consumer-facing ISP happens to service your home.
>
> For example, in Seattle, a number of people discovered that they could keep 
> the Centurylink GPON ONT, and remove the centurylink-provided router/modem 
> combo device. Provided that they were able to configure their own router 
> (small vyatta, pfsense box, mikrotik, whatever) to speak a certain VLAN tag 
> on its WAN interface and be a normal PPPoE / DHCP client.
>
> I'm sure there are a lot of people who prefer to run their own home router 
> and wifi devices, and not rely upon a ($big_residential_isp) provided 
> all-in-one router/nat/wifi box with opaque configuration parameters, or no 
> ability to change configuration at all.
>
> Any insights as to what the configuration of the Telus AS852 GPON network 
> looks would be helpful. Or other observations in general on 
> technically-oriented persons who are doing similar with other ILECs.

Re: Ingress filtering on transits, peers, and IX ports

[Eric Kuhnke]

Aside from the BCPs currently being discussed for ingress filtering, I
would be very interested in seeing what this traffic looked like from the
perspective of your DNS servers' logs.

I assume you're talking about customer facing recursive/caching resolvers,
and not authoritative-only nameservers.

Considering that one can run an instance of an anycasted recursive
nameserver, under heavy load for a very large number of clients, on a $600
1U server these days... I wonder what exactly the threat model is.

Reverse amplification of DNS traffic returning to the spoofed IPs for DoS
purposes, such as to cause the nameserver to DoS a single /32 endpoint IP
being targeted, as in common online gaming disputes?

What volume of pps or Mbps would appear as spurious traffic as a result of
this attack?



On Tue, Oct 13, 2020 at 3:14 PM Brian Knight via NANOG 
wrote:

> We recently received an email notice from a group of security
> researchers who are looking at the feasibility of attacks using spoofed
> traffic.  Their methodology, in broad strokes, was to send traffic to
> our DNS servers with a source IP that looked like it came from our
> network.  Their attacks were successful, and they included a summary of
> what they found.  So this message has started an internal conversation
> on what traffic we should be filtering and how.
>
> This security test was not about BCP 38 for ingress traffic from our
> customers, nor was it about BGP ingress filtering.  This tested our
> ingress filtering from the rest of the Internet.
>
> It seems to me like we should be filtering traffic with spoofed IPs on
> our transit, IX, and peering links.  I have done this filtering in the
> enterprise world extensively, and it's very helpful to keep out bad
> traffic.  BCP 84 also discusses ingress filtering for SP's briefly and
> seems to advocate for it.
>
> We have about 15 IP blocks allocated to us.  With a network as small as
> ours, I chose to go with a static ACL approach to start the
> conversation.  I crafted a static ACL, blocking all ingress traffic
> sourced from any of our assigned IP ranges.  I made sure to include:
>
> * Permit entries for P-t-P WAN subnets on peering links
> * Permit entries for IP assignments to customers running multi-homed BGP
> * The "permit ipv4 any any" at the end :)
>
> The questions I wanted to ask the SP community are:
>
> * What traffic filtering do you do on your transits, on IX ports, and
> your direct peering links?
> * How is it accomplished?  Through static ACL or some flavor of uRPF?
> * If you use static ACLs, what is the administrative overhead like?
> What makes it easy or difficult to update?
> * How did you test your filters when they were implemented?
>
> Thanks a lot,
>
> -Brian
>

Re: Ingress filtering on transits, peers, and IX ports

[Nikolas Geyer]

Specifically with regards to “Don’t accept your own prefix”, this poses an 
interesting challenge for the original notice sent out by the security 
researchers.

It is not uncommon today for various content networks (and others) to operate 
multiple “island networks” with a single ASN. For example, AS65001 operates in 
Los Angeles and New York, with no internal connectivity between them - only 
connectivity via the Internet (loop prevention disablement is done by every 
tier 1 provider upon request). Los Angeles advertises 192.168.10.0/24 and New 
York advertises 192.168.20.0/24 to the Internet, and both have relevant 
anti-spoofing filters (e.g. Los Angeles has an ingress filter to drop traffic 
with source IP of 192.168.10.0/24, and New York has an ingress filter to drop 
traffic with a source IP of 192.168.20.0/24). Traffic between Los Angeles and 
New York is not filtered as they need to legitimately pass traffic to each 
other over the Internet. This triggers a false positive detection by the system 
in question that sent the original notification email.

After discussing this with the people running this project and highlighting 
that this will be generating false positive data as part of their research (and 
probably quite a lot, this practice is fairly common), the response was to 
establish some form of tunnel between the AS islands over the Internet. Not 
realistic for a bunch of the content companies who practice this design pushing 
tens/hundreds of Gbps over the Internet (if not more). There seemed to be no 
interest in the discussion that the data being generated by this system is 
arguably flawed.

Tl;dr - definitely don’t accept your own prefix from the site it originated 
from, or other sites that have internal connectivity. But also don’t assume 
that an AS has a full-mesh of internal connectivity behind it and shouldn’t 
accept its own prefixes for any reason. 

Sent from my iPhone

> On Oct 13, 2020, at 7:54 PM, Marcos Manoni  wrote:
> 
> Hi, Brian
> 
> Check RFC3704/BCP84 Ingress Filtering for Multihomed Networks (Updated
> by: RFC8704 Enhanced Feasible-Path uRPF).
> 
>Ingress Access Lists require typically manual maintenance, but are
>the most bulletproof when done properly; typically, ingress access
>lists are best fit between the edge and the ISP when the
>configuration is not too dynamic if strict RPF is not an option,
>between ISPs if the number of used prefixes is low, or as an
>additional layer of protection
> 
> 
> Ingress filters Best Practices
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf
> *Don’t accept BOGON ASNs
> *Don’t accept BOGON prefixes
> *Don’t accept your own prefix
> *Don’t accept default (unless you requested it)
> *Don’t accept prefixes that are too specific
> *Don’t accept if AS Path is too long
> *Create filters based on Internet Routing Registries
> 
> And also BGP Best Current Practices by Philip Smith
> http://www.bgp4all.com.au/pfs/_media/workshops/05-bgp-bcp.pdf
> 
> Regards.
> 
>> El mar., 13 oct. 2020 a las 19:52, Brian Knight via NANOG
>> () escribió:
>> 
>> Hi Mel,
>> 
>> My understanding of uRPF is:
>> 
>> * Strict mode will permit a packet only if there is a route for the source 
>> IP in the RIB, and that route points to the interface where the packet was 
>> received
>> 
>> * Loose mode will permit a packet if there is a route for the source IP in 
>> the RIB.  It does not matter where the route is pointed.
>> 
>> Strict mode won't work for us, because with our multi-homed transits and IX 
>> peers, we will almost certainly drop a legitimate packet because the best 
>> route is through another transit.
>> 
>> Loose mode won't work for us, because all of our own prefixes are in our 
>> RIB, and thus the uRPF check on a transit would never block anything.
>> 
>> Or am I missing something?
>> 
>> Thanks,
>> 
>> -Brian
>> 
>> On 2020-10-13 17:22, Mel Beckman wrote:
>> 
>> You can also use Unicast Reverse Path Forwarding. RPF is more efficient than 
>> ACLs, and has the added advantage of not requiring maintenance. In a 
>> nutshell, if your router has a route to a prefix in its local RIB, then 
>> incoming packets from a border interface having a matching source IP will be 
>> dropped.
>> 
>> RPF has knobs and dials to make it work for various ISP environments. 
>> Implement it carefully (as is be standing next to the router involved :)
>> 
>> Here's a Cisco brief on the topic:
>> 
>> 
>> https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding
>> 
>> 
>> 
>> 
>> 
>> I think all router vendors support this feature. Here's a similar article by 
>> Juniper:
>> 
>> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html
>> 
>> 
>> -mel beckman
>> 
>> On Oct 13, 2020, at 3:15 PM, Brian Knight via NANOG  wrote:
>> 
>> We recently received an email notice from a group of security 

Residential GPON last mile for network engineers (Telus AS852 and others)

[Eric Kuhnke]

With the growth of gigabit class single fiber GPON last mile services, I
imagine a number of people reading the list must have subscribed to such by
now.

Something that I have observed, and shared observations with a number of
colleagues, is that very often a person who works for ($someAS) lives in a
location where you are effectively singlehomed to ($someotherAS). Maybe you
bought your house before you got a job with your current employer, or maybe
the network you work for doesn't do residential last mile service at all.
Perhaps you work remotely for a regional sized entity that's a long
distance away from where you live.

Therefore necessitating a choice of service from whatever facilities based
consumer-facing ISP happens to service your home.

For example, in Seattle, a number of people discovered that they could keep
the Centurylink GPON ONT, and remove the centurylink-provided router/modem
combo device. Provided that they were able to configure their own router
(small vyatta, pfsense box, mikrotik, whatever) to speak a certain VLAN tag
on its WAN interface and be a normal PPPoE / DHCP client.

I'm sure there are a lot of people who prefer to run their own home router
and wifi devices, and not rely upon a ($big_residential_isp) provided
all-in-one router/nat/wifi box with opaque configuration parameters, or no
ability to change configuration at all.

Any insights as to what the configuration of the Telus AS852 GPON network
looks would be helpful. Or other observations in general on
technically-oriented persons who are doing similar with other ILECs.

Re: Hurricane Electric AS6939

[craig washington]

Side note, they don’t support any traffic engineer aside from prepends but no 
complaints Besides that.



On Oct 13, 2020, at 8:25 PM, Mike Hammett 
mailto:na...@ics-il.net>> wrote:

https://bgp.he.net/AS16527

You don't appear to be on any IXes. Definitely join some IXes before buying 
another 100G of transit.

DFW has a couple and there are some more that are starting up.



-
Mike Hammett
Intelligent Computing Solutions
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
Midwest Internet Exchange
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
The Brothers WISP
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png]

From: "Aaron Gould" mailto:aar...@gvtc.com>>
To: nanog@nanog.org
Sent: Tuesday, October 13, 2020 6:29:55 PM
Subject: Hurricane Electric AS6939

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: Hurricane Electric AS6939

[Mike Hammett]

https://bgp.he.net/AS16527 


You don't appear to be on any IXes. Definitely join some IXes before buying 
another 100G of transit. 


DFW has a couple and there are some more that are starting up. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Aaron Gould"  
To: nanog@nanog.org 
Sent: Tuesday, October 13, 2020 6:29:55 PM 
Subject: Hurricane Electric AS6939 

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: Hurricane Electric AS6939

[Seth Mattinen]

On 10/13/20 5:10 PM, Darin Steffl wrote:


You would do well to add them to your mix and remove one of the other 
ones. I'd probably remove spectrum and replace with HE. We've only had 
30 minutes of downtime total in 5 years so they've been very reliable 
for us.



I removed Spectrum (Charter) and replaced them with HE. The latter's 
value proposition was far superior, plus HE is friendlier to work with, 
and easier to get in touch with a clued individual at HE.

Re: Hurricane Electric AS6939

[Darin Steffl]

In Minnesota, hurricane has the lowest latency and most routes out of our
state. I can reach most destinations with lower latency than any other
carrier I've tested.

Their NOC is great and easy to reach. Billing is perfect and predictable
with no hidden fees or surcharges in the fine print. And their pricing is
some of the best out there.

They peer with anyone who wants to peer and they're on more IX's than any
other provider.

You would do well to add them to your mix and remove one of the other ones.
I'd probably remove spectrum and replace with HE. We've only had 30 minutes
of downtime total in 5 years so they've been very reliable for us.

On Tue, Oct 13, 2020, 7:01 PM Brandon Martin 
wrote:

> On 10/13/20 7: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.
>
> They're a good bulk/budget option in a blend.  A decent number of
> content hosts are keen to source traffic into them.  I would be loathe
> to be single-homed to them, but even then they're not the worst option
> in that department.
>
> If you've already got Telia, Spectrum, and Cogent, 6939 is probably a
> great addition to your blend.
>
> They'll probably want a 5yr contract out of you to get their best (and
> headline per-Mbps) rate.  Evaluate carefully what position that puts you
> in based on the continually dropping cost of wholesale transit and bulk
> interconnect opportunities.  You may prefer a shorter contract term at
> slightly higher rates.
>
> As others said, if you don't need full routes from them, they have a
> VERY open peering policy, and that 100G port might be better suited to a
> local IX where you can pick them up along with a bunch of other content
> networks.
> --
> Brandon Martin
>

Re: Hurricane Electric AS6939

[Brandon Martin]

On 10/13/20 7: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.


They're a good bulk/budget option in a blend.  A decent number of 
content hosts are keen to source traffic into them.  I would be loathe 
to be single-homed to them, but even then they're not the worst option 
in that department.


If you've already got Telia, Spectrum, and Cogent, 6939 is probably a 
great addition to your blend.


They'll probably want a 5yr contract out of you to get their best (and 
headline per-Mbps) rate.  Evaluate carefully what position that puts you 
in based on the continually dropping cost of wholesale transit and bulk 
interconnect opportunities.  You may prefer a shorter contract term at 
slightly higher rates.


As others said, if you don't need full routes from them, they have a 
VERY open peering policy, and that 100G port might be better suited to a 
local IX where you can pick them up along with a bunch of other content 
networks.

--
Brandon Martin

Re: Ingress filtering on transits, peers, and IX ports

[Marcos Manoni]

Hi, Brian

Check RFC3704/BCP84 Ingress Filtering for Multihomed Networks (Updated
by: RFC8704 Enhanced Feasible-Path uRPF).

Ingress Access Lists require typically manual maintenance, but are
the most bulletproof when done properly; typically, ingress access
lists are best fit between the edge and the ISP when the
configuration is not too dynamic if strict RPF is not an option,
between ISPs if the number of used prefixes is low, or as an
additional layer of protection


Ingress filters Best Practices
https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf
*Don’t accept BOGON ASNs
*Don’t accept BOGON prefixes
*Don’t accept your own prefix
*Don’t accept default (unless you requested it)
*Don’t accept prefixes that are too specific
*Don’t accept if AS Path is too long
*Create filters based on Internet Routing Registries

And also BGP Best Current Practices by Philip Smith
http://www.bgp4all.com.au/pfs/_media/workshops/05-bgp-bcp.pdf

Regards.

El mar., 13 oct. 2020 a las 19:52, Brian Knight via NANOG
() escribió:
>
> Hi Mel,
>
> My understanding of uRPF is:
>
> * Strict mode will permit a packet only if there is a route for the source IP 
> in the RIB, and that route points to the interface where the packet was 
> received
>
> * Loose mode will permit a packet if there is a route for the source IP in 
> the RIB.  It does not matter where the route is pointed.
>
> Strict mode won't work for us, because with our multi-homed transits and IX 
> peers, we will almost certainly drop a legitimate packet because the best 
> route is through another transit.
>
> Loose mode won't work for us, because all of our own prefixes are in our RIB, 
> and thus the uRPF check on a transit would never block anything.
>
> Or am I missing something?
>
> Thanks,
>
> -Brian
>
> On 2020-10-13 17:22, Mel Beckman wrote:
>
> You can also use Unicast Reverse Path Forwarding. RPF is more efficient than 
> ACLs, and has the added advantage of not requiring maintenance. In a 
> nutshell, if your router has a route to a prefix in its local RIB, then 
> incoming packets from a border interface having a matching source IP will be 
> dropped.
>
> RPF has knobs and dials to make it work for various ISP environments. 
> Implement it carefully (as is be standing next to the router involved :)
>
> Here's a Cisco brief on the topic:
>
>
> https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding
>
>
>
>
>
> I think all router vendors support this feature. Here's a similar article by 
> Juniper:
>
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html
>
>
> -mel beckman
>
> On Oct 13, 2020, at 3:15 PM, Brian Knight via NANOG  wrote:
>
> We recently received an email notice from a group of security researchers who 
> are looking at the feasibility of attacks using spoofed traffic.  Their 
> methodology, in broad strokes, was to send traffic to our DNS servers with a 
> source IP that looked like it came from our network.  Their attacks were 
> successful, and they included a summary of what they found.  So this message 
> has started an internal conversation on what traffic we should be filtering 
> and how.
>
> This security test was not about BCP 38 for ingress traffic from our 
> customers, nor was it about BGP ingress filtering.  This tested our ingress 
> filtering from the rest of the Internet.
>
> It seems to me like we should be filtering traffic with spoofed IPs on our 
> transit, IX, and peering links.  I have done this filtering in the enterprise 
> world extensively, and it's very helpful to keep out bad traffic.  BCP 84 
> also discusses ingress filtering for SP's briefly and seems to advocate for 
> it.
>
> We have about 15 IP blocks allocated to us.  With a network as small as ours, 
> I chose to go with a static ACL approach to start the conversation.  I 
> crafted a static ACL, blocking all ingress traffic sourced from any of our 
> assigned IP ranges.  I made sure to include:
>
> * Permit entries for P-t-P WAN subnets on peering links
>
> * Permit entries for IP assignments to customers running multi-homed BGP
>
> * The "permit ipv4 any any" at the end :)
>
> The questions I wanted to ask the SP community are:
>
> * What traffic filtering do you do on your transits, on IX ports, and your 
> direct peering links?
>
> * How is it accomplished?  Through static ACL or some flavor of uRPF?
>
> * If you use static ACLs, what is the administrative overhead like?  What 
> makes it easy or difficult to update?
>
> * How did you test your filters when they were implemented?
>
> Thanks a lot,
>
> -Brian
>
>

Re: Hurricane Electric AS6939

[TJ Trout]

sounds like he needs full routes..

On Tue, Oct 13, 2020 at 4:36 PM Ryan Hamel  wrote:

> 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: Hurricane Electric AS6939

[Ryan Hamel]

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

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

Hurricane Electric AS6939

[Aaron Gould]

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: Ingress filtering on transits, peers, and IX ports

[Brian Knight via NANOG]

Hi Mel, 

My understanding of uRPF is: 

* Strict mode will permit a packet only if there is a route for the
source IP in the RIB, and that route points to the interface where the
packet was received 

* Loose mode will permit a packet if there is a route for the source IP
in the RIB.  It does not matter where the route is pointed. 

Strict mode won't work for us, because with our multi-homed transits and
IX peers, we will almost certainly drop a legitimate packet because the
best route is through another transit. 

Loose mode won't work for us, because all of our own prefixes are in our
RIB, and thus the uRPF check on a transit would never block anything. 

Or am I missing something? 

Thanks, 

-Brian 

On 2020-10-13 17:22, Mel Beckman wrote:

> You can also use Unicast Reverse Path Forwarding. RPF is more efficient than 
> ACLs, and has the added advantage of not requiring maintenance. In a 
> nutshell, if your router has a route to a prefix in its local RIB, then 
> incoming packets from a border interface having a matching source IP will be 
> dropped. 
> 
> RPF has knobs and dials to make it work for various ISP environments. 
> Implement it carefully (as is be standing next to the router involved :) 
> 
> Here's a Cisco brief on the topic: 
> 
> https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding
>  
> 
> I think all router vendors support this feature. Here's a similar article by 
> Juniper: 
> 
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html
>  
> 
> -mel beckman
> 
>> On Oct 13, 2020, at 3:15 PM, Brian Knight via NANOG  wrote:
> 
>> We recently received an email notice from a group of security researchers 
>> who are looking at the feasibility of attacks using spoofed traffic.  Their 
>> methodology, in broad strokes, was to send traffic to our DNS servers with a 
>> source IP that looked like it came from our network.  Their attacks were 
>> successful, and they included a summary of what they found.  So this message 
>> has started an internal conversation on what traffic we should be filtering 
>> and how.
> 
>> This security test was not about BCP 38 for ingress traffic from our 
>> customers, nor was it about BGP ingress filtering.  This tested our ingress 
>> filtering from the rest of the Internet.
> 
>> It seems to me like we should be filtering traffic with spoofed IPs on our 
>> transit, IX, and peering links.  I have done this filtering in the 
>> enterprise world extensively, and it's very helpful to keep out bad traffic. 
>>  BCP 84 also discusses ingress filtering for SP's briefly and seems to 
>> advocate for it.
> 
>> We have about 15 IP blocks allocated to us.  With a network as small as 
>> ours, I chose to go with a static ACL approach to start the conversation.  I 
>> crafted a static ACL, blocking all ingress traffic sourced from any of our 
>> assigned IP ranges.  I made sure to include:
> 
>> * Permit entries for P-t-P WAN subnets on peering links
> 
>> * Permit entries for IP assignments to customers running multi-homed BGP
> 
>> * The "permit ipv4 any any" at the end :)
> 
>> The questions I wanted to ask the SP community are:
> 
>> * What traffic filtering do you do on your transits, on IX ports, and your 
>> direct peering links?
> 
>> * How is it accomplished?  Through static ACL or some flavor of uRPF?
> 
>> * If you use static ACLs, what is the administrative overhead like?  What 
>> makes it easy or difficult to update?
> 
>> * How did you test your filters when they were implemented?
> 
>> Thanks a lot,
> 
>> -Brian

RE: Ingress filtering on transits, peers, and IX ports

[Jean St-Laurent via NANOG]

That’s an interesting suggestion

 

There are 2 modes for uRPF. Loose and strict.

 

Which one would you recommend in this scenario and why?

 

There are many ways to solve this and definitely uRPF is one layer of defense. 
But, probably not the best alone. I advocate a 3 layers approach.

 

I’m curious to hear/read which uRPF would you recommend for this particular 
case.

 

Thanks

Jean St-Laurent

 

 

From: NANOG  On Behalf Of Mel Beckman
Sent: Tuesday, October 13, 2020 6:22 PM
To: Brian Knight 
Cc: nanog@nanog.org
Subject: Re: Ingress filtering on transits, peers, and IX ports

 

You can also use Unicast Reverse Path Forwarding. RPF is more efficient than 
ACLs, and has the added advantage of not requiring maintenance. In a nutshell, 
if your router has a route to a prefix in its local RIB, then incoming packets 
from a border interface having a matching source IP will be dropped.

 

RPF has knobs and dials to make it work for various ISP environments. Implement 
it carefully (as is be standing next to the router involved :)

 

Here’s a Cisco brief on the topic:

 

https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding

 

 

I think all router vendors support this feature. Here’s a similar article by 
Juniper:

 

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html

 


-mel beckman




On Oct 13, 2020, at 3:15 PM, Brian Knight via NANOG mailto:nanog@nanog.org> > wrote:

 

We recently received an email notice from a group of security researchers who 
are looking at the feasibility of attacks using spoofed traffic.  Their 
methodology, in broad strokes, was to send traffic to our DNS servers with a 
source IP that looked like it came from our network.  Their attacks were 
successful, and they included a summary of what they found.  So this message 
has started an internal conversation on what traffic we should be filtering and 
how.

 

This security test was not about BCP 38 for ingress traffic from our customers, 
nor was it about BGP ingress filtering.  This tested our ingress filtering from 
the rest of the Internet.

 

It seems to me like we should be filtering traffic with spoofed IPs on our 
transit, IX, and peering links.  I have done this filtering in the enterprise 
world extensively, and it's very helpful to keep out bad traffic.  BCP 84 also 
discusses ingress filtering for SP's briefly and seems to advocate for it.

 

We have about 15 IP blocks allocated to us.  With a network as small as ours, I 
chose to go with a static ACL approach to start the conversation.  I crafted a 
static ACL, blocking all ingress traffic sourced from any of our assigned IP 
ranges.  I made sure to include:

 

* Permit entries for P-t-P WAN subnets on peering links

* Permit entries for IP assignments to customers running multi-homed BGP

* The "permit ipv4 any any" at the end :)

 

The questions I wanted to ask the SP community are:

 

* What traffic filtering do you do on your transits, on IX ports, and your 
direct peering links?

* How is it accomplished?  Through static ACL or some flavor of uRPF?

* If you use static ACLs, what is the administrative overhead like?  What makes 
it easy or difficult to update?

* How did you test your filters when they were implemented?

 

Thanks a lot,

 

-Brian

Re: Ingress filtering on transits, peers, and IX ports

[Matt Harris]

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 Tue, Oct 13, 2020 at 5:22 PM Mel Beckman  wrote:

> You can also use Unicast Reverse Path Forwarding. RPF is more efficient
> than ACLs, and has the added advantage of not requiring maintenance. In a
> nutshell, if your router has a route to a prefix in its local RIB, then
> incoming packets from a border interface having a matching source IP will
> be dropped.
>
> RPF has knobs and dials to make it work for various ISP environments.
> Implement it carefully (as is be standing next to the router involved :
>

I received one of the aforementioned messages as well, and my response was
that perhaps the best overall step towards protection at scale from the
issue they raise would be for SPs to implement URPF facing stubby,
single-homed networks. This is effectively the low-hanging fruit and
doesn't require too much additional labor in terms of maintaining
additional ACLs or prefix lists. In the case of multi-homed networks,
things are less straight forward, but multi-homed networks make up a
minority even if we exclude consumer internet connections.

Take care,
Matt

Re: Ingress filtering on transits, peers, and IX ports

[Mel Beckman]

You can also use Unicast Reverse Path Forwarding. RPF is more efficient than 
ACLs, and has the added advantage of not requiring maintenance. In a nutshell, 
if your router has a route to a prefix in its local RIB, then incoming packets 
from a border interface having a matching source IP will be dropped.

RPF has knobs and dials to make it work for various ISP environments. Implement 
it carefully (as is be standing next to the router involved :)

Here’s a Cisco brief on the topic:


https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding



I think all router vendors support this feature. Here’s a similar article by 
Juniper:

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html


-mel beckman

On Oct 13, 2020, at 3:15 PM, Brian Knight via NANOG  wrote:

We recently received an email notice from a group of security researchers who 
are looking at the feasibility of attacks using spoofed traffic.  Their 
methodology, in broad strokes, was to send traffic to our DNS servers with a 
source IP that looked like it came from our network.  Their attacks were 
successful, and they included a summary of what they found.  So this message 
has started an internal conversation on what traffic we should be filtering and 
how.

This security test was not about BCP 38 for ingress traffic from our customers, 
nor was it about BGP ingress filtering.  This tested our ingress filtering from 
the rest of the Internet.

It seems to me like we should be filtering traffic with spoofed IPs on our 
transit, IX, and peering links.  I have done this filtering in the enterprise 
world extensively, and it's very helpful to keep out bad traffic.  BCP 84 also 
discusses ingress filtering for SP's briefly and seems to advocate for it.

We have about 15 IP blocks allocated to us.  With a network as small as ours, I 
chose to go with a static ACL approach to start the conversation.  I crafted a 
static ACL, blocking all ingress traffic sourced from any of our assigned IP 
ranges.  I made sure to include:

* Permit entries for P-t-P WAN subnets on peering links
* Permit entries for IP assignments to customers running multi-homed BGP
* The "permit ipv4 any any" at the end :)

The questions I wanted to ask the SP community are:

* What traffic filtering do you do on your transits, on IX ports, and your 
direct peering links?
* How is it accomplished?  Through static ACL or some flavor of uRPF?
* If you use static ACLs, what is the administrative overhead like?  What makes 
it easy or difficult to update?
* How did you test your filters when they were implemented?

Thanks a lot,

-Brian

Ingress filtering on transits, peers, and IX ports

[Brian Knight via NANOG]

We recently received an email notice from a group of security 
researchers who are looking at the feasibility of attacks using spoofed 
traffic.  Their methodology, in broad strokes, was to send traffic to 
our DNS servers with a source IP that looked like it came from our 
network.  Their attacks were successful, and they included a summary of 
what they found.  So this message has started an internal conversation 
on what traffic we should be filtering and how.


This security test was not about BCP 38 for ingress traffic from our 
customers, nor was it about BGP ingress filtering.  This tested our 
ingress filtering from the rest of the Internet.


It seems to me like we should be filtering traffic with spoofed IPs on 
our transit, IX, and peering links.  I have done this filtering in the 
enterprise world extensively, and it's very helpful to keep out bad 
traffic.  BCP 84 also discusses ingress filtering for SP's briefly and 
seems to advocate for it.


We have about 15 IP blocks allocated to us.  With a network as small as 
ours, I chose to go with a static ACL approach to start the 
conversation.  I crafted a static ACL, blocking all ingress traffic 
sourced from any of our assigned IP ranges.  I made sure to include:


* Permit entries for P-t-P WAN subnets on peering links
* Permit entries for IP assignments to customers running multi-homed BGP
* The "permit ipv4 any any" at the end :)

The questions I wanted to ask the SP community are:

* What traffic filtering do you do on your transits, on IX ports, and 
your direct peering links?

* How is it accomplished?  Through static ACL or some flavor of uRPF?
* If you use static ACLs, what is the administrative overhead like?  
What makes it easy or difficult to update?

* How did you test your filters when they were implemented?

Thanks a lot,

-Brian

Re: Virginia voter registration down due to cable cut

[Christopher Morrow]

On Tue, Oct 13, 2020 at 2:41 PM Sean Donelan  wrote:
>
> On Tue, 13 Oct 2020, Christopher Morrow wrote:
> > spof
> >
> > the vita folk have a history of 'not really understanding large scale
> > compute/network operations' :(
>
> Reportedly, the VITA data center and Virginia voter registration system is
> back up.
>
> According to VITA, a Verizon fiber was struck during a roadside utilities
> construction project near Route 10 in Chester, VA.  As network engineers
> know, fiber cuts happen all the time due to construction.  Malicious cuts
> and sabatoge occur, but are rare and usually obvious. Absent clear and
> compelling evidence, assume normal stupid reasons for outages.
>

sorry I meant that: 1) yes clearly it's still the middle of
roadwork/backhoe season, 2) i'm surprised that a single path failure
for their production datacenter was enough to take the system offline.
'spof' there meant: "Wow, a single point of failure in their outside
plant?"

>
> There are various long-term structural problems with election
> administration across 10,000+ jurisdictions in the United States.  A lot
> of duct-tape and heroic work needed by election administrators to keep
> things running.
>
>
> Election administration in Australia, Norway and Luxembourg tend to score
> the best with 10 out of 10 according to international election observers.
>
> Election administration in the United States of American tends to score
> around 7 or 8. There will be problems and delays. Not perfect,
> embarrassing and USA should do better. But still a full and free election.

Re: Passive Wave Primer

[Dave Cohen]

From the perspective of a large carrier, spectrum is an operational nightmare. 
At a former $dayjob it was an “offering” in the sense that we had deployed it, 
told customers we offered it but wouldn’t actually deploy it anymore. 

Logistically there are a lot of potential points of failure once you got beyond 
the distance threshold where mid-line amps would be required, and as alluded to 
here, no big carrier would want to take on risk to the network that they’re not 
in control of. There’s not much sense in doing it in shorter-distance scenarios 
when most folks needing enough bandwidth to even have the conversation are 
going to be able to run their own optical systems across dark fiber at that 
distance anyway. The customers that we talked to about it were almost 
exclusively other carriers that wanted to use the muxes they had in inventory 
(aka not the same platform as the photonic layer) without the burden of 
deploying/managing a lot of amps but had no issue taking OTN or even LAN PHY in 
bulk when push came to shove. 

FWIW, and I understand these terms have become fungible over time, the scenario 
above is spectrum from the perspective of the photonic layer owner and alien 
wave from the perspective of the customer. As the photonic layer owner, alien 
wave would generally be thought of as 1) accepting a handoff as a WDM-specific 
channel of light, whether on fixed or tunable optics, not a standard 1310/1550, 
and, typically but not necessarily, 2) accepting a signal that is framed as 
OTN, not LAN PHY or WAN PHY.  

For the record, the OP’s query about passive wave would suggest PON/GPON or 
similar low-power CWDM for short-haul use, and not spectrum or alien wave, both 
of which are decidedly non-passive. 

Dave Cohen
craetd...@gmail.com

> On Oct 13, 2020, at 4:24 PM, Brandon Martin  wrote:
> 
> On 10/13/20 4:01 PM, Mike Hammett wrote:
>> It seems incredibly simple to do, depending on the capabilities of your 
>> platform.
>> What am I missing?
> 
> If the span between the mux/demux pair is entirely passive, it's fairly 
> straightforward.  That's going to limit distances to around 80km or so with 
> conventional systems or maybe 120km with systems designed entirely around 
> modern coherent optics.
> 
> If there are photonic devices in the span, you now have customer-supplied 
> light being part of the rainbow that those photonics have to handle.  
> Balancing things at amplifiers requires careful coordination with the 
> customer (or adding a separate managed/monitored VOA for each alien wave 
> which somewhat defeats the point).  You end up with a scenario where a 
> customer can do something screwy and potentially affect other waves on 
> potentially multiple spans which your big-name carriers are obviously 
> completely freaked out by.
> 
> It's obviously possible, but the operational headache seems large enough that 
> the major mid-haul and long-haul carriers I've talked to (all North America 
> and all midwest, for that matter), don't seem to want to sell it despite all 
> the major optical transport platform vendors not just supporting it by 
> heavily pushing it.
> 
> I really do hope it becomes a real product that I (as a smaller, local island 
> operator) can buy, but it just doesn't seem to be there yet at least in my 
> region.
> -- 
> Brandon Martin

Re: Passive Wave Primer

[Brandon Martin]

On 10/13/20 4:01 PM, Mike Hammett wrote:
It seems incredibly simple to do, depending on the capabilities of your 
platform.


What am I missing?


If the span between the mux/demux pair is entirely passive, it's fairly 
straightforward.  That's going to limit distances to around 80km or so 
with conventional systems or maybe 120km with systems designed entirely 
around modern coherent optics.


If there are photonic devices in the span, you now have 
customer-supplied light being part of the rainbow that those photonics 
have to handle.  Balancing things at amplifiers requires careful 
coordination with the customer (or adding a separate managed/monitored 
VOA for each alien wave which somewhat defeats the point).  You end up 
with a scenario where a customer can do something screwy and potentially 
affect other waves on potentially multiple spans which your big-name 
carriers are obviously completely freaked out by.


It's obviously possible, but the operational headache seems large enough 
that the major mid-haul and long-haul carriers I've talked to (all North 
America and all midwest, for that matter), don't seem to want to sell it 
despite all the major optical transport platform vendors not just 
supporting it by heavily pushing it.


I really do hope it becomes a real product that I (as a smaller, local 
island operator) can buy, but it just doesn't seem to be there yet at 
least in my region.

--
Brandon Martin

Re: Passive Wave Primer

[TJ Trout]

Thanks for the explanation, I always thought 'waves' were 'alien waves' I
guess, I thought you had to coordinate the channel and you used wdm optics,
I didn't realize they normally are provisioned with ethernet to a OTN then
get channelized, good info.

On Tue, Oct 13, 2020 at 11:36 AM Tony Wicks  wrote:

> An Alien wave comes in from an external source, for an example a customer
> has WDM optics in their kit. A normal wave the “customer” connects with a
> normal 10GE/100GE (or whatever is appropriate) and a line card on the OTN
> platform “grooms” that to the appropriate WDM channel.
>
>
>
> *From:* NANOG  *On Behalf Of *TJ
> Trout
> *Sent:* Wednesday, 14 October 2020 6:22 am
> *To:* James Jun 
> *Cc:* nanog 
> *Subject:* Re: Passive Wave Primer
>
>
>
> What is the difference between a normal wave and a alien wave?
>
>
>

Re: Passive Wave Primer

[Brandon Martin]

On 10/13/20 3:35 PM, Tony Wicks wrote:

We sell some wavelengths on passive CWDM/DWDM path's between Datacentres
(less than 80Km) to customers to spread the cost of leasing the dark fibre.
But yes, as far as long distance (apart from bespoke offerings) I'm yet to
see a productised alien wave service. If you are spending all that money on
OTN kit the extra cost of the transponders is not really significant I
suppose.


It's in some providers' catalogs (amazingly) but they seem loathe to 
actually sell it when asked.  Even then, you're spot on with the 
description of "bespoke".  I saw Zayo's product description sheet for 
it, and, while it did seem to check the boxes I'd expect, it was also 
quite expectedly very complex (they also wouldn't actually sell it to me).


At less than 80km, you don't have to worry so much about balancing light 
levels, etc. as you can usually just throw things straight into a 
mux/demux on each end and rely on the power budget of the transceiver 
itself, so that makes sense for cheap DCI.

--
Brandon Martin

Re: Passive Wave Primer

[Mike Hammett]

It seems incredibly simple to do, depending on the capabilities of your 
platform. 

What am I missing? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Brandon Martin"  
To: nanog@nanog.org 
Sent: Tuesday, October 13, 2020 2:11:24 PM 
Subject: Re: Passive Wave Primer 

On 10/13/20 8:27 AM, Rod Beck wrote: 
> Looking for a tutorial on passive waves. How it works. Pros and cons. . 

If you're talking about what I think you are, the term the folks who 
make the transport gear seem to use is "spectrum" as in you (as service 
provider) sell your customer some portion of the WDM transport spectrum. 
It typically comes in 50GHz increments or sometimes 100GHz 
corresponding to the standard ITU channel system but not always. 

To the service provider, this is then an "alien wave" in that they have 
essentially no control or visibility into it other than light shows up, 
and they're responsible for getting it to the other end of the path with 
acceptable path characteristics. 

I have yet to find a service provider that is actually willing to sell 
this even when they have it in their service offering catalog. The 
difficulties of coordinating everything with the customer are so extreme 
that it seems to usually make sense to either lease the customer dark 
fiber or capitalize the transponders needed to carry it as a managed 
wave on the provider's transport system. Might make sense if you 
literally want half the spectrum on a long-haul span or something. 

-- 
Brandon Martin 

RE: Juniper configuration recommendations/BCP

[Jakob Heitz (jheitz) via NANOG]

IOS-XR accepts extended communities and large communities by default.
You have to enable to send them, but not receive.

Regards,
Jakob.

-Original Message-
Date: Mon, 12 Oct 2020 15:06:05 +0100
From: 

Here's a fun one.
By default Junos accepts extended communities on any BGP session (not just
on MP-BGP sessions like it's the default case on cisco -unless explicitly
enabled).
Since most operators are not aware of this default Junos behaviour, one can
be importing routes to interesting places if one were so inclined.  

-so yeah bleach unwanted communities on ingress (bleach those that would
interfere with the ones used by the AS internally -so called
"untaggable"/"untouchable" ).  

adam

> -Original Message-
> From: NANOG  bounces+adamv0025=netconsultings@nanog.org> On Behalf Of
> Chriztoffer Hansen
> Sent: Thursday, October 8, 2020 11:05 AM
> To: nanog@nanog.org
> Subject: Juniper configuration recommendations/BCP
> Importance: Low
> 
> 
> On 08/10/2020 11:37, Forrest Christian (List Account) wrote:
> > Is there anything I should worry about which is Juniper-specific?
> 
> JUNOS default ARP timeout: 20 min.
> 
> If you connect to IXP's. Recommended ARP timeout: 4 hours.

Re: Passive Wave Primer

[Martijn Schmidt via NANOG]

I know there are some European carriers that offer this as a fully productized 
service, Colt and euNetworks come to mind.

Best regards,
Martijn

From: NANOG  on behalf of Tony 
Wicks 
Sent: 13 October 2020 21:35
To: 'Brandon Martin' 
Cc: nanog@nanog.org 
Subject: RE: Passive Wave Primer

We sell some wavelengths on passive CWDM/DWDM path's between Datacentres
(less than 80Km) to customers to spread the cost of leasing the dark fibre.
But yes, as far as long distance (apart from bespoke offerings) I'm yet to
see a productised alien wave service. If you are spending all that money on
OTN kit the extra cost of the transponders is not really significant I
suppose.

-Original Message-
From: NANOG  On Behalf Of Brandon
Martin
Sent: Wednesday, 14 October 2020 8:11 am
To: nanog@nanog.org
Subject: Re: Passive Wave Primer


I have yet to find a service provider that is actually willing to sell this
even when they have it in their service offering catalog.  The difficulties
of coordinating everything with the customer are so extreme that it seems to
usually make sense to either lease the customer dark fiber or capitalize the
transponders needed to carry it as a managed wave on the provider's
transport system.  Might make sense if you literally want half the spectrum
on a long-haul span or something.

RE: Passive Wave Primer

[Tony Wicks]

We sell some wavelengths on passive CWDM/DWDM path's between Datacentres
(less than 80Km) to customers to spread the cost of leasing the dark fibre.
But yes, as far as long distance (apart from bespoke offerings) I'm yet to
see a productised alien wave service. If you are spending all that money on
OTN kit the extra cost of the transponders is not really significant I
suppose.

-Original Message-
From: NANOG  On Behalf Of Brandon
Martin
Sent: Wednesday, 14 October 2020 8:11 am
To: nanog@nanog.org
Subject: Re: Passive Wave Primer


I have yet to find a service provider that is actually willing to sell this
even when they have it in their service offering catalog.  The difficulties
of coordinating everything with the customer are so extreme that it seems to
usually make sense to either lease the customer dark fiber or capitalize the
transponders needed to carry it as a managed wave on the provider's
transport system.  Might make sense if you literally want half the spectrum
on a long-haul span or something.

Re: Passive Wave Primer

[Brandon Martin]

On 10/13/20 8:27 AM, Rod Beck wrote:

Looking for a tutorial on passive waves. How it works. Pros and cons. .


If you're talking about what I think you are, the term the folks who 
make the transport gear seem to use is "spectrum" as in you (as service 
provider) sell your customer some portion of the WDM transport spectrum. 
 It typically comes in 50GHz increments or sometimes 100GHz 
corresponding to the standard ITU channel system but not always.


To the service provider, this is then an "alien wave" in that they have 
essentially no control or visibility into it other than light shows up, 
and they're responsible for getting it to the other end of the path with 
acceptable path characteristics.


I have yet to find a service provider that is actually willing to sell 
this even when they have it in their service offering catalog.  The 
difficulties of coordinating everything with the customer are so extreme 
that it seems to usually make sense to either lease the customer dark 
fiber or capitalize the transponders needed to carry it as a managed 
wave on the provider's transport system.  Might make sense if you 
literally want half the spectrum on a long-haul span or something.


--
Brandon Martin

Re: Virginia voter registration down due to cable cut

[Sean Donelan]

On Tue, 13 Oct 2020, Christopher Morrow wrote:

spof

the vita folk have a history of 'not really understanding large scale
compute/network operations' :(


Reportedly, the VITA data center and Virginia voter registration system is 
back up.


According to VITA, a Verizon fiber was struck during a roadside utilities 
construction project near Route 10 in Chester, VA.  As network engineers 
know, fiber cuts happen all the time due to construction.  Malicious cuts 
and sabatoge occur, but are rare and usually obvious. Absent clear and 
compelling evidence, assume normal stupid reasons for outages.



There are various long-term structural problems with election 
administration across 10,000+ jurisdictions in the United States.  A lot 
of duct-tape and heroic work needed by election administrators to keep 
things running.



Election administration in Australia, Norway and Luxembourg tend to score 
the best with 10 out of 10 according to international election observers.


Election administration in the United States of American tends to score 
around 7 or 8. There will be problems and delays. Not perfect, 
embarrassing and USA should do better. But still a full and free election.

RE: Passive Wave Primer

[Tony Wicks]

An Alien wave comes in from an external source, for an example a customer has 
WDM optics in their kit. A normal wave the “customer” connects with a normal 
10GE/100GE (or whatever is appropriate) and a line card on the OTN platform 
“grooms” that to the appropriate WDM channel.

 

From: NANOG  On Behalf Of TJ Trout
Sent: Wednesday, 14 October 2020 6:22 am
To: James Jun 
Cc: nanog 
Subject: Re: Passive Wave Primer

 

What is the difference between a normal wave and a alien wave?

 

Re: Passive Wave Primer

[TJ Trout]

What is the difference between a normal wave and a alien wave?

On Tue, Oct 13, 2020, 6:36 AM James Jun  wrote:

> On Tue, Oct 13, 2020 at 12:27:44PM +, Rod Beck wrote:
> > Dear Network Gurus,
> >
> > Looking for a tutorial on passive waves. How it works. Pros and cons. .
> >
>
> Essentially, you're providing a channel off of your DWDM filters for
> someone else to pass light.
>
> Commonly in the market, a "wavelength" product generally isn't a true
> wavelength, especially on long-haul segments.
> The 'wavelength' market really is an evolution of the old SONET market in
> some ways -- carriers will typically light a channel (either in fixed grid
> filter or flex grid) and that single channel is usually an X-gigabaud (e.g.
> 35-95Gbd) that uses coherent modulation on line side for say 200-800Gbps
> and multiplexing for tributary channels (such as TDM) on client side ports
> to break away a 100GE circuit for the customer end-user.
>
> As far as technicalities are concerned, most 'wavelength' products that
> behave as described above, ought to be called "dedicated circuits" or
> "circuit-switched transport" if we're anal about its operating principles.
>
> As for 'true' wavelength service, that brings us to your question:
>
> When you're talking about passive wave or 'alien wave', what you're doing
> is you're providing a wavelength frequency assignment on your photonic
> filter system (a channel on your 100 Ghz fixed grid DWDM filter, or
> bandwidth assignment window on your flex grid ROADM) to the customer, which
> would typically be another network provider, or a very clued enterprise
> customer that wants to run his own optical transport but can't justify the
> economics of full dark fiber over the said span, and doesn't need more than
> <=95Gbd max of modulation bandwidth.
>
> The customer would pass traffic similarly to how you yourself would light
> a channel, installing a coherent transponder for 200-800Gbps wave facing
> the line side, and breaking it out to Nx100GE for end-user traffic.
>
> James
>
>

Re: Virginia voter registration down due to cable cut

[Christopher Morrow]

spof

the vita folk have a history of 'not really understanding large scale
compute/network operations' :(

On Tue, Oct 13, 2020 at 11:06 AM Sean Donelan  wrote:
>
>
> On the last day of Virginia voter registration, the state-wide voter
> registration system experienced a cable cut disrupting access to the
> state-wide database system.
>
> Absent clear and convincing evidence otherwise, the problems will likely
> be caused by the usual stupid stuff.
>
>
>
> VITA
> @VITAagency
> A fiber cut near Rt. 10 in Chester near the Commonwealth Enterprise
> Solutions Center (CESC) is impacting data circuits and virtual private
> network (VPN) connectivity for multiple Commonwealth agencies.
>
>
> VITA
> @VITAagency
> Technicians are on site and working to repair the cut; updates will be
> provided as work progresses.

Virginia voter registration down due to cable cut

[Sean Donelan]

On the last day of Virginia voter registration, the state-wide voter 
registration system experienced a cable cut disrupting access to the

state-wide database system.

Absent clear and convincing evidence otherwise, the problems will likely 
be caused by the usual stupid stuff.




VITA
@VITAagency
A fiber cut near Rt. 10 in Chester near the Commonwealth Enterprise 
Solutions Center (CESC) is impacting data circuits and virtual private 
network (VPN) connectivity for multiple Commonwealth agencies.



VITA
@VITAagency
Technicians are on site and working to repair the cut; updates will be 
provided as work progresses.

Re: Passive Wave Primer

[James Jun]

On Tue, Oct 13, 2020 at 12:27:44PM +, Rod Beck wrote:
> Dear Network Gurus,
> 
> Looking for a tutorial on passive waves. How it works. Pros and cons. .
>

Essentially, you're providing a channel off of your DWDM filters for someone 
else to pass light.

Commonly in the market, a "wavelength" product generally isn't a true 
wavelength, especially on long-haul segments.
The 'wavelength' market really is an evolution of the old SONET market in some 
ways -- carriers will typically light a channel (either in fixed grid filter or 
flex grid) and that single channel is usually an X-gigabaud (e.g. 35-95Gbd) 
that uses coherent modulation on line side for say 200-800Gbps and multiplexing 
for tributary channels (such as TDM) on client side ports to break away a 100GE 
circuit for the customer end-user.

As far as technicalities are concerned, most 'wavelength' products that behave 
as described above, ought to be called "dedicated circuits" or 
"circuit-switched transport" if we're anal about its operating principles.

As for 'true' wavelength service, that brings us to your question:

When you're talking about passive wave or 'alien wave', what you're doing is 
you're providing a wavelength frequency assignment on your photonic filter 
system (a channel on your 100 Ghz fixed grid DWDM filter, or bandwidth 
assignment window on your flex grid ROADM) to the customer, which would 
typically be another network provider, or a very clued enterprise customer that 
wants to run his own optical transport but can't justify the economics of full 
dark fiber over the said span, and doesn't need more than <=95Gbd max of 
modulation bandwidth.

The customer would pass traffic similarly to how you yourself would light a 
channel, installing a coherent transponder for 200-800Gbps wave facing the line 
side, and breaking it out to Nx100GE for end-user traffic.

James 
 

Passive Wave Primer

[Rod Beck]

Dear Network Gurus,

Looking for a tutorial on passive waves. How it works. Pros and cons. .

Thanks.

Best,

Roderick.


Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com

New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183


[1467221477350_image005.png]