Re: US/Canada International border concerns for routing

[Eric Dugas]

Re: US/Canada International border concerns for routing

[Eric Kuhnke]

It is worth noting, however, that the former AllStream ASN (formerly AT
Canada) AS15290 is a completely different thing, and has distinct
infrastructure and routing from the AboveNet ASN which is operated by Zayo.
Although they are probably using "Free" Zayo transport by now.

If I am grossly wrong and anybody from layer 3 network operations at Zayo
wants to chime in and tell us about the 40,000 ft view of their plans to
combine AS15290 and AS6461, I am sure the community would be very
interested.

On Tue, Aug 8, 2017 at 5:31 PM, Stephen Fulton  wrote:

> TR,
>
> MTS Allstream is no longer a combined entity.  MTS was purchased by Bell
> Canada and Allstream was purchased by Zayo.
>
> -- Stephen
>
>
> On 2017-08-08 8:19 PM, TR Shaw wrote:
>
>> Bill,
>>
>> What does Bell buying MTS do? Does it change your statement or will the
>> MTS portion of Bell still peer locally?
>>
>> Tom
>>
>> On Aug 8, 2017, at 8:10 PM, Bill Woodcock  wrote:
>>>
>>>
>>> On Jul 20, 2017, at 7:01 AM, Hiers, David  wrote:
 For traffic routing, is anyone constraining cross-border routing
 between Canada and the US?  IOW, if you are routing from Toronto to
 Montreal, do you have to guarantee that the path cannot go through, say,
 Syracuse, New York?

>>>
>>> No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you
>>> _will_ go through Chicago, Seattle, New York, or Ashburn, since none of
>>> them peer anywhere in Canada at all.
>>>
>>> Last I checked (November of last year) the best-connected commercial
>>> networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS
>>> Allstream, Primus, and Zip Telecom, all of which peer at three or more
>>> Canadian IXes.  So, they’re capable of keeping traffic in Canada so long as
>>> the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to
>>> Canadians.
>>>
>>> In November, only 27% of intra-Canadian routes stayed within Canada; 64%
>>> went through the U.S.  That’s way worse than five years ago, when 60%
>>> stayed within Canada, and 38% went through the U.S.
>>>
>>> As has been pointed out, Canada has been building IXPs…  Just not as
>>> fast as the rest of the world has.  They’re behind the global average
>>> growth rate, and behind the U.S. growth rate, which is why the problem is
>>> getting worse.  Bandwidth costs are falling faster elsewhere, so they’re
>>> importing more foreign bandwidth.
>>>
>>> -Bill
>>>
>>>
>>>
>>>
>>>
>>

Re: US/Canada International border concerns for routing

[Bill Woodcock]

> On Aug 8, 2017, at 5:48 PM, Keenan Tims  wrote:
> While they do practice peering protectionism and only purchase transit out of 
> country, the situation is not *quite* so bad that all traffic round-trips 
> through the US.

No, not all, 64%.  By comparison, only 0.27% of intra-US traffic goes through 
Canada.

-Bill






signature.asc
Description: Message signed with OpenPGP

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Mike Hammett]

Ah, okay. I haven't used one yet. 

Also, I don't talk about beta outside of beta. ;-) 




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

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

- Original Message -

From: "Josh Reynolds"  
To: "Mike Hammett"  
Cc: "NANOG"  
Sent: Tuesday, August 8, 2017 8:07:36 PM 
Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? 


Forgot reply all... 


That does not apply to the infinity. Those shipped with 1.9.8dev. 





On Aug 8, 2017 8:03 PM, "Mike Hammett" < na...@ics-il.net > wrote: 


1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on May 
1st. 

https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161
 




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

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

- Original Message - 

From: "Nick W" < nickdwh...@gmail.com > 
To: nanog@nanog.org 
Sent: Thursday, July 20, 2017 10:55:28 PM 
Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? 

Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them 
all, sitting in my homelab for now. Multiple full tables, nothing fancy for 
firewall or QOS, but ran into issues with random ribd/bgpd crashes and 
kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would 
personally stay away from them until they are out of beta, and possibly 
even another 6-12 months after that. 

The current stable EdgeMax version (1.9.1.1) is relatively stable, but 
using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP) 
- nothing too major, but can be annoying. Probably okay for what you 
described. Depending on how much throughput you need, an ERPro, or Mikrotik 
would probably be fine. If you need 10G, load up VyOS on some cheap servers 
with an Intel or Solarflare card... probably cheaper than a beta Infinity 
or Mikrotik. 

On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders < j...@instituut.net > wrote: 

> Dear NANOG, 
> 
> Some friends of mine are operating a nonprofit (on shoe string) and looking 
> to connect some CDN caches to an IX fabric. A BGP speaking device is needed 
> between the caches and the BGP peers connected to the fabric. The BGP 
> speaker is needed to present the peers on the IX with a unified view of the 
> assemblage of CDN nodes. 
> 
> I was wondering whether anyone was experience with the "EdgeRouter Infinity 
> XG" device, specifically in the role of a simple peering router for a 
> couple of tens of thousands of routes. (I'd point default to the left and 
> take just the on-net routes on the right to reduce the table size 
> requirement). 
> 
> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is 
> automatable (supports idempotency), can forward IMIX at line-rate, *flow, 
> and exposes some telemetry via SNMP. 
> 
> Any note sharing would be appreciated! 
> 
> Kind regards, 
> 
> Job 
> 

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Josh Reynolds]

Forgot reply all...

That does not apply to the infinity. Those shipped with 1.9.8dev.


On Aug 8, 2017 8:03 PM, "Mike Hammett"  wrote:

> 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on
> May 1st.
>
> https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-
> EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Nick W" 
> To: nanog@nanog.org
> Sent: Thursday, July 20, 2017 10:55:28 PM
> Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?
>
> Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them
> all, sitting in my homelab for now. Multiple full tables, nothing fancy for
> firewall or QOS, but ran into issues with random ribd/bgpd crashes and
> kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would
> personally stay away from them until they are out of beta, and possibly
> even another 6-12 months after that.
>
> The current stable EdgeMax version (1.9.1.1) is relatively stable, but
> using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP)
> - nothing too major, but can be annoying. Probably okay for what you
> described. Depending on how much throughput you need, an ERPro, or Mikrotik
> would probably be fine. If you need 10G, load up VyOS on some cheap servers
> with an Intel or Solarflare card... probably cheaper than a beta Infinity
> or Mikrotik.
>
> On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders  wrote:
>
> > Dear NANOG,
> >
> > Some friends of mine are operating a nonprofit (on shoe string) and
> looking
> > to connect some CDN caches to an IX fabric. A BGP speaking device is
> needed
> > between the caches and the BGP peers connected to the fabric. The BGP
> > speaker is needed to present the peers on the IX with a unified view of
> the
> > assemblage of CDN nodes.
> >
> > I was wondering whether anyone was experience with the "EdgeRouter
> Infinity
> > XG" device, specifically in the role of a simple peering router for a
> > couple of tens of thousands of routes. (I'd point default to the left and
> > take just the on-net routes on the right to reduce the table size
> > requirement).
> >
> > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
> > automatable (supports idempotency), can forward IMIX at line-rate, *flow,
> > and exposes some telemetry via SNMP.
> >
> > Any note sharing would be appreciated!
> >
> > Kind regards,
> >
> > Job
> >
>
>

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Mike Hammett]

