Re: Amazon peering peeps on the list?

[Craig]

We had to do the same, a ticket and issue moved along quickly and a CO-
worker had the peers up quickly.


On Fri, Mar 9, 2018 at 9:16 AM Jason Kuehl  wrote:

> The better way to go ahead and get a hold of Amazon for peering issues is
> to open a ticket with them via AWS account with business support.
>
> This is how I resolved issues with peering in the past.
>
> On Mar 9, 2018 8:27 AM, "Joe Nelson"  wrote:
>
> > I've all but given up on trying to get a response from
> peer...@amazon.com.
> > If you do end up getting a contact, please share.
> >
> > On Wed, Mar 7, 2018 at 8:19 PM, Mike Lyon  wrote:
> >
> > > Anyone on the list from Amazon peering? Have sent multiple emails to
> > > peer...@amazon.com over the past couple of weeks with no reply.
> > >
> > > Any help would be appreciated.
> > >
> > > Thank You,
> > > Mike
> > >
> > >
> > > --
> > > Mike Lyon
> > > mike.l...@gmail.com
> > > http://www.linkedin.com/in/mlyon
> > >
> >
>

MANRS IXP Webinar: Tuesday, 13 March

[Chris Grundemann]

Hail NANOGers!

If you operate an IX in North America, this message is for you.

(I'm passing it along on behalf of my former colleagues at the Internet
Society.)

Hope to "see" you on the webinar this Tuesday!


———
Hi,

The MANRS IXP Partnership program is designed to invite and encourage
participation of IXPs in MANRS (Mutually Agreed Norms for Routing
Security). In accordance with the principles of the initiative, the
membership depends on the visible commitment to improve the routing
security of the peering fabric and Internet infrastructure in general and
demonstrated by the implementation of defined Actions.

The Internet Society is looking for leading IXPs around the world that have
a track record in contributing to routing security, already implement the
majority of Actions and are willing to participate in the launch of this
program, planned in early 2018. The set of Actions was developed by the
development team consisting of IXP representatives around the world. It has
been reviewed in by various IXP communities, such as EURO-IX, LAC-IX, Af-IX.

I’d like to invite you to participate in a webinar on March 13 at 14:00 EDT
(18:00 UTC) where we present the IXP Partnership Program and the Actions to
the North-American IXP community and invite your feedback. Call details are
below. We would also ask you to disseminate the information about the
webinar to the NA IX community.