1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on May 
1st. 

https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161
 




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

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

- Original Message -

From: "Nick W"  
To: nanog@nanog.org 
Sent: Thursday, July 20, 2017 10:55:28 PM 
Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? 

Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them 
all, sitting in my homelab for now. Multiple full tables, nothing fancy for 
firewall or QOS, but ran into issues with random ribd/bgpd crashes and 
kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would 
personally stay away from them until they are out of beta, and possibly 
even another 6-12 months after that. 

The current stable EdgeMax version (1.9.1.1) is relatively stable, but 
using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP) 
- nothing too major, but can be annoying. Probably okay for what you 
described. Depending on how much throughput you need, an ERPro, or Mikrotik 
would probably be fine. If you need 10G, load up VyOS on some cheap servers 
with an Intel or Solarflare card... probably cheaper than a beta Infinity 
or Mikrotik. 

On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders  wrote: 

> Dear NANOG, 
> 
> Some friends of mine are operating a nonprofit (on shoe string) and looking 
> to connect some CDN caches to an IX fabric. A BGP speaking device is needed 
> between the caches and the BGP peers connected to the fabric. The BGP 
> speaker is needed to present the peers on the IX with a unified view of the 
> assemblage of CDN nodes. 
> 
> I was wondering whether anyone was experience with the "EdgeRouter Infinity 
> XG" device, specifically in the role of a simple peering router for a 
> couple of tens of thousands of routes. (I'd point default to the left and 
> take just the on-net routes on the right to reduce the table size 
> requirement). 
> 
> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is 
> automatable (supports idempotency), can forward IMIX at line-rate, *flow, 
> and exposes some telemetry via SNMP. 
> 
> Any note sharing would be appreciated! 
> 
> Kind regards, 
> 
> Job 
> 

Re: US/Canada International border concerns for routing

[Clayton Zekelman]

OK, Maybe I was a bit overly dramatic.  One of the big 3 peered with 
us in a US location, but refused to peer in Canada.


I can't recall if we actually did specifically ask Rogers at one 
point or not.  I know we haven't asked recently.



At 08:41 PM 08/08/2017, Bill Woodcock wrote:


> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman  wrote:
>
>
>
> With the peering policies of the major Canadian ISPs, you're 
virtually guaranteed to hairpin through the US on most paths.

>
> Robellus (Rogers, Bell & Telus) will peer with you at any of 
their major Canadian peering points, such as NYC, Chicago or LA.


To be fair, Rogers does peer in Toronto.  Along with New York, 
Chicago, Seattle, and Ashburn.


-Bill







--

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Re: US/Canada International border concerns for routing

[Dave Cohen]

It seems to me the original question was asking about it more from a legal 
perspective, in other words does Canadian traffic have to stay in Canada. IANAL 
(or a Canadian), but the answer is "mostly, no, especially as related to 
publicly routed traffic" as should be evidenced based on what's already been 
discussed here. In other words, there is restricted traffic but unless you're 
making a play for MAN/WAN type service on owned infrastructure, those 
requirements are unlikely to arise. 

To support the macro point, there is some big-boy level peering in Toronto but 
not really much else outside that, but there are plenty of routes that don't 
cross the border if you don't have to jump networks to your destination, for 
example going to an AWS on ramp in Canada using a native partner network, 
especially in the Toronto-Ottawa-Montreal. 

Dave Cohen
craetd...@gmail.com

> On Aug 8, 2017, at 8:41 PM, Bill Woodcock  wrote:
> 
> 
> --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
>charset=us-ascii
> 
> 
>> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman  wrote:
>> =20
>> =20
>> =20
>> With the peering policies of the major Canadian ISPs, you're virtually =
> guaranteed to hairpin through the US on most paths.
>> =20
>> Robellus (Rogers, Bell & Telus) will peer with you at any of their =
> major Canadian peering points, such as NYC, Chicago or LA.
> 
> To be fair, Rogers does peer in Toronto.  Along with New York, Chicago, =
> Seattle, and Ashburn.
> 
>-Bill
> 
> 
> 
> 
> 
> --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
>filename=signature.asc
> Content-Type: application/pgp-signature;
>name=signature.asc
> Content-Description: Message signed with OpenPGP
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE
> TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/
> crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD
> 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r
> 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL
> v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ
> ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6
> tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA
> Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf
> ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY
> RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW
> btKUtEvrcU28g15nOhLG
> =MTUG
> -END PGP SIGNATURE-
> 
> --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E--
> 

Re: US/Canada International border concerns for routing

[Keenan Tims]

On 2017-08-08 17:10, Bill Woodcock wrote:

No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you_will_  go 
through Chicago, Seattle, New York, or Ashburn, since none of them peer 
anywhere in Canada at all.


The major national networks (Bell, Rogers, Telus, Shaw, Zayo/Allstream) 
do peer with each other and some other large / old Canadian networks 
(e.g. MTS, SaskTel, Peer1) within Canada. While they do practice peering 
protectionism and only purchase transit out of country, the situation is 
not *quite* so bad that all traffic round-trips through the US.


Of course if neither side of the conversation has at least one of those 
major networks as a transit upstream - which is most of the eyeballs and 
most of the important Canadian content - you'll see that hop through 
Chicago or Seattle (or worse). Which is exactly the way they like it.


Keenan

Re: US/Canada International border concerns for routing

[Bill Woodcock]

> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman  wrote:
> 
> 
> 
> With the peering policies of the major Canadian ISPs, you're virtually 
> guaranteed to hairpin through the US on most paths.
> 
> Robellus (Rogers, Bell & Telus) will peer with you at any of their major 
> Canadian peering points, such as NYC, Chicago or LA.

To be fair, Rogers does peer in Toronto.  Along with New York, Chicago, 
Seattle, and Ashburn.

-Bill






signature.asc
Description: Message signed with OpenPGP

Re: US/Canada International border concerns for routing

[Clayton Zekelman]

With the peering policies of the major Canadian ISPs, you're 
virtually guaranteed to hairpin through the US on most paths.


Robellus (Rogers, Bell & Telus) will peer with you at any of their 
major Canadian peering points, such as NYC, Chicago or LA.




At 10:01 AM 20/07/2017, Hiers, David wrote:

Hi,
We're looking to extend some services into Canada.  While our 
lawyers dig into it, I thought that I'd ask the hive mind about 
border restrictions.


For traffic routing, is anyone constraining cross-border routing 
between Canada and the US?  IOW, if you are routing from Toronto to 
Montreal, do you have to guarantee that the path cannot go through, 
say, Syracuse, New York?


I'm asking network operators about packet routing; data storage is a 
very different matter, of course.


Thanks,

David

--
This message and any attachments are intended only for the use of 
the addressee and may contain information that is privileged and 
confidential. If the reader of the message is not the intended 
recipient or an authorized representative of the intended recipient, 
you are hereby notified that any dissemination of this communication 
is strictly prohibited. If you have received this communication in 
error, notify the sender immediately by return email and delete the 
message and any attachments from your system.


--

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Re: US/Canada International border concerns for routing

[Stephen Fulton]

TR,

MTS Allstream is no longer a combined entity.  MTS was purchased by Bell 
Canada and Allstream was purchased by Zayo.


-- Stephen

On 2017-08-08 8:19 PM, TR Shaw wrote:

Bill,

What does Bell buying MTS do? Does it change your statement or will the MTS 
portion of Bell still peer locally?

Tom


On Aug 8, 2017, at 8:10 PM, Bill Woodcock  wrote:



On Jul 20, 2017, at 7:01 AM, Hiers, David  wrote:
For traffic routing, is anyone constraining cross-border routing between Canada 
and the US?  IOW, if you are routing from Toronto to Montreal, do you have to 
guarantee that the path cannot go through, say, Syracuse, New York?


No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you _will_ go 
through Chicago, Seattle, New York, or Ashburn, since none of them peer 
anywhere in Canada at all.

Last I checked (November of last year) the best-connected commercial networks 
(i.e. not CANARIE) in Canada were Hurricane Electric, MTS Allstream, Primus, 
and Zip Telecom, all of which peer at three or more Canadian IXes.  So, they’re 
capable of keeping traffic in Canada so long as the other end isn’t on Bell or 
Telus, which only sell U.S. bandwidth to Canadians.

In November, only 27% of intra-Canadian routes stayed within Canada; 64% went 
through the U.S.  That’s way worse than five years ago, when 60% stayed within 
Canada, and 38% went through the U.S.

As has been pointed out, Canada has been building IXPs…  Just not as fast as 
the rest of the world has.  They’re behind the global average growth rate, and 
behind the U.S. growth rate, which is why the problem is getting worse.  
Bandwidth costs are falling faster elsewhere, so they’re importing more foreign 
bandwidth.

-Bill

Re: US/Canada International border concerns for routing

[Bill Woodcock]

> On Aug 8, 2017, at 5:19 PM, TR Shaw  wrote:
> 
> Bill,
> 
> What does Bell buying MTS do? Does it change your statement or will the MTS 
> portion of Bell still peer locally?

I’d have to go back and look at the actual ASNs in our analysis.  I think what 
we called “MTS Allstream” in the chart is actually the Zayo-owned Allstream, 
not the Bell-owned Bell MTS.

-Bill






signature.asc
Description: Message signed with OpenPGP

Re: Admiral Hosting in London

[Mike Hammett]

I've heard of some people that don't have the capital to purchase their own 
block yet, but want PI space so they can move away from whomever is providing 
their transit + IP space now. I'm sure the discussed reason is much more 
prevalent, though. 




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

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

- Original Message -

From: "Chris Woodfield"  
To: "Randy Bush" , "Michael Wayne"  
Cc: "NANOG list"  
Sent: Monday, July 31, 2017 11:31:47 AM 
Subject: Re: Admiral Hosting in London 

And I’d *love* to hear the story they come up with when you ask why they only 
want to rent space vs buy it… 

-C 

> On Jul 27, 2017, at 9:22 PM, Randy Bush  wrote: 
> 
>> We were contacted by Admiral Hosting in London to rent some our 
>> unused IP space. 
> 
> anyone wanting to rent/lease space is 99% sure to be not nice folk. 
> if you get your space back, it will be radioactive with an amazingly 
> long half life. 
> 
> if you are willing to let go of the space, just tell them the price 
> for which you are willing to sell it. 
> 
> randy 
> 

Re: US/Canada International border concerns for routing

[TR Shaw]

Bill,

What does Bell buying MTS do? Does it change your statement or will the MTS 
portion of Bell still peer locally?

Tom

> On Aug 8, 2017, at 8:10 PM, Bill Woodcock  wrote:
> 
> 
>> On Jul 20, 2017, at 7:01 AM, Hiers, David  wrote:
>> For traffic routing, is anyone constraining cross-border routing between 
>> Canada and the US?  IOW, if you are routing from Toronto to Montreal, do you 
>> have to guarantee that the path cannot go through, say, Syracuse, New York?
> 
> No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you _will_ 
> go through Chicago, Seattle, New York, or Ashburn, since none of them peer 
> anywhere in Canada at all.
> 
> Last I checked (November of last year) the best-connected commercial networks 
> (i.e. not CANARIE) in Canada were Hurricane Electric, MTS Allstream, Primus, 
> and Zip Telecom, all of which peer at three or more Canadian IXes.  So, 
> they’re capable of keeping traffic in Canada so long as the other end isn’t 
> on Bell or Telus, which only sell U.S. bandwidth to Canadians.
> 
> In November, only 27% of intra-Canadian routes stayed within Canada; 64% went 
> through the U.S.  That’s way worse than five years ago, when 60% stayed 
> within Canada, and 38% went through the U.S.
> 
> As has been pointed out, Canada has been building IXPs…  Just not as fast as 
> the rest of the world has.  They’re behind the global average growth rate, 
> and behind the U.S. growth rate, which is why the problem is getting worse.  
> Bandwidth costs are falling faster elsewhere, so they’re importing more 
> foreign bandwidth.
> 
>-Bill
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: US/Canada International border concerns for routing

[Bill Woodcock]

> On Jul 20, 2017, at 7:01 AM, Hiers, David  wrote:
> For traffic routing, is anyone constraining cross-border routing between 
> Canada and the US?  IOW, if you are routing from Toronto to Montreal, do you 
> have to guarantee that the path cannot go through, say, Syracuse, New York?

No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you _will_ go 
through Chicago, Seattle, New York, or Ashburn, since none of them peer 
anywhere in Canada at all.

Last I checked (November of last year) the best-connected commercial networks 
(i.e. not CANARIE) in Canada were Hurricane Electric, MTS Allstream, Primus, 
and Zip Telecom, all of which peer at three or more Canadian IXes.  So, they’re 
capable of keeping traffic in Canada so long as the other end isn’t on Bell or 
Telus, which only sell U.S. bandwidth to Canadians.

In November, only 27% of intra-Canadian routes stayed within Canada; 64% went 
through the U.S.  That’s way worse than five years ago, when 60% stayed within 
Canada, and 38% went through the U.S.

As has been pointed out, Canada has been building IXPs…  Just not as fast as 
the rest of the world has.  They’re behind the global average growth rate, and 
behind the U.S. growth rate, which is why the problem is getting worse.  
Bandwidth costs are falling faster elsewhere, so they’re importing more foreign 
bandwidth.

-Bill






signature.asc
Description: Message signed with OpenPGP

Re: US/Canada International border concerns for routing

[Constantine A. Murenin]

On 20/07/2017, Hiers, David  wrote:
> Hi,
> We're looking to extend some services into Canada.  While our lawyers dig
> into it, I thought that I'd ask the hive mind about border restrictions.
>
> For traffic routing, is anyone constraining cross-border routing between
> Canada and the US?  IOW, if you are routing from Toronto to Montreal, do you
> have to guarantee that the path cannot go through, say, Syracuse, New York?