MANRS (https://www.manrs.org) is a collaborative initiative, coordinated by
the Internet Society. It was launched in November 2014 and has received
much encouragement from all sections of the Internet industry. The key
objective of MANRS is to gain industry-wide agreement on a minimum set of
practices for secure routing across the Internet, through coordinated
action by many parties.

MANRS was designed for network operators, but other parties can play an
important role in facilitating improvements in routing security such as
Internet Exchange Points (IXPs). Many of them represent active communities
with common operational objectives and already contribute to a more
resilient and secure Internet infrastructure.


Thanks!

Mark Buell
Regional Bureau Director, North America
Internet Society





Details:
Topic: MANRS and IXPs
Time: Mar 13, 2018 7:00 PM Amsterdam, Berlin, Rome, Stockholm, Vienna

Join from PC, Mac, Linux, iOS or Android: https://isoc.zoom.us/j/288357813

Or iPhone one-tap :
US: +16699006833,,288357813#  or +16465588656,,288357813#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833  or +1 646 558 8656
Meeting ID: 288 357 813
International numbers available: https://isoc.zoom.
us/zoomconference?m=WXysPTqEpKm5ELZq6evhxxHUX43prdSf




-- 
@ChrisGrundemann
http://chrisgrundemann.com

Re: Zayo zColo Xcon Pricing

[Jim Shankland]

On 3/7/18 9:00 AM, Ian Mock wrote:

Everything is negotiable. NRC on a cross-connect is ridiculous. The cost to
run should be made up with the amount they're charging monthly. I wouldn't
pay more than $200/mo for copper.

Actually, as a reflection of the provider's cost, NRC for a 
cross-connect makes more sense than a recurring cost. After all, there's 
labor involved in setting up the cross-connect, but once it's in, it 
pretty much just sits there.


The fallacy here, though, is assuming that rational pricing bears some 
relation to the vendor's cost to provide the good or service. Actual 
price is based on what the market will bear. Sharing pricing information 
on NANOG likely helps consumers by increasing market transparency (which 
is why vendors love to block such sharing via NDA). Much as I sympathize 
with the sentiment, though, "ridiculous" is meaningless in this context. 
It may even be construed as positive, as in: "Awesome, we're making 
ridiculous profits on all these copper cross-connects." :-)


Jim

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 10 Mar, 2018

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  689505
Prefixes after maximum aggregation (per Origin AS):  267381
Deaggregation factor:  2.58
Unique aggregates announced (without unneeded subnets):  332013
Total ASes present in the Internet Routing Table: 60061
Prefixes per ASN: 11.48
Origin-only ASes present in the Internet Routing Table:   51878
Origin ASes announcing only one prefix:   22755
Transit ASes present in the Internet Routing Table:8183
Transit-only ASes present in the Internet Routing Table:255
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  37
Max AS path prepend of ASN (262865)  25
Prefixes from unregistered ASNs in the Routing Table:61
Number of instances of unregistered ASNs:61
Number of 32-bit ASNs allocated by the RIRs:  21745
Number of 32-bit ASNs visible in the Routing Table:   17492
Prefixes from 32-bit ASNs in the Routing Table:   72632
Number of bogon 32-bit ASNs visible in the Routing Table:12
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:329
Number of addresses announced to Internet:   2855882594
Equivalent to 170 /8s, 57 /16s and 79 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.8
Total number of prefixes smaller than registry allocations:  229062

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   189556
Total APNIC prefixes after maximum aggregation:   54236
APNIC Deaggregation factor:3.50
Prefixes being announced from the APNIC address blocks:  188509
Unique aggregates announced from the APNIC address blocks:77335
APNIC Region origin ASes present in the Internet Routing Table:8697
APNIC Prefixes per ASN:   21.68
APNIC Region origin ASes announcing only one prefix:   2465
APNIC Region transit ASes present in the Internet Routing Table:   1285
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3609
Number of APNIC addresses announced to Internet:  767978658
Equivalent to 45 /8s, 198 /16s and 108 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:205495
Total ARIN prefixes after maximum aggregation:98454
ARIN Deaggregation factor: 2.09
Prefixes being announced from the ARIN address blocks:   206400
Unique aggregates announced from the ARIN address blocks: 97400
ARIN Region origin ASes present in the Internet Routing Table:18111
ARIN Prefixes per ASN:  

Re: Amazon peering peeps on the list?

[Jason Kuehl]

The better way to go ahead and get a hold of Amazon for peering issues is
to open a ticket with them via AWS account with business support.

This is how I resolved issues with peering in the past.

On Mar 9, 2018 8:27 AM, "Joe Nelson"  wrote:

> I've all but given up on trying to get a response from peer...@amazon.com.
> If you do end up getting a contact, please share.
>
> On Wed, Mar 7, 2018 at 8:19 PM, Mike Lyon  wrote:
>
> > Anyone on the list from Amazon peering? Have sent multiple emails to
> > peer...@amazon.com over the past couple of weeks with no reply.
> >
> > Any help would be appreciated.
> >
> > Thank You,
> > Mike
> >
> >
> > --
> > Mike Lyon
> > mike.l...@gmail.com
> > http://www.linkedin.com/in/mlyon
> >
>

Re: BCP 38 addendum

[Fabien VINCENT (NaNOG)]

Le 2018-03-07 16:19, Saku Ytti a écrit :


Hey,

How would this work?

ISP1--ISP2---ISP3
||
+---ISP4-+

In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects
to ISP2, ISP4

- ISP3 receives ISP1 prefixes via ISP[24]
- ISP3 advertises its prefix out via ISP4

ISP1 will receive traffic from ISP3 through ISP2, and that is not in
the eBGP session, so prefix gets dropped.

Internet is symmetric and people don't advertise consistently, so
while maybe undesirable above stuff does happen. It's not obvious to
me what this eBGP-routes-in-VRF and RPF-to-VRF would solve, which use
case does it address which is not addressed by existing tooling.


Internet is not symmetric ;) My problem is more simple :

I'm multihomed, so I cannot use uRPF strict mode, because my traffic is 
not symetric. Prepend can help, but that obviously not the way of doing 
TE for inbound traffic, expect if you love crappy design or you 
multihomed is just under 10 peerings.


Loose mode is not useful, because of so many parameters, default route, 
local-pref / med inside the network, which lead to asymetrical path. So 
routes not inserted in FIB. So uRPF strict mode not possible. But in 
loose mode, because even Tier1 are not doing any BCP 38 filters (tested 
and verified for all least 3 Tier1), ACL or prefix list (that's not the 
point of BGP hijack here), I received UDP spoofed traffic from routes I 
don't learned on this port. By in case my router has 2 ports, one with 
Level3, one with Cogent, uRPF loose mode will look at the FIB (so for 
all ports), not one where the packet is coming from and the BGP table 
facing this port + BGP table.


This is exactly my idea : why should I allowed uRPF passing traffic from 
routes not learned on this port ?? Why if I have Cogent + Level3 and I 
denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should 
get spoofed traffic from Level3 ranges over Cogent peering port ? That's 
just silly this kind of mode doesn't exist in uRPF ...