Guarantee to whom?

Back a few years ago when I looked into it, most of the traffic within
Canada went through the US, e.g., since Bell didn't want to peer with
anyone in Canada, you'd go something like YYZ - ORD - YYZ, clearly
visible through the traceroute.

Possibly somewhat better nowadays — there's been quite a few new IX
POPs that popped up — but I doubt the scenario is a thing of the past.

P.S.  Just for the giggles — checked http://lg.he.net/ routing from
core1.tor1.he.net to www.bell.ca — still goes through Chicago, to
Montreal, from Toronto. :-)  Going straight to Montreal,
core1.ymq1.he.net, will route you to www.bell.ca (still in Montreal)
through the peering at NYC.

P.P.S.  In other words — if someone wants guarantees, they better
explicitly ask you for it.

Cheers,
Constantine.
http://cm.su/

Re: Spoofer Project

[Matthew Luckie]

To my knowledge this is the meeting network.

https://spoofer.caida.org/recent_tests.php?as_include=19230

Your interpretation of the results is congruent with mine.  If you look
through the history of tests you can see SAV is usually deployed on the
network during the meeting.

This is true of other network operator group meeting networks as well.

On 08/09/17 11:25, Info | ddostest.me wrote:
> Is it me or NANOG's AS allowing spoofing?
> 
> https://spoofer.caida.org/as.php?asn=19230



signature.asc
Description: OpenPGP digital signature

Re: Cisco Nexus 93180YC Switch Feedback

[Brandon Butterworth]

On Tue Jul 25, 2017 at 08:31:54PM -0700, Tim Stevenson wrote:
> Actually, only two.
> 
> tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed
> Ethernet1/49
>   Speed: 4
> Ethernet1/50
>   Speed: 1000,1,25000,4,5,10
> Ethernet1/51
>   Speed: 4
> Ethernet1/52
>   Speed: 1000,1,25000,4,5,10
> Ethernet1/53
>   Speed: 4
> Ethernet1/54
>   Speed: 4
> tstevens-92160yc-1#

same box, cisco Nexus9000 C92160YC-X

is2.ed# sh int cap | beg 1/49 | eg Eth|Speed
Ethernet1/49
  Speed: 4,10
Ethernet1/50
  Speed: 1000,1,25000,4,5,10
Ethernet1/51
  Speed: 1000,1,25000,4,5,10
Ethernet1/52
  Speed: 1000,1,25000,4,5,10

You have to tell it you want more 100G with fewer ports
hardware profile portmode 48x25G+4x100G

brandon

Re: Cisco Nexus 93180YC Switch Feedback

[Simon Lockhart]

On Tue Jul 25, 2017 at 08:31:54PM -0700, Tim Stevenson wrote:
> tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed
> Ethernet1/49 >   Speed: 4
> Ethernet1/50 >   Speed: 1000,1,25000,4,5,10
> Ethernet1/51 >   Speed: 4
> Ethernet1/52 >   Speed: 1000,1,25000,4,5,10
> Ethernet1/53 >   Speed: 4
> Ethernet1/54 >   Speed: 4

Are you sure?

xsw-01.ixn# show ver | incl Nexus9
  cisco Nexus9000 C92160YC-X chassis 

xsw-01.ixn# sh int cap | beg 1/49 | eg Eth|Speed
Ethernet1/49
  Speed: 4,10
Ethernet1/50
  Speed: 1000,1,25000,4,5,10
Ethernet1/51
  Speed: 1000,1,25000,4,5,10
Ethernet1/52
  Speed: 1000,1,25000,4,5,10

xsw-01.ixn# show run | incl portmode
hardware profile portmode 48x25G+4x100G

xsw-01.ixn(config)# hardware profile portmode ?
  48x25g+2x100g+4x40g  48x25G+2x100G+4x40G port mode
  48x25g+4x100g48x25G+4x100G port mode

You can configure how the ports present themselves...

Simon

cable modem provisioning servers

[Dan Spencer]

All,

I am at a point where I need to update our servers that provision our customer 
cable modems.  I would like to see what other options are out there that people 
like.

If anyone in the community has any recommendations it would be appreciated.

Thank you,

Dan

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived.

Looking for a AT MIS engineer to help with a Circuit

[Jason Wilson]

Message off list please


Jason Wilson
Remotely Located
Providing High Speed Internet to out of the way places.
530-651-1736
530-748-9608 Cell
www.remotelylocated.com

US/Canada International border concerns for routing

[Hiers, David]

Hi,
We're looking to extend some services into Canada.  While our lawyers dig into 
it, I thought that I'd ask the hive mind about border restrictions.

For traffic routing, is anyone constraining cross-border routing between Canada 
and the US?  IOW, if you are routing from Toronto to Montreal, do you have to 
guarantee that the path cannot go through, say, Syracuse, New York?

I'm asking network operators about packet routing; data storage is a very 
different matter, of course.

Thanks,

David

--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.

RE: Transparent Waves

[Jameson, Daniel]

They're probably looking for a G.709 spec service.  You still need to know 
something about their traffic,  is it analog RFOG,  or something already framed 
like SONET or 1/10/100G.  If they can hand you a connection with G.709 styled 
framing  most modern transport gear can ship it end-to-end,  even over ROADM.
https://en.wikipedia.org/wiki/G.709
https://www.itu.int/rec/T-REC-G.709-201611-I!Amd1/en
https://www.itu.int/rec/dologin_pub.asp?lang=e=T-REC-G.709-201611-I!Amd1!PDF-E=items





-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Bryan Holloway
Sent: Saturday, August 05, 2017 9:22 AM
To: Rod Beck; nanog@nanog.org
Subject: Re: Transparent Waves

Are you referring to GFP?

I think G.7041 is what you want. The "transparent" flavor.

https://www.itu.int/rec/dologin_pub.asp?lang=e=T-REC-G.7041-201608-I!!PDF-E=items


On 8/4/17 12:34 PM, Rod Beck wrote:
> Can someone refer me to the ITU SPEC on transparent 10 gig wave service. I 
> have a client is looking to lease two 10 gig waves but they do not want an 
> Ethernet format. Just transparent. I want to make sure the carrier gets it 
> right when they configure the service.
> 
> 
> Regards,
> 
> 
> Roderick.
> 
> 
> Roderick Beck
> 
> Director of Global Sales
> 
> United Cable Company
> 
> DRG Undersea Consulting
> 
> Affiliate Member
> 
> www.unitedcablecompany.com
> 
> 85 Király utca, 1077 Budapest
> 
> rod.b...@unitedcablecompany.com
> 
> 36-30-859-5144
> 
> 
> [1467221477350_image005.png]
> 

Re: Bell outage

[John Cavanaugh]

No a single fiber bundle cut doesn’t cause this level of outage.

I am at a family reunion in Nova Scotia and – Bell internet is down, all cell 
services are down, most land lines are down and 911 services are problematic.  
A lot of flights in Halifax have been cancelled (impacting our reunion).  
Downdetector.com shows a lot, but do not see any details on outages.  

Looks more like a Cyber incident.  At the moment cable service at the cottage 
is still up….  Was in town and all the banks were closed except RBC.  Only one 
gas station on the highway was operational.

Thanks,
 
John Cavanaugh

On 8/4/17, 2:07 PM, "NANOG on behalf of jim deleskie" 
 wrote:

Single fiber cut causes the much impact?

-jim

On Fri, Aug 4, 2017 at 2:59 PM, J  wrote:

> https://www.theglobeandmail.com/news/national/much-of-
> atlantic-canada-loses-cellphone-service-in-widespread-outage/
> article35881182/
>
>
>
> Apparently some fiber cut.  No word on the exact model of construction
> equipment, yet, though.
>
>
>
> :\
>
>
>
>
>  On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah 
ks...@primustel.ca
> wrote 
>
>
>
>
> Does anyone know what is happening with Bell network at East Canada?
>
>
>
> http://canadianoutages.com/status/bell/map/
>
>
>
>
>
> Krunal
>
> 
>
>
>
>  This electronic message contains information from Primus Management ULC
> ("PRIMUS") , which may be legally privileged and confidential. The
> information is intended to be for the use of the individual(s) or entity
> named above. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you have received this electronic message in
> error, please notify us by telephone or e-mail (to the number or address
> above) immediately. Any views, opinions or advice expressed in this
> electronic message are not necessarily the views, opinions or advice of
> PRIMUS. It is the responsibility of the recipient to ensure that any
> attachments are virus free and PRIMUS bears no responsibility for any loss
> or damage arising in any way from the use thereof.The term "PRIMUS"
> includes its affiliates.
>
>
>
> 
>
>  Pour la version en français de ce message, veuillez voir
>
> http://www.primustel.ca/fr/legal/cs.htm
>
>
>
>
>
>
>

Re: Admiral Hosting in London

[Chris Woodfield]

And I’d *love* to hear the story they come up with when you ask why they only 
want to rent space vs buy it…

-C

> On Jul 27, 2017, at 9:22 PM, Randy Bush  wrote:
> 
>> We were contacted by Admiral Hosting in London to rent some our
>> unused IP space.
> 
> anyone wanting to rent/lease space is 99% sure to be not nice folk.
> if you get your space back, it will be radioactive with an amazingly
> long half life.
> 
> if you are willing to let go of the space, just tell them the price
> for which you are willing to sell it.
> 
> randy
> 

Re: Leaked routes earlier

[Wilson Chu]

It was AS12389 who leaked for few minutes.
>From my view, AS7922, 16059, 4134, 6805, 13649, 29562, 31334, 9116 were all
affected.

For example 50.18.174.0/18 from AWS AS16509, right before:

[image: Inline image 1]

Duration:

[image: Inline image 2]

After:

[image: Inline image 3]

--Wilson


On Tue, Jul 25, 2017 at 3:44 PM, Wilson Chu  wrote:

> For about two minutes from Tue Jul 25 21:09:42 2017 GMT to 21:11:30 2017,
> routes to AWS were routed to stream-internet.net and got blackholed.
>
> for example, route to 50.18.x.x at the time:
>
> 
>   5. sd-cr01-te3-4.161.nyc.stream  0.0% 3  350.9 249.9 173.9 350.9
>  91.2
>   6. anc-cr03-xe-5-0-1.149.ff.str 33.3% 3  174.7 195.8 174.7 216.8
>  29.8
>   7. radio-cr01-ae4.135.hel.strea 33.3% 3  213.4 213.6 213.4 213.7
> 0.2
>   8. mmon-cr01-be3.78.spb.stream- 66.7% 3  204.6 204.6 204.6 204.6
> 0.0
>   9. a433-cr01-be1.78.msk.stream- 33.3% 3  214.4 212.9 211.5 214.4
> 2.1
>  10. m9-cr05-ae9.77.msk.stream-in 66.7% 3  213.6 213.6 213.6 213.6
> 0.0
>  11. m9-cr03-ae1.199.msk.stream-i 33.3% 3  197.5 206.4 197.5 215.3
>  12.6
>  12. s-bb3-link.telia.net 66.7% 3  206.8 206.8 206.8 206.8
> 0.0
>  13. kbn-bb3-link.telia.net   66.7% 3  214.9 214.9 214.9 214.9
> 0.0
>  14. 54.240.242.130   66.7% 3  614.2 614.2 614.2 614.2
> 0.0
>  15. 54.240.242.147   66.7% 3  204.4 204.4 204.4 204.4
> 0.0
>  16. m9-cr05-ae3.77.msk.stream-in 66.7% 3  262.0 262.0 262.0 262.0
> 0.0
>  17. 54.240.242.132   66.7% 3  606.2 606.2 606.2 606.2
> 0.0
>  18. 54.240.242.147   33.3% 3  205.5 203.6 201.6 205.5
> 2.7
>  19. 205.251.229.158  66.7% 3  200.8 200.8 200.8 200.8
> 0.0
>  20. ???  100.0 30.0   0.0   0.0   0.0
> 0.0
>  21. ???  100.0 20.0   0.0   0.0   0.0
> 0.0
>  22. ???  100.0 20.0   0.0   0.0   0.0
> 0.0
>  23. ???  100.0 20.0   0.0   0.0   0.0
> 0.0
>
> Anyone saw the same issue?
>
> Thanks,
>
> --Wilson
>

Leaked routes earlier

[Wilson Chu]

For about two minutes from Tue Jul 25 21:09:42 2017 GMT to 21:11:30 2017,
routes to AWS were routed to stream-internet.net and got blackholed.

for example, route to 50.18.x.x at the time:


  5. sd-cr01-te3-4.161.nyc.stream  0.0% 3  350.9 249.9 173.9 350.9  91.2
  6. anc-cr03-xe-5-0-1.149.ff.str 33.3% 3  174.7 195.8 174.7 216.8  29.8
  7. radio-cr01-ae4.135.hel.strea 33.3% 3  213.4 213.6 213.4 213.7   0.2
  8. mmon-cr01-be3.78.spb.stream- 66.7% 3  204.6 204.6 204.6 204.6   0.0
  9. a433-cr01-be1.78.msk.stream- 33.3% 3  214.4 212.9 211.5 214.4   2.1
 10. m9-cr05-ae9.77.msk.stream-in 66.7% 3  213.6 213.6 213.6 213.6   0.0
 11. m9-cr03-ae1.199.msk.stream-i 33.3% 3  197.5 206.4 197.5 215.3  12.6
 12. s-bb3-link.telia.net 66.7% 3  206.8 206.8 206.8 206.8   0.0
 13. kbn-bb3-link.telia.net   66.7% 3  214.9 214.9 214.9 214.9   0.0
 14. 54.240.242.130   66.7% 3  614.2 614.2 614.2 614.2   0.0
 15. 54.240.242.147   66.7% 3  204.4 204.4 204.4 204.4   0.0
 16. m9-cr05-ae3.77.msk.stream-in 66.7% 3  262.0 262.0 262.0 262.0   0.0
 17. 54.240.242.132   66.7% 3  606.2 606.2 606.2 606.2   0.0
 18. 54.240.242.147   33.3% 3  205.5 203.6 201.6 205.5   2.7
 19. 205.251.229.158  66.7% 3  200.8 200.8 200.8 200.8   0.0
 20. ???  100.0 30.0   0.0   0.0   0.0   0.0
 21. ???  100.0 20.0   0.0   0.0   0.0   0.0
 22. ???  100.0 20.0   0.0   0.0   0.0   0.0
 23. ???  100.0 20.0   0.0   0.0   0.0   0.0