I'm aware it's due to hardware limitation, because uRPF look into FIB, 
not BGP Table or RIB, but that could help denying spoofed traffic that 
comes over transit tier 1 because the BCP38 to the downstreams are not 
in place, or not automatic (I'm still thinking why Level3 as an IRR and 
do use it for filtering downstreams ...)




There is much cheaper feature which has worked for decades which
applies better to this problem. While you generate list of prefixes
ISP2 COULD announce to you, that includes the prefix ISP3 is NOT
announcing, but COULD. The same prefix-list you use for BGP
announcements use in your ACL.


Yeah agreee, but not usable and programmable regarding huge upstreams 
values (over 100, I know hw even for smaller values that will say "my 
ASIC is limited man").




On 6 March 2018 at 23:16, Fabien VINCENT (NaNOG)  
wrote: Le 2018-03-06 19:39, Barry Greene a écrit :


On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) 
 wrote:
Hope one day the 3rd mode of uRPF will be something else than a plan 
...

uRPF is not very usefull when multi homed. And as far as I know, multi
homed networks are increasing as fast as PNI development ;)
This was working microcode code when I left in 2008. Several operators 
tested, but none deployed (no pushing or pulling).


Yep,  but saw only reference of it, but no real CLI implementation
(especially on Cisco), so I guess it's not a killer feature to sell
routers ;)

In 2005 :
https://www.cisco.com/c/dam/en_us/about/security/intelligence/urpf.pdf

"A third phase is currently under way that will create a way to have
strict enforcement of the uRPF check on individual ISP-ISP edges. Here,
external BGP (eBGP) peer sessions will send specific prefixes to a
dedicated Virtual routing and forwarding (VRF) table. This will allow
uRPF to query the VRF table that contains all the routes for that
specific eBGP peering session over the interface, thus verifying
(authorizing) the source addresses of packets matching the advertised
routes from the peered ISP"

That's obviously not so sexy, but I guess the problem is on hardware
performance, as the prefer method should to have a look on BGP tables,
and uRPF is done on FIB / ASIC level. Sadly, seems not possible right ?

--
FABIEN VINCENT
_@beufanet_


--
FABIEN VINCENT
_@beufanet_

Re: Amazon peering peeps on the list?

[Joe Nelson]

I've all but given up on trying to get a response from peer...@amazon.com.
If you do end up getting a contact, please share.

On Wed, Mar 7, 2018 at 8:19 PM, Mike Lyon  wrote:

> Anyone on the list from Amazon peering? Have sent multiple emails to
> peer...@amazon.com over the past couple of weeks with no reply.
>
> Any help would be appreciated.
>
> Thank You,
> Mike
>
>
> --
> Mike Lyon
> mike.l...@gmail.com
> http://www.linkedin.com/in/mlyon
>

Re: Zayo zColo Xcon Pricing

[Ian Mock]

Everything is negotiable. NRC on a cross-connect is ridiculous. The cost to
run should be made up with the amount they're charging monthly. I wouldn't
pay more than $200/mo for copper.

Ian Mock

On Wed, Mar 7, 2018 at 9:10 AM, James Laszko  wrote:

> One of our colo’s in San Diego was purchased by Zayo recently and I
> requested a new copper Ethernet xcon to be placed.  After a few days I
> received a quote from my new rep quoting a MRC 3x what I’m currently paying
> for existing xcon’s as well as a hefty NRC as well.  Anyone have any
> experience with this kind of thing?  Anyone care to share what an average
> copper xcon, single floor, meet-me-room to cage, Ethernet from carrier
> circuit costs?  (This xcon is approx 30 feet..)
>
> Thanks!
>
> James
>
> Sent from my iPad

Looking for a network abuse contact at CenturyLink

[Bill Weiss]

I know, it's a big place. I'd like to talk about something I'm seeing from
your networks and see if you agree on what it could be. This includes
legacy Qwest, CenturyTel, etc.  I could list ASNs but it's kind of a long
list, as you'd expect :)

Thank you, and sorry for the noise.

-- 
Bill Weiss

Google

[Daniel Temple]

I'm having a problem with some Google services that seems to be related to
our public IP block. Anyone have a contact there that could check the IP
block against any sort of google black list? Thanks

 

Daniel Temple

WISP Administrator 

CMB Systems, Inc 

 

92-1 Hwy 64 West

Cashiers, NC 28717 

Direct: 828-743-2470 ext.209

FAX: 828-743-3155 

dan...@pyranah.com  

 

Confidentiality Notice 

This message is being sent by or on behalf of CMB Systems, Inc. It is
intended exclusively for the individual or entity to which it is addressed.
This communication may contain information that is proprietary, privileged
or confidential or otherwise legally exempt from disclosure. If you are not
the named addressee, you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
message in error, please notify the sender immediately by e-mail and delete
all copies of the message.