Anyone saw the same issue?

Thanks,

--Wilson

Re: VXLAN for WAN Pseudowires?

[Ignas Bagdonas]

Hi there,


However,
this would mean a shift from VPLS to VXLAN.
On this particular sentence - it is incorrect to compare VPLS and VXLAN. 
One is a set of control plane mechanisms for discovery and tunnel setup 
and data plane encapsulations and multipoint reachability model, while 
the other is just a data plane encapsulation. VXLAN is equivalent to a 
(point to point) pseudowire used as a data plane component in VPLS.




2) Traffic engineering - we don't have a lot of requirement for this, but do
have a small number of customers who buy A and B circuits, and require them
to be routed across different paths on our network. This is easy with MPLS
using explicit LSPs, but we've not yet worked out how to achieve the same
thing in VXLAN.
VXLAN is a tunnel over a routed IP network. The path to reach the tunnel 
endpoint will define how VXLAN encapsulated payload is traversing over 
your network. If tunnel endpoint is reachable via explicitly routed LSP, 
the payload will follow that path. VXLAN by itself does nothing to 
influence the underlay path.



So, my question to the community is - have any of you used VXLAN as a wide-area
layer 2 transport technology?
Yes, there are such deployments. The number of such deployments is 
increasing.



Any pros or cons? Gotchas? Scare stories?
Recommendations? Am I trying to shoot myself in the foot?


VXLAN is a tunnelling mechanism. You seem to be looking for a end to end 
solution, for which VXLAN is a (rather small) component. You need to 
start from the requirements. What is the underlay technology being used? 
How much of traffic engineering functionality will be required, and how 
the particular underlay technology can implement it? What about ECMP 
support and requirements for its use - flow mapping to VXLAN tunnel is 
the same problem as flow mapping to any other tunnel in underlay ECMP 
environment. To build all of this is one thing, but to operate is quite 
the other - what about OAM requirements? VXLAN has no OAM support, and 
will not get one. If your operations systems rely on MPLS based OAM for 
service layer (eg, an MPLS based PW) - that will not be available. How 
the tunnels will be set up - is there a need to do discovery, or will 
all of it be orchestrated?


Two main limiting factors in VXLAN applicability are lack of payload 
type indicator - the tunnel can carry only a single type of payload 
(ethernet in the canonic definition, no possibility to use single tunnel 
for multiple user payload types without additional encapsulation), and 
no ability to indicate that the payload is not a user payload but some 
other special type like OAM (pseudowire control word would be an example 
of such indicator). This leaves VXLAN as a solution of limited 
applicability for anything else than original intended one - ethernet 
tunnel over IP underlay. For other uses VXLAN is of limited 
applicability, there may be (and in fact are) vendor specific extensions 
but there is no point in talking about interoperability then. This 
problem space is well understood and there are successors to VXLAN - 
Geneve is getting into good shape (there are vendor specific early 
implementations but it is too early to talk about interoperability at 
this time), plus different vendors have their own tunnel encapsulation 
mechanisms (VXLAN-GPE being a more visible one, however it is not going 
to be standardized soon).


The other interesting part to solve is the control plane. BGP based one 
will likely be the most practical option here. Combined with ability to 
tunnel multiple payload types this gives you a single control plane for 
L3VPN and point to point and multipoint L2VPN built on the same underlay 
with the single tunnelling mechanism. Your operations team will thank 
you violently for doing this.


Ignas

Re: Temperature monitoring

[J. Hellenthal]

Would be pretty great if mobile worked... 



-- 
 Onward!, 
 Jason Hellenthal, 
 Systems & Network Admin, 
 Mobile: 0x9CA0BD58, 
 JJH48-ARIN

On Jul 18, 2017, at 15:39, Edwin Pers  wrote:

+1 for the serverscheck.com gear. Been running it as a humidity monitor in the 
plant for a year or so now and it's been rock solid. If you're the kind of shop 
that requires calibration for that sort of equipment they'll handle that as 
well. Great company to work with. Pair it with Cacti + thold plugin or whatever 
other snmp monitoring you like - or the base units can handle alerting on their 
own.

FYI for those interested - the stated max length of connecting cable between 
the base station and the sensor units (30ft iirc) is way under what it'll do in 
the real world - I've got at least one sensor unit that's a good 500ft away 
from the base station and it's been working just fine

Ed Pers

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of David Charlebois
Sent: Sunday, July 16, 2017 10:02 PM
To: NANOG 
Subject: Re: Temperature monitoring

we use: https://serverscheck.com/sensors/ - simple setup, graph nicely in 
Cacti. I went with ServerCheck wired based units + external temp+humidity 
probe. The base unit displays the temperature which is a nice quick reference 
if you are in the room.

> On Fri, Jul 14, 2017 at 8:31 AM, Dan White  wrote:
> 
> We use Asentria.
> 
>> On 07/13/17 22:33 -0400, Dovid Bender wrote:
>> 
>> All,
>> 
>> We had an issue with a DC where temps were elevated. The one bit of 
>> hardware that wasn't watched much was the one that sent out the 
>> initial alert. Looking for recommendations on hardware that I can 
>> mount/hang in each cabinet that is easy to set up and will alert us 
>> if temps go beyond a certain point.
>> 
> 
> --
> Dan White
> BTC Broadband
> Network Admin Lead
> Ph  918.366.0248 (direct)   main: (918)366-8000
> Fax 918.366.6610email: dwh...@olp.net
> http://www.btcbroadband.com
> 

Re: ISP billing - data collection, correlation, and billing

[Michael Krygeris]

On Sat, Jul 15, 2017 at 4:48 AM Lee Howard  wrote:

>
> Depending on the capability of the exporter, you don't need to export full
flow information. With Cisco's Flexible Netflow you can define the
aggregation in the flow cache you are monitoring. You are not required to
use a 7-tuple.
An aggregation could be something basic like this:
Source interface
Destination interface
Octets
Packets

This would give you SNMP equivalent for byte accounting on interfaces
without requiring full flow accounting IF you're not forced to do sampling
and IF you have flexible netflow.

Another much more recent method around SNMP (sorry SNMP, I'm over you) is
streaming telemetry, which is part of Netconf/YANG/OpenConfig.
This is more of a push method for these yang data models(the relevent one
here being snmp interfaces table).
It already exists on some Juniper and Cisco platforms.
Mike Krygeris


>
> On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory"
>  wrote:
>
> >On the HFC / CMTS side of things we have IPDR which I believe has some
> >open source collectors out there. I'm not sure that IPDR is used much
> >outside of the HFC world though.
>
> IPDR was my first thought as an alternative to SNMP. Is its accuracy
> comparable? It’s been included into TR-069, so it’s theoretically
> available to telcos, too. And usage-based billing is part of it’s purpose.
>
>
> Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows,
> not bits, and I don’t want to record flows. But I’d be interested in
> hearing others’ experience.
>
>
> Lee
>
>
>
>

Spoofer Project

[Matthew Luckie]

Hi,

The CAIDA Spoofer project has been collecting and publicly sharing
data on the deployment of source address validation since March 2016.
We've built up a reasonably large install-base of the open-source
client, and receive tests from 400-500 unique IPs per day.  We're
posting reports with links to test outcomes on the spoofer website.
In particular, we've got summary statistics for each AS at:

https://spoofer.caida.org/as_stats.php

If you know an operator for anyone on that list who has at least one
spoofable prefix, please feel free to reach out to them and let them
know.  I've been sending emails to abuse contacts for nearly a year
now.  Roughly 1/5 ASes I've contacted have fixed at least one problem.
The remediation we know about (automatically generated) is at:

https://spoofer.caida.org/remedy.php

In order to improve the notification emails, I'm also soliciting
configuration snippets from operators who have deployed source address
validation.  If you have deployed SAV and wouldn't mind sharing
redacted configuration (privately is fine) including any necessary
platform details (such as vendor and operating system) we would
greatly appreciate it.  We will aggregate and post configuration
snippets at https://spoofer.caida.org/

Matthew

signature.asc
Description: PGP signature

Re: Admiral Hosting in London

[Andy Smith]

Hello,

On Thu, Jul 27, 2017 at 03:54:01PM -0400, Michael Wayne wrote:
> We were contacted by Admiral Hosting in London to rent some our
> unused IP space. While they insist that they're not spammers, we can
> not find out much about them.
> 
> Has anyone had any dealings with this company? Legit? Scam? We
> are not interested in contributing to the Scam/Spam problem and
> figured I would ask here.

Had a couple of exactly the same messages from them. It seems like
one guy with no infrastructure of their own. Asked him a few
questions along the lines of why he was willing to pay more than the
cost of becoming a RIPE member for less than a /22 and he eventually
went away.

As others have said, anyone wanting to lease IPs is likely going to
do something that ruins the reputation of the IPs and relies on not
having their name on it at the registry level.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit?

[Sebastian Wiesinger]

* Ronald F. Guilmette  [2017-08-02 09:37]:
> 
> The annotations in the RIPE WHOIS record for AS202746 seem pretty clear to me.
> This thing is B-O-G-U-S!

You know, people might be more willing to listen to you when you
express your points in a less emotional and aggressive tone.

Regards


Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant

Re: Cisco Nexus 93180YC Switch Feedback

[Tim Stevenson]

At 07:39 PM 7/25/2017  Tuesday, Bill Woodcock opined:

> On Jul 25, 2017, at 7:25 PM, James Braunegg 
 wrote:

>
> Dear Nanog
>
> Just wondering if anyone is using the Cisco 
Nexus 93180YC with the LAN enterprise license 
and has any honest feedback about this 
platform, especially if you are using VXLAN 
routing and eVPN, would love to hear from you.

>
> For those that don't know the Cisco Nexus 
93180YC is a 1RU switch with 48 x 25gbit ports 
SFP+ ports (1G, 10G or 25G) + 6 x 100gbit QSFP uplink ports. (40G, 50G or 100G)


We’ve started testing them, as well as the 
92160YCX and C92300YC, for IXP use.  Notably 
only four of the six 100G ports on the 92160YCX 
will run at 100G, leaving two at 40G.



Actually, only two.

tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed
Ethernet1/49
  Speed: 4
Ethernet1/50
  Speed: 1000,1,25000,4,5,10
Ethernet1/51
  Speed: 4
Ethernet1/52
  Speed: 1000,1,25000,4,5,10
Ethernet1/53
  Speed: 4
Ethernet1/54
  Speed: 4
tstevens-92160yc-1#


All 6 on 93180YC EX/FX are 100G capable.

Tim




Anybody had any luck sourcing 2x25G NICs for Cisco UCS servers?

-Bill











Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Distinguished Engineer, Technical Marketing
Data Center Switching
Cisco - http://www.cisco.com
+1(408)526-6759

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Nick W]

Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them
all, sitting in my homelab for now. Multiple full tables, nothing fancy for
firewall or QOS, but ran into issues with random ribd/bgpd crashes and
kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would
personally stay away from them until they are out of beta, and possibly
even another 6-12 months after that.

The current stable EdgeMax version (1.9.1.1) is relatively stable, but
using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP)
- nothing too major, but can be annoying. Probably okay for what you
described. Depending on how much throughput you need, an ERPro, or Mikrotik
would probably be fine. If you need 10G, load up VyOS on some cheap servers
with an Intel or Solarflare card... probably cheaper than a beta Infinity
or Mikrotik.

On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders  wrote:

> Dear NANOG,
>
> Some friends of mine are operating a nonprofit (on shoe string) and looking
> to connect some CDN caches to an IX fabric. A BGP speaking device is needed
> between the caches and the BGP peers connected to the fabric. The BGP
> speaker is needed to present the peers on the IX with a unified view of the
> assemblage of CDN nodes.
>
> I was wondering whether anyone was experience with the "EdgeRouter Infinity
> XG" device, specifically in the role of a simple peering router for a
> couple of tens of thousands of routes. (I'd point default to the left and
> take just the on-net routes on the right to reduce the table size
> requirement).
>
> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
> automatable (supports idempotency), can forward IMIX at line-rate, *flow,
> and exposes some telemetry via SNMP.
>
> Any note sharing would be appreciated!
>
> Kind regards,
>
> Job
>

Re: Reviews - GTT, NTT and Telia

[Van Dyk, Donovan via NANOG]

Hello, 

We use all three globally. 

NTT – Like everyone already stated, excellent customer service. Fast and very 
knowledgeable. 

TELIA – It was a rocky start with them in the beginning, but they’ve been very 
good lately (About a year). Customer service is always fast and decent. In the 
beginning, their maintenances tended to cause problems they did not expect. We 
would have a couple service interruption and later find out they were 
conducting maintenance on their internal network. We were not expected to be 
affected so weren’t notified type thing. They also have had quite a few 
mis-configuration issues which put a little doubt in their changes and 
engineers. But they’ve implemented stricter change control and peer review 
which seems to have mitigated this. A good thing in my eyes is they are always 
forth coming if there was a problem on their side. All in all, I recommend them.

GTT – Ever since they merged their network with Hibernia (About 6months ago), 
their customer service has taken a big hit. Tickets can now take days to hear 
back from them, have to constantly ask for updates. I think their NOC is 
swamped with work and are backed up. If your issue is not ongoing, it could be 
awhile. I don’t want to harp on them, but their customer service used to be 
excellent. I think they are going through some growing pains right now, 
hopefully they turn it around soon. As for their network, it’s reliable, a 
couple hits here and there, but you’ll see that anywhere.  

Regards,
--
Donovan Van Dyk
SOC Network Engineer
Office: +1.954.620.6002 x911
Fort Lauderdale, FL USA


The information contained in this electronic mail transmission and its 
attachments may be privileged and confidential and protected from disclosure. 
If the reader of this message is not the intended recipient (or an individual 
responsible for delivery of the message to such person), you are strictly 
prohibited from copying, disseminating or distributing this communication. If 
you have received this communication in error, please notify the sender 
immediately and destroy all electronic, paper or other versions.
 

On 8/7/17, 1:19 PM, "Ramy Hashish"  wrote:

Thank you so much Edward for your elaborate review.

I would like to read more reviews, we are going to consolidate many smaller
circuits in two 10Gs, it would be great if we can learn the experience the
easy way :)

Ramy

On Aug 7, 2017 17:16, "Edward Dore" 
wrote:


Hi Ramy,

We use both GTT and NTT for IP transit in the UK. The NTT NOC is absolutely
excellent and I wouldn’t hesitate to recommend them. We had serious service
delivery problems with GTT which dragged on for months, but once they
finally managed to provision the service it has been perfectly reliable and
their NOC seemed OK on the few occasions that we’ve needed to deal with
them.

Edward Dore
Freethought Internet

Re: ARIN NRPM 2017.4: New Policies Implemented

[John Curran]

Mel -

  My apologies.   There is a NRPM change log is available in the navigation box
  on the right hand side of the NRPM page, and it contains links to the two 
policy
  language changes (which I’ve included below for ready reference) -

  https://www.arin.net/policy/proposals/2016_3.html
  https://www.arin.net/policy/proposals/2016_9.html

Thanks!
/John

On 8 Aug 2017, at 11:25 AM, Mel Beckman 
> wrote:

John,

Forgive me if I'm missing something obvious, but I looked at all the links in 
the email you forwarded to TW list, and I cannot see anything that specifically 
details the set of two policy changes you mentioned. The minutes of the June 
meeting talk about some policy changes in general, but they don't provide the 
specific language. I could try to diff the entire policy in the NPRM, but 
that's not very practical. Is there a mark-up document showing the specific 
changes and where they appear in the in NPRM?

-mel

On Aug 8, 2017, at 8:15 AM, John Curran 
> wrote:

NANOGers:

Two new policies affecting transfers of number resources have been implemented
at ARIN – it is worthing taking a moment to become familiar with these changes 
if
you manage IP number resources.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN >
Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented
Date: 8 August 2017 at 11:08:52 AM EDT
To: >

On 22 June 2017, the Board of Trustees adopted the following Recommended Draft 
Policies:

Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for 
justifying small IPv4 transfers

Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers

These policies are now in effect. A new version of the ARIN Number Resource 
Policy Manual (NRPM) has been published to the ARIN website.

NRPM version 2017.4 is effective 8 August 2017 and supersedes the previous 
version.

The NRPM is available at:

https://www.arin.net/policy/nrpm.html

Board minutes are available at:

https://www.arin.net/about_us/bot/index.html

Draft policies and proposals are available at:

https://www.arin.net/policy/proposals/

The ARIN Policy Development Process (PDP) is available at:

https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (arin-p...@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: ARIN NRPM 2017.4: New Policies Implemented

[Mel Beckman]

John,

Forgive me if I'm missing something obvious, but I looked at all the links in 
the email you forwarded to TW list, and I cannot see anything that specifically 
details the set of two policy changes you mentioned. The minutes of the June 
meeting talk about some policy changes in general, but they don't provide the 
specific language. I could try to diff the entire policy in the NPRM, but 
that's not very practical. Is there a mark-up document showing the specific 
changes and where they appear in the in NPRM?

-mel 

> On Aug 8, 2017, at 8:15 AM, John Curran  wrote:
> 
> NANOGers:
> 
> Two new policies affecting transfers of number resources have been implemented
> at ARIN – it is worthing taking a moment to become familiar with these 
> changes if
> you manage IP number resources.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> Begin forwarded message:
> 
> From: ARIN >
> Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented
> Date: 8 August 2017 at 11:08:52 AM EDT
> To: >
> 
> On 22 June 2017, the Board of Trustees adopted the following Recommended 
> Draft Policies:
> 
> Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for 
> justifying small IPv4 transfers
> 
> Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition 
> Transfers
> 
> These policies are now in effect. A new version of the ARIN Number Resource 
> Policy Manual (NRPM) has been published to the ARIN website.
> 
> NRPM version 2017.4 is effective 8 August 2017 and supersedes the previous 
> version.
> 
> The NRPM is available at:
> 
> https://www.arin.net/policy/nrpm.html
> 
> Board minutes are available at:
> 
> https://www.arin.net/about_us/bot/index.html
> 
> Draft policies and proposals are available at:
> 
> https://www.arin.net/policy/proposals/
> 
> The ARIN Policy Development Process (PDP) is available at:
> 
> https://www.arin.net/policy/pdp.html
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (arin-p...@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
> 

ARIN NRPM 2017.4: New Policies Implemented

[John Curran]

NANOGers:

Two new policies affecting transfers of number resources have been implemented
at ARIN – it is worthing taking a moment to become familiar with these changes 
if
you manage IP number resources.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN >
Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented
Date: 8 August 2017 at 11:08:52 AM EDT
To: >

On 22 June 2017, the Board of Trustees adopted the following Recommended Draft 
Policies:

Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for 
justifying small IPv4 transfers

Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers

These policies are now in effect. A new version of the ARIN Number Resource 
Policy Manual (NRPM) has been published to the ARIN website.

NRPM version 2017.4 is effective 8 August 2017 and supersedes the previous 
version.

The NRPM is available at:

https://www.arin.net/policy/nrpm.html

Board minutes are available at:

https://www.arin.net/about_us/bot/index.html

Draft policies and proposals are available at:

https://www.arin.net/policy/proposals/

The ARIN Policy Development Process (PDP) is available at:

https://www.arin.net/policy/pdp.html

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (arin-p...@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: Reviews - GTT, NTT and Telia

[i3D.net - Martijn Schmidt]

Hi Ramy,

Having worked with NTT & GTT, but not Telia, I can heartily recommend
NTT. Every one of these providers has its peering challenges so you'll
need diversity regardless of the one you pick, but the operations team
over at NTT has been absolutely stellar in terms of technical know-how
and always provides clear communication about any issues that one might
encounter operationally speaking.

Best regards,
Martijn

On 07-08-17 19:19, Ramy Hashish wrote:
> Thank you so much Edward for your elaborate review.
>
> I would like to read more reviews, we are going to consolidate many smaller
> circuits in two 10Gs, it would be great if we can learn the experience the
> easy way :)
>
> Ramy
>
> On Aug 7, 2017 17:16, "Edward Dore" 
> wrote:
>
>
> Hi Ramy,
>
> We use both GTT and NTT for IP transit in the UK. The NTT NOC is absolutely
> excellent and I wouldn’t hesitate to recommend them. We had serious service
> delivery problems with GTT which dragged on for months, but once they
> finally managed to provision the service it has been perfectly reliable and
> their NOC seemed OK on the few occasions that we’ve needed to deal with
> them.
>
> Edward Dore
> Freethought Internet