From george.herbert at gmail.com Sat Apr 1 18:19:55 2017 From: george.herbert at gmail.com (George William Herbert) Date: Sat, 1 Apr 2017 11:19:55 -0700 Subject: AS9498 Bharti BGP hijacks Message-ID: <1D660CCA-14E1-4C9F-96DD-756F6BE879E3@gmail.com> Hey, Bharti, knock that off. http://bgpstream.com/event/78126 http://bgpstream.com/event/78125 http://bgpstream.com/event/78124 http://bgpstream.com/event/78123 http://bgpstream.com/event/78122 Sent from my iPhone From mehmet at akcin.net Sat Apr 1 20:36:57 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 01 Apr 2017 20:36:57 +0000 Subject: Interconnection Track Message-ID: Hello, As promised few months ago publically I have volunteered to bring together content to have Peering Track back to agenda. Now called "Interconnection Track" I would like to ask those who will attend, have attended in person in the past or those who have organized similar events to chime in and help suggest topics to cover in this 90 min session. I must say, Interconnection Track has been a major part if NANOG for many years. We have watched those who we consider as legends to discuss very important topics there. Please try to make your suggestion in order of importance for you as well as from community. I can try to do my best with help of few folks to bring this track back but you can help make it even better so please take a moment and send me your suggestions. Thanks in advance! Mehmet From tyler at tgconrad.com Sat Apr 1 21:24:24 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Sat, 1 Apr 2017 14:24:24 -0700 Subject: AS9498 Bharti BGP hijacks In-Reply-To: <1D660CCA-14E1-4C9F-96DD-756F6BE879E3@gmail.com> References: <1D660CCA-14E1-4C9F-96DD-756F6BE879E3@gmail.com> Message-ID: So not only are they hijacking prefixes, they're leaking the /30s to their peers. Failure through and through. On Saturday, April 1, 2017, George William Herbert wrote: > > Hey, Bharti, knock that off. > > http://bgpstream.com/event/78126 > http://bgpstream.com/event/78125 > http://bgpstream.com/event/78124 > http://bgpstream.com/event/78123 > http://bgpstream.com/event/78122 > > > Sent from my iPhone > From job at instituut.net Sat Apr 1 21:33:55 2017 From: job at instituut.net (Job Snijders) Date: Sat, 01 Apr 2017 21:33:55 +0000 Subject: AS9498 Bharti BGP hijacks In-Reply-To: References: <1D660CCA-14E1-4C9F-96DD-756F6BE879E3@gmail.com> Message-ID: Hi all, Perhaps another explanation is that these are router2router linknets between the involved parties, and all we are seeing is the effect of "redistribute connected". If this is the case, the word "hijack" might be somewhat strong worded. Kind regards, Job On Sat, 1 Apr 2017 at 23:25, Tyler Conrad wrote: So not only are they hijacking prefixes, they're leaking the /30s to their peers. Failure through and through. On Saturday, April 1, 2017, George William Herbert wrote: > > Hey, Bharti, knock that off. > > http://bgpstream.com/event/78126 > http://bgpstream.com/event/78125 > http://bgpstream.com/event/78124 > http://bgpstream.com/event/78123 > http://bgpstream.com/event/78122 > > > Sent from my iPhone > From bengelly at gmail.com Sat Apr 1 22:09:41 2017 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Sun, 2 Apr 2017 00:09:41 +0200 Subject: AS9498 Bharti BGP hijacks In-Reply-To: References: <1D660CCA-14E1-4C9F-96DD-756F6BE879E3@gmail.com> Message-ID: <88A35AB5-B9BC-47E6-A3A8-AE7604D14C6F@gmail.com> Hi, What's more concerning here is that those prefixes were able to pass through all filters on their way, via their transits and maybe probably via their peers as well. Haven't we been here before !?! And here I thought 2017 internet would be a "safer" place. Silly me... Y. > Le 1 avr. 2017 ? 23:33, Job Snijders a ?crit : > > Hi all, > > Perhaps another explanation is that these are router2router linknets > between the involved parties, and all we are seeing is the effect of > "redistribute connected". If this is the case, the word "hijack" might be > somewhat strong worded. > > Kind regards, > > Job > > On Sat, 1 Apr 2017 at 23:25, Tyler Conrad wrote: > > So not only are they hijacking prefixes, they're leaking the /30s to their > peers. Failure through and through. > > On Saturday, April 1, 2017, George William Herbert wrote: > >> >> Hey, Bharti, knock that off. >> >> http://bgpstream.com/event/78126 >> http://bgpstream.com/event/78125 >> http://bgpstream.com/event/78124 >> http://bgpstream.com/event/78123 >> http://bgpstream.com/event/78122 >> >> >> Sent from my iPhone >> From hannigan at gmail.com Sat Apr 1 23:59:20 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 1 Apr 2017 19:59:20 -0400 Subject: Interconnection Track In-Reply-To: References: Message-ID: Hi Mehmet, *Great effort here. +1.* I'd suggest that you bring new faces to the game. New ideas are needed. Topic wise: - 'inside' settlement free peering - Content vs. Network Operators, and right sizing where the traffic comes from - Once and for all: Are IXP's as dead as some say? Hope that helps. Best, -M< On Sat, Apr 1, 2017 at 4:36 PM, Mehmet Akcin wrote: > Hello, > > As promised few months ago publically I have volunteered to bring together > content to have Peering Track back to agenda. Now called "Interconnection > Track" > > I would like to ask those who will attend, have attended in person in the > past or those who have organized similar events to chime in and help > suggest topics to cover in this 90 min session. > > I must say, Interconnection Track has been a major part if NANOG for many > years. We have watched those who we consider as legends to discuss very > important topics there. > > Please try to make your suggestion in order of importance for you as well > as from community. > > I can try to do my best with help of few folks to bring this track back but > you can help make it even better so please take a moment and send me your > suggestions. > > Thanks in advance! > > Mehmet > From arnold at nipper.de Sun Apr 2 17:17:33 2017 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 2 Apr 2017 19:17:33 +0200 Subject: Interconnection Track In-Reply-To: References: Message-ID: <61f6266d-51a0-5f05-f677-51106105410b@nipper.de> On 02.04.2017 01:59, Martin Hannigan wrote: > - Once and for all: Are IXP's as dead as some say? > The last time I heard "dead" it was spelled out: transit is dead ;-) Arnold -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From netravnen+nanog at gmail.com Sat Apr 1 22:15:37 2017 From: netravnen+nanog at gmail.com (netravnen+nanog at gmail.com) Date: Sun, 2 Apr 2017 00:15:37 +0200 Subject: AS9498 Bharti BGP hijacks In-Reply-To: <88A35AB5-B9BC-47E6-A3A8-AE7604D14C6F@gmail.com> References: <1D660CCA-14E1-4C9F-96DD-756F6BE879E3@gmail.com> <88A35AB5-B9BC-47E6-A3A8-AE7604D14C6F@gmail.com> Message-ID: I would (from a peering perspective) see this as a configuration error where somebody/someone botched a configuration change in a specific network router. Partly because a) seeing as the reports is sequentially numbered, b) as - already pointed out - it is either /30 or /29. c) thou I'm puzzled about the /27 leaked https://bgpstream.com/event/78122 Somebody noticed, somebody or another fixed the error in silence and said nothing afterwards. Sadly, No route-maps or the like were in place to prevent the prefix leaks from happening. That in it-self should be stuff for the people at Origin ASN 9498 (BHARTI Airtel Ltd.) to think a little "harder" about in the future. "Routers mostly only fail because of the selected many people managing them." Kind regards, Christoffer, CH11404-RIPE On 2 April 2017 at 00:09, Youssef Bengelloun-Zahr wrote: > Hi, > > What's more concerning here is that those prefixes were able to pass through all filters on their way, via their transits and maybe probably via their peers as well. Haven't we been here before !?! > > And here I thought 2017 internet would be a "safer" place. Silly me... > > Y. > > > >> Le 1 avr. 2017 ? 23:33, Job Snijders a ?crit : >> >> Hi all, >> >> Perhaps another explanation is that these are router2router linknets >> between the involved parties, and all we are seeing is the effect of >> "redistribute connected". If this is the case, the word "hijack" might be >> somewhat strong worded. >> >> Kind regards, >> >> Job >> >> On Sat, 1 Apr 2017 at 23:25, Tyler Conrad wrote: >> >> So not only are they hijacking prefixes, they're leaking the /30s to their >> peers. Failure through and through. >> >> On Saturday, April 1, 2017, George William Herbert > wrote: >> >>> >>> Hey, Bharti, knock that off. >>> >>> http://bgpstream.com/event/78126 >>> http://bgpstream.com/event/78125 >>> http://bgpstream.com/event/78124 >>> http://bgpstream.com/event/78123 >>> http://bgpstream.com/event/78122 >>> >>> >>> Sent from my iPhone >>> From m4rtntns at gmail.com Mon Apr 3 15:00:09 2017 From: m4rtntns at gmail.com (Martin T) Date: Mon, 3 Apr 2017 18:00:09 +0300 Subject: association between ASN and company name in ARIN region In-Reply-To: <87pogxn7nn.fsf@mid.deneb.enyo.de> References: <67f61a68-0aa3-b26b-2c97-051cd707011d@nipper.de> <87pogxn7nn.fsf@mid.deneb.enyo.de> Message-ID: Thanks for replies! Who is allowed to change "OrgName" attribute value? Only ARIN? thanks, Martin On Fri, Mar 31, 2017 at 11:59 AM, Florian Weimer wrote: > * Arnold Nipper: > >> On 30.03.2017 17:50, Martin T wrote: >> >>> Is it possible to make a similar connection between AS number and >>> company name in ARIN region? In other words, how do you find out that >>> company is eligible to use AS number? >>> >> >> >> This doesn't work for you? >> >> whois -h whois.arin.net as174 | egrep > > Note that depending on the WHOIS client, this does not work. The > correct AS number query syntax for whois.arin.net does not include an > ?AS? prefix. The difference is only visibile for AS numbers with in > an AS range object. 14745 is an example that shows the difference. From alessandro.improta at iit.cnr.it Mon Apr 3 12:42:05 2017 From: alessandro.improta at iit.cnr.it (alessandro.improta at iit.cnr.it) Date: Mon, 03 Apr 2017 14:42:05 +0200 Subject: Alternatives to bgpmon? In-Reply-To: References: <913AF024-4C9A-4D80-B667-A41F7ACD99E6@dino.hostasaurus.com> <84ff8c94b38a494d95df09bc19ed0f3f@uth.tmc.edu> Message-ID: <11c7b44c621d8d7acf1a31073702db7d@iit.cnr.it> Hi all, it sounds like you may be interested in the project we are carrying on here in my research institute here in Pisa (Isolario project, www.isolario.it). The project is totally free of charge and we just require you to open one (or more) full route (v4/v6) BGP session(s) towards our route collectors to have one (or more) Isolario user(s). BGP packets received on these sessions will be used to provide to the users the real-time services we implemented (e.g. external reachability analyses and alerting), and they will be stored and made publicly available as every other route collecting project (e.g. Route Views and RIPE NCC RIS) on our website. My colleague Luca gave a presentation about that at NANOG66 in San Diego, so you may find the slides on NANOG archives. Just write me if you need any more detail about the project! Ale Il 2017-03-29 23:54 Victor Gonzalez ha scritto: > I just signed up for the free account .. gonna give a spin > > Victor > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Murphy, > William > Sent: Wednesday, March 29, 2017 2:51 PM > To: 'David Hubbard' ; nanog at nanog.org > Subject: RE: Alternatives to bgpmon? > > We are going to be trying ThousandEyes... They provide flexible > alerting rules for various BGP issues and their visualization is > excellent, kind of like BGPlay on steroids... > > Bill > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Hubbard > Sent: Wednesday, March 29, 2017 2:22 PM > To: nanog at nanog.org > Subject: Alternatives to bgpmon? > > Anyone have recommendations for an alternative service that works like > bgpmon (external reachability/peer monitoring, route hijack alerts, > etc)? Since their OpenDNS acquisition, I?ve found the service not > working reliably, as in I receive no alerts even when I?m > intentionally taking one of our peers offline, and after two attempts > to find out why this is, I receive no response, so it seems support is > now broken as well. > > Thanks, > > David From carywiedemann at gmail.com Mon Apr 3 16:06:26 2017 From: carywiedemann at gmail.com (Cary Wiedemann) Date: Mon, 3 Apr 2017 12:06:26 -0400 Subject: Nationwide AT&T BVOIP/SIP Outage Message-ID: All, Our AT&T BVOIP service is down nationwide. Our account managers are frantically looking into it but we don't have an official statement yet. Symptoms vary from no ringing (sourced from MegaPath), ring then drop (sourced from Verizon/T-Mobile), or "The call you are attempting to place is not allowed from this line" (sourced from AT&T Wireless). Anyone else experiencing this or have any explanations? It's supposedly affecting the entire platform. Anyone on-list from AT&T who can comment? Our PNT private line circuits are all up, it seems the BVOIP phone switch is just hard down. Sorry, I know NANOG isn't the best place for outage discussions; but the puck.nether.net Outages list seems to be broken today and AT&T is a gigantic North American phone provider. Thank you. - Cary From rvandolson at esri.com Mon Apr 3 16:29:41 2017 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 3 Apr 2017 09:29:41 -0700 Subject: Nationwide AT&T BVOIP/SIP Outage In-Reply-To: References: Message-ID: <20170403162941.GA1323@esri.com> On Mon, Apr 03, 2017 at 12:06:26PM -0400, Cary Wiedemann wrote: > All, > > Our AT&T BVOIP service is down nationwide. Our account managers are > frantically looking into it but we don't have an official statement yet. > > Symptoms vary from no ringing (sourced from MegaPath), ring then drop > (sourced from Verizon/T-Mobile), or "The call you are attempting to place > is not allowed from this line" (sourced from AT&T Wireless). > > Anyone else experiencing this or have any explanations? It's supposedly > affecting the entire platform. Anyone on-list from AT&T who can comment? > > Our PNT private line circuits are all up, it seems the BVOIP phone switch > is just hard down. > > Sorry, I know NANOG isn't the best place for outage discussions; but the > puck.nether.net Outages list seems to be broken today and AT&T is a > gigantic North American phone provider. > > Thank you. > > - Cary We're an ATT BVoIP/SIP user but not experiencing any issues. Southern California. Ray From tb at tburke.us Mon Apr 3 22:34:46 2017 From: tb at tburke.us (Tim Burke) Date: Mon, 3 Apr 2017 22:34:46 +0000 Subject: Nationwide AT&T BVOIP/SIP Outage In-Reply-To: References: Message-ID: Can confirm there was an outage here... Houston, TX area. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Cary Wiedemann Sent: Monday, April 3, 2017 11:06 AM To: North American Network Operators' Group Subject: Nationwide AT&T BVOIP/SIP Outage All, Our AT&T BVOIP service is down nationwide. Our account managers are frantically looking into it but we don't have an official statement yet. Symptoms vary from no ringing (sourced from MegaPath), ring then drop (sourced from Verizon/T-Mobile), or "The call you are attempting to place is not allowed from this line" (sourced from AT&T Wireless). Anyone else experiencing this or have any explanations? It's supposedly affecting the entire platform. Anyone on-list from AT&T who can comment? Our PNT private line circuits are all up, it seems the BVOIP phone switch is just hard down. Sorry, I know NANOG isn't the best place for outage discussions; but the puck.nether.net Outages list seems to be broken today and AT&T is a gigantic North American phone provider. Thank you. - Cary From jra at baylink.com Tue Apr 4 01:23:58 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 4 Apr 2017 01:23:58 +0000 (UTC) Subject: NTP problems/time.windows.com? Message-ID: <450865912.301293.1491269038290.JavaMail.zimbra@baylink.com> I haven't personally seen anything about this across my fleet; anyone here seeing tracks from it? http://www.ibtimes.com/how-change-ntp-server-microsofts-timewindowscom-causes-computers-display-wrong-time-2519884 Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From josh at imaginenetworksllc.com Tue Apr 4 01:35:56 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 3 Apr 2017 21:35:56 -0400 Subject: NTP problems/time.windows.com? In-Reply-To: <450865912.301293.1491269038290.JavaMail.zimbra@baylink.com> References: <450865912.301293.1491269038290.JavaMail.zimbra@baylink.com> Message-ID: Reddit has a big post on it. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Apr 3, 2017 9:25 PM, "Jay R. Ashworth" wrote: > I haven't personally seen anything about this across my fleet; anyone here > seeing tracks from it? > > http://www.ibtimes.com/how-change-ntp-server-microsofts- > timewindowscom-causes-computers-display-wrong-time-2519884 > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > From msa at latt.net Tue Apr 4 01:46:15 2017 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 3 Apr 2017 21:46:15 -0400 Subject: NTP problems/time.windows.com? In-Reply-To: <450865912.301293.1491269038290.JavaMail.zimbra@baylink.com> References: <450865912.301293.1491269038290.JavaMail.zimbra@baylink.com> Message-ID: <20170404014615.GB24050@puck.nether.net> On Tue, Apr 04, 2017 at 01:23:58AM +0000, Jay R. Ashworth wrote: > I haven't personally seen anything about this across my fleet; anyone here > seeing tracks from it? -snip- > http://www.ibtimes.com/how-change-ntp-server-microsofts-timewindowscom-causes-computers-display-wrong-time-2519884 -snip- "One explanation that has gained traction online as users scramble for answers is the suggestion that a cluster of time servers may have lost connection with an external source that syncs the time and date." Haven't seen it, but if people are reporting sudden hour offsets, on the first Monday in April, I'd bet on a DST implementation bug that hijacked the system clock on their servers. This doesn't look like the sort of error you'd get with a free running clock. --msa From esr at thyrsus.com Tue Apr 4 02:34:21 2017 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 3 Apr 2017 22:34:21 -0400 Subject: NTP problems/time.windows.com? In-Reply-To: <20170404014615.GB24050@puck.nether.net> References: <450865912.301293.1491269038290.JavaMail.zimbra@baylink.com> <20170404014615.GB24050@puck.nether.net> Message-ID: <20170404023421.GA21557@thyrsus.com> Majdi S. Abbas : > Haven't seen it, but if people are reporting sudden hour > offsets, on the first Monday in April, I'd bet on a DST implementation > bug that hijacked the system clock on their servers. > > This doesn't look like the sort of error you'd get with a free > running clock. I concur, about the one-hour shift anyway. The random garbage times aren't really likely either - jumps that large would tend to get the source rejected as a falseticker. It's a weird set of symptoms that rather looks as if they hit two different failure modes at once. Dunno. One of our NTPsec devs posted the link on one of our project channels and suggested maybe we ought to call M$ with an offer of help... -- Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. From jra at baylink.com Tue Apr 4 02:35:52 2017 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 4 Apr 2017 02:35:52 +0000 (UTC) Subject: NTP problems/time.windows.com? In-Reply-To: <20170404023421.GA21557@thyrsus.com> References: <450865912.301293.1491269038290.JavaMail.zimbra@baylink.com> <20170404014615.GB24050@puck.nether.net> <20170404023421.GA21557@thyrsus.com> Message-ID: <406290898.301460.1491273352159.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "esr" > To: "Majdi S. Abbas" > Cc: "jra" , "North American Network Operators' Group" > Sent: Monday, April 3, 2017 10:34:21 PM > Subject: Re: NTP problems/time.windows.com? > Majdi S. Abbas : >> Haven't seen it, but if people are reporting sudden hour >> offsets, on the first Monday in April, I'd bet on a DST implementation >> bug that hijacked the system clock on their servers. >> >> This doesn't look like the sort of error you'd get with a free >> running clock. > > I concur, about the one-hour shift anyway. The random garbage times > aren't really likely either - jumps that large would tend to get the > source rejected as a falseticker. > > It's a weird set of symptoms that rather looks as if they hit two different > failure modes at once. Dunno. It's not entirely clear whether it's *entirely* MSWin clients; I can't imagine anything being pointed at those servers that wasn't, though, cause who the hell would? Anyone smart enough to manually select NTP upstreams isn't going *there*... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From main at kipsang.com Tue Apr 4 11:00:20 2017 From: main at kipsang.com (Michael Bullut) Date: Tue, 4 Apr 2017 14:00:20 +0300 Subject: Microsoft Exchange Error... Message-ID: Greetings Team, Please find attached an error I am getting on a client's server. Has anyone encountered such before? Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang * *Blog: http://www.kipsang.com/ * *E-mail:* *main at kipsang.com
* *---* From jhellenthal at dataix.net Tue Apr 4 12:02:02 2017 From: jhellenthal at dataix.net (J. Hellenthal) Date: Tue, 4 Apr 2017 07:02:02 -0500 Subject: Microsoft Exchange Error... In-Reply-To: References: Message-ID: NAMOG ? ? -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Apr 4, 2017, at 06:00, Michael Bullut
wrote: Greetings Team, Please find attached an error I am getting on a client's server. Has anyone encountered such before? Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang * *Blog: http://www.kipsang.com/ * *E-mail:* *main at kipsang.com
* *---* From mmata at intercom.com.sv Mon Apr 3 22:46:30 2017 From: mmata at intercom.com.sv (Miguel Mata) Date: Mon, 03 Apr 2017 16:46:30 -0600 Subject: did facebook just DoS me? Message-ID: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Guys and gals, just received a DoS from supposedly Facebook. Any contact of way of getting in touch with them? Thanks. From Rich.Compton at charter.com Tue Apr 4 16:35:19 2017 From: Rich.Compton at charter.com (Compton, Rich A) Date: Tue, 4 Apr 2017 16:35:19 +0000 Subject: did facebook just DoS me? In-Reply-To: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: Any proof that you can provide that Facebook did indeed DoS you? Unless it is an attack after a tcp 3-way handshake I highly doubt that it was actually Facebook and probably an attacker spoofing Facebook?s source IPs (perhaps in hopes that the source IPs would be on your whitelist and not be blocked). Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112 On 4/3/17, 4:46 PM, "NANOG on behalf of Miguel Mata" wrote: >Guys and gals, > >just received a DoS from supposedly Facebook. Any contact of way of >getting in touch with >them? > >Thanks. > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From damian at google.com Tue Apr 4 19:04:20 2017 From: damian at google.com (Damian Menscher) Date: Tue, 4 Apr 2017 12:04:20 -0700 Subject: did facebook just DoS me? In-Reply-To: References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: It might have been even more innocent than that. There are some really crappy consumer-grade firewalls out there that say "DoS Attack" any time they receive an unexpected packet. This most commonly occurs when the device reboots (power outage) and a live TCP connection sends a keepalive or a RST. The end result is a flood of emails from customers to the abuse@ address of every major web company. I'd love to track down the manufacturers of these devices and get them to stop their fearmongering.... Damian On Tue, Apr 4, 2017 at 9:35 AM, Compton, Rich A wrote: > Any proof that you can provide that Facebook did indeed DoS you? Unless > it is an attack after a tcp 3-way handshake I highly doubt that it was > actually Facebook and probably an attacker spoofing Facebook?s source IPs > (perhaps in hopes that the source IPs would be on your whitelist and not > be blocked). > > Rich Compton | Principal Eng | 314.596.2828 > 14810 Grasslands Dr, Englewood, CO 80112 > > > > > > > On 4/3/17, 4:46 PM, "NANOG on behalf of Miguel Mata" > wrote: > > >Guys and gals, > > > >just received a DoS from supposedly Facebook. Any contact of way of > >getting in touch with > >them? > > > >Thanks. > > > > > > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > > From rod.beck at unitedcablecompany.com Tue Apr 4 21:30:02 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 4 Apr 2017 21:30:02 +0000 Subject: 350 East Main, Buffalo Message-ID: Hi, I am helping a carrier on a new fiber build. Trying to determine where to collocate in this building. There is no central meet-me room, but instead there are three 'gangs' - landlord and two major colo providers. [?] Any insight on the best provider in this facility would be appreciated. We want to minimize cross connect charges and delays and avoid being taken hostage. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Kir?ly utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221429846_image002.jpg][1467221477350_image005.png] From listas at kurtkraut.net Wed Apr 5 00:47:23 2017 From: listas at kurtkraut.net (Kurt Kraut) Date: Tue, 4 Apr 2017 21:47:23 -0300 Subject: did facebook just DoS me? In-Reply-To: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: Hello Mr. Mata, I'd like to register you might not be the only one. At work, I deal with DDoS on a daily basis. A pretty common UDP DDoS attack was hiting random IPs of our autonomous system and I applied a bunch of rules to block it. There rule had exceptions for content providers with high demand, like Google, Facebook and Akamai. For my surprise, after I applied my DROP rules, there was still a significant amount of traffic reaching the target servers. I perform some PCAPs I many IP addresses belonged to Facebook. At first I thought: - 'Clever attacker. He guesses I could not be as severe as I am to regular UDP traffic if the origin was Facebook and he deliberately spoofed their IP address.' But one of my collegues quickly realized the incoming MAC ADDRESS was the actual Facebook router we have a peering at a internet exchange. So indeed the traffic came from their network. The UDP source IP address is not enough to drag to this conclusion, but the MAC ADDRESS was very convincing to me. Best regards, Kurt Kraut 2017-04-03 19:46 GMT-03:00 Miguel Mata : > Guys and gals, > > just received a DoS from supposedly Facebook. Any contact of way of > getting in touch with > them? > > Thanks. > > > From morrowc.lists at gmail.com Wed Apr 5 00:58:43 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Apr 2017 18:58:43 -0600 Subject: did facebook just DoS me? In-Reply-To: References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: On Tue, Apr 4, 2017 at 6:47 PM, Kurt Kraut wrote: > > I perform some PCAPs I many IP addresses belonged to Facebook. At first I > thought: - 'Clever attacker. He guesses I could not be as severe as I am to > regular UDP traffic if the origin was Facebook and he deliberately spoofed > their IP address.' > > But one of my collegues quickly realized the incoming MAC ADDRESS was the > actual Facebook router we have a peering at a internet exchange. So indeed > the traffic came from their network. > one wonders if this is the new (ish?) Streaming thingy they launched? From listas at kurtkraut.net Wed Apr 5 01:03:07 2017 From: listas at kurtkraut.net (Kurt Kraut) Date: Tue, 4 Apr 2017 22:03:07 -0300 Subject: did facebook just DoS me? In-Reply-To: References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: Hello Christopher, I hardly belive it. IP addresses not allocated to servers were receiving attack, a whole /22 was attacked and it was solely used for servers (including IP addresses not allocated to devices), not for computers with user interface or mobile devices that could actually use Facebook. And if I recall it correctly, it was SSDP amplification attack. Best regards, Kurt Kraut 2017-04-04 21:58 GMT-03:00 Christopher Morrow : > > > On Tue, Apr 4, 2017 at 6:47 PM, Kurt Kraut wrote: > >> >> I perform some PCAPs I many IP addresses belonged to Facebook. At first I >> thought: - 'Clever attacker. He guesses I could not be as severe as I am >> to >> regular UDP traffic if the origin was Facebook and he deliberately spoofed >> their IP address.' >> >> But one of my collegues quickly realized the incoming MAC ADDRESS was the >> actual Facebook router we have a peering at a internet exchange. So indeed >> the traffic came from their network. >> > > one wonders if this is the new (ish?) Streaming thingy they launched? > From morrowc.lists at gmail.com Wed Apr 5 01:15:19 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Apr 2017 19:15:19 -0600 Subject: did facebook just DoS me? In-Reply-To: References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: On Tue, Apr 4, 2017 at 7:03 PM, Kurt Kraut wrote: > Hello Christopher, > > > I hardly belive it. IP addresses not allocated to servers were receiving > attack, a whole /22 was attacked and it was solely used for servers > (including IP addresses not allocated to devices), not for computers with > user interface or mobile devices that could actually use Facebook. And if I > recall it correctly, it was SSDP amplification attack. > > oh so some mis-config in their network/policy and exploitation by other folks :( bummer. > > Best regards, > > > Kurt Kraut > > 2017-04-04 21:58 GMT-03:00 Christopher Morrow : > >> >> >> On Tue, Apr 4, 2017 at 6:47 PM, Kurt Kraut wrote: >> >>> >>> I perform some PCAPs I many IP addresses belonged to Facebook. At first I >>> thought: - 'Clever attacker. He guesses I could not be as severe as I am >>> to >>> regular UDP traffic if the origin was Facebook and he deliberately >>> spoofed >>> their IP address.' >>> >>> But one of my collegues quickly realized the incoming MAC ADDRESS was the >>> actual Facebook router we have a peering at a internet exchange. So >>> indeed >>> the traffic came from their network. >>> >> >> one wonders if this is the new (ish?) Streaming thingy they launched? >> > > From jhellenthal at dataix.net Wed Apr 5 01:20:38 2017 From: jhellenthal at dataix.net (J. Hellenthal) Date: Tue, 4 Apr 2017 20:20:38 -0500 Subject: did facebook just DoS me? In-Reply-To: References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: Exactly -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Apr 4, 2017, at 20:15, Christopher Morrow wrote: On Tue, Apr 4, 2017 at 7:03 PM, Kurt Kraut wrote: > Hello Christopher, > > > I hardly belive it. IP addresses not allocated to servers were receiving > attack, a whole /22 was attacked and it was solely used for servers > (including IP addresses not allocated to devices), not for computers with > user interface or mobile devices that could actually use Facebook. And if I > recall it correctly, it was SSDP amplification attack. > > oh so some mis-config in their network/policy and exploitation by other folks :( bummer. > > Best regards, > > > Kurt Kraut > > 2017-04-04 21:58 GMT-03:00 Christopher Morrow : > >> >> >>> On Tue, Apr 4, 2017 at 6:47 PM, Kurt Kraut wrote: >>> >>> >>> I perform some PCAPs I many IP addresses belonged to Facebook. At first I >>> thought: - 'Clever attacker. He guesses I could not be as severe as I am >>> to >>> regular UDP traffic if the origin was Facebook and he deliberately >>> spoofed >>> their IP address.' >>> >>> But one of my collegues quickly realized the incoming MAC ADDRESS was the >>> actual Facebook router we have a peering at a internet exchange. So >>> indeed >>> the traffic came from their network. >>> >> >> one wonders if this is the new (ish?) Streaming thingy they launched? >> > > From mpalmer at hezmatt.org Wed Apr 5 01:34:25 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 5 Apr 2017 11:34:25 +1000 Subject: did facebook just DoS me? In-Reply-To: References: <58E2D0C6.17552.49225C04@mmata.intercom.com.sv> Message-ID: <20170405013425.GA3281@hezmatt.org> On Tue, Apr 04, 2017 at 09:47:23PM -0300, Kurt Kraut wrote: > But one of my collegues quickly realized the incoming MAC ADDRESS was the > actual Facebook router we have a peering at a internet exchange. So indeed > the traffic came from their network. If you've got a bilateral peering session with Facebook, presumably you have some sort of technical contact there that you can reach out to and ask "WTF?". That would seem to be a good first step. - Matt From jhellenthal at dataix.net Wed Apr 5 14:32:34 2017 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 5 Apr 2017 09:32:34 -0500 Subject: [AS1299] Contact Request Message-ID: <20170405143234.7656978F3DF9@localhost> Could someone from AS1299 track down a the source of this problem. Feel free to contact me off list for phone number or otherwise. Thanks Routing from AS11427, AS209 & AS32201 to the IP address of 190.166.236.188 in the Dominican Republic (DO) seems to be dropping traffic at AS1299 to and from. I have a remote programmer that needs VPN access back to our corporate office in Wisconsin from that IP address. /TIA From Serg at Macomnet.net Wed Apr 5 17:36:51 2017 From: Serg at Macomnet.net (Serg Shubenkov) Date: Wed, 5 Apr 2017 20:36:51 +0300 (MSK) Subject: Incapsula.com/AS19551 contact? Message-ID: <20170405202732.I43518@dry.macomnet.ru> Hello all, If someone from Incapsula.com/AS19551 is lurking, could you contact me off-list? www.hotelbeds.com is not available from AS8470. # nmap -sT -p 443 client.hotelbeds.com Starting Nmap 7.40 ( https://nmap.org ) at 2017-04-05 20:33 MSK Nmap scan report for client.hotelbeds.com (192.230.96.244) Host is up (0.00044s latency). rDNS record for 192.230.96.244: 192.230.96.244.ip.incapdns.net PORT STATE SERVICE 443/tcp closed https Nmap done: 1 IP address (1 host up) scanned in 0.39 seconds # Thanks! - serg -- Serg Shubenkov, MAcomnet, Internet Dept. phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.NET icq uin: 101964103, Skype: serg.v.shubenkov From JNiec at nitelusa.com Wed Apr 5 18:08:53 2017 From: JNiec at nitelusa.com (Josh Niec) Date: Wed, 5 Apr 2017 18:08:53 +0000 Subject: Verizon Email RBL Whitelist Message-ID: <48A552C38960A446A309B29BB1BE5EF81B22F575@NI-MAIL02.nii.ads> If there is a Verizon Email Admin around, would you be able to contact me off-list about whitelisting a /24 network we have? We have tried going through the Verizon whitelist ISP form online, as well as contacting numerous groups at Verizon without any success over the past few months. Thanks, Josh C. Niec Network Engineer II 1101 W. Lake Street, 6th Floor | Chicago, IL 60607 jniec at nitelusa.com | www.nitelusa.com ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From ken at wemonitoremail.com Thu Apr 6 14:57:53 2017 From: ken at wemonitoremail.com (Ken O'Driscoll) Date: Thu, 06 Apr 2017 15:57:53 +0100 Subject: Verizon Email RBL Whitelist In-Reply-To: <48A552C38960A446A309B29BB1BE5EF81B22F575@NI-MAIL02.nii.ads> References: <48A552C38960A446A309B29BB1BE5EF81B22F575@NI-MAIL02.nii.ads> Message-ID: <1491490673.2468.12.camel@wemonitoremail.com> On Wed, 2017-04-05 at 18:08 +0000, Josh Niec wrote: > If there is a Verizon Email Admin around, would you be able to contact me > off-list about whitelisting a /24 network we have???We have tried going > through the Verizon whitelist ISP form online, as well as contacting > numerous groups at Verizon without any success over the past few months. > [...snip...] Hi Josh, The form's been broken for months. If you create an account on their forum (https://forums.verizon.com/t5/Verizon-net-Email/bd-p/emailissues) and raise your issue there, a support-rep will engage with you privately. Ken. --? Ken O'Driscoll / We Monitor Email t: +353 1 254 9400 | w: www.wemonitoremail.com From ahmed.dalaali at hrins.net Thu Apr 6 15:08:32 2017 From: ahmed.dalaali at hrins.net (Ahmed Munaf) Date: Thu, 6 Apr 2017 18:08:32 +0300 Subject: CGNAT Message-ID: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> Hi, Any recommendation regarding CGNAT appliance who try it and which brand is the best from his perspective! The throughput which I want to pass through the CGNAT is about 40Gbits and number of subscribers are about 40,000 subscribers. Regards, Ahmed From sh.vahabzadeh at gmail.com Thu Apr 6 15:56:49 2017 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Thu, 6 Apr 2017 15:56:49 +0000 (UTC) Subject: CGNAT In-Reply-To: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> Message-ID: Hello Ahmad,I am using F5 for CGNAT, right now 250K subscriber with 28Gbps bandwidth, I will double it with the second appliance easily soon.Its high performance and I like it.Any time Any QuestionThanks Ch, Shahab On Thu, Apr 6, 2017 at 7:41 PM +0430, "Ahmed Munaf" wrote: Hi, Any recommendation regarding CGNAT appliance who try it and which brand is the best from his perspective! The throughput which I want to pass through the CGNAT is about 40Gbits and number of subscribers are about 40,000 subscribers. Regards, Ahmed From morrowc.lists at gmail.com Thu Apr 6 19:11:20 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 6 Apr 2017 13:11:20 -0600 Subject: Verizon Email RBL Whitelist In-Reply-To: <1491490673.2468.12.camel@wemonitoremail.com> References: <48A552C38960A446A309B29BB1BE5EF81B22F575@NI-MAIL02.nii.ads> <1491490673.2468.12.camel@wemonitoremail.com> Message-ID: alternately, just tweet @verizonsupport .... On Thu, Apr 6, 2017 at 8:57 AM, Ken O'Driscoll via NANOG wrote: > On Wed, 2017-04-05 at 18:08 +0000, Josh Niec wrote: > > If there is a Verizon Email Admin around, would you be able to contact me > > off-list about whitelisting a /24 network we have? We have tried going > > through the Verizon whitelist ISP form online, as well as contacting > > numerous groups at Verizon without any success over the past few months. > > > [...snip...] > > Hi Josh, > > The form's been broken for months. If you create an account on their forum > (https://forums.verizon.com/t5/Verizon-net-Email/bd-p/emailissues) and > raise your issue there, a support-rep will engage with you privately. > > Ken. > > -- > Ken O'Driscoll / We Monitor Email > t: +353 1 254 9400 | w: www.wemonitoremail.com > > From aaron1 at gvtc.com Thu Apr 6 20:33:41 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 6 Apr 2017 15:33:41 -0500 Subject: CGNAT In-Reply-To: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> Message-ID: <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> Last year I evaluated Cisco ASR9006/VSM-500 and Juniper MX104/MS-MIC-16G in my lab. I went with MX104/MS-MIC-16G. I love it. I deployed (2) MX104's. Each MX104 has a single MX-MIC-16G card in it. I integrated this CGNAT with MPLS L3VPN's for NAT Inside vrf and NAT outside vrf. Both MX104's learn 0/0 route for outside and send a 0/0 route for inside to all the PE's that have DSLAMs connected to them. So each PE with DSL connected to it learns default route towards 2 equal cost MX104's. I could easily add a third MX104 to this modular architecture. I have 7,000 DSL broadband customers behind it. Peak time throughput is hitting up at 4 gbps... I see a little over 100,000 service flows (translations) at peak time I think each MX104 MS-MIC-16G can able about ~7 million translations and about 7 gbps of cgnat throughput... so I'm good. I have a /25 for each MX104 outside public address pool (so /24 total for both MX104's)... pretty sweet how I use /24 for ~7,000 customers :) I'll freeze this probably for DSL and not put anything else behind it. I want to leave well-enough alone. If I move forward with CGNAT'ing Cable Modem (~6,000 more subsrcibers) I'll probably roll-out (2) more MX104's with a new vrf for that... If I move forward with CGNAT'ing FTTH (~20,000 more subsrcibers) I'll probably roll-out (2) MX240/480/960 with MS-MPC... I feel I'd want/need something beefier for FTTH... - Aaron From goemon at sasami.anime.net Thu Apr 6 21:41:39 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 6 Apr 2017 14:41:39 -0700 (PDT) Subject: competent earthlink abuse contact please Message-ID: A competent earthlink abuse contact please? I am getting the runaround from people who are unable to read headers. -Dan From ken at wemonitoremail.com Thu Apr 6 22:00:29 2017 From: ken at wemonitoremail.com (Ken O'Driscoll) Date: Thu, 06 Apr 2017 23:00:29 +0100 Subject: competent earthlink abuse contact please In-Reply-To: References: Message-ID: <1491516029.25562.1.camel@wemonitoremail.com> On Thu, 2017-04-06 at 14:41 -0700, Dan Hollis wrote: > A competent earthlink abuse contact please? > > I am getting the runaround from people who are unable to read headers. > > -Dan Hi Dan, There's usually an Earthlink presence over at Mailop: https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop Ken. --? Ken O'Driscoll / We Monitor Email t: +353 1 254 9400 | w: www.wemonitoremail.com From aaron1 at gvtc.com Fri Apr 7 17:48:33 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 7 Apr 2017 12:48:33 -0500 Subject: CGNAT In-Reply-To: References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> Message-ID: <000201d2afc7$2d821c20$88865460$@gvtc.com> Thanks Rich, you bring up some good points. Yes it would seem that an attack aimed at a target IP address would in-fact now have a greater surface since that IP address is being used by many people. When we remotely-trigger-black-hole (RTBH) route an ip address (/32 host route) into a black hole to stop an attack.... you're right, now you've completed the ddos, not only for one customer, but hundreds or thousands that were using that public ip address through the NAT appliance. ...to which I've told my NOC to not act on any of the /24's-worth of address space the we use for NAT. Interestingly, the nature of NAT is that it doesn't allow in-bound traffic unless a previous out-bound packet had been sent from customer-side to internet-side and caused the NAT translation to be built.... therefore, an outside-initiated DDoS attack would be automatically blocked by a NAT boundary*. This would cause the DDoS to not go as far as it did in the non-nat scenario. ...so with cgnat you've caused your reach of DDoS to be shortened. ...but of course this doesn't cause the DDoS to not occur and to not reach the NAT boundary...the attack still arrives. You have to continue with other layers of security, defense and mitigation in other areas/layers of your network. - Aaron * (I guess unless they were able to guess-spoof the exact ip address and port number of an existing nat session, but then it would seem that they would only reach that same port-address-translated session destination...which I think would be a single ip address endpoint and port number) From maxtul at netassist.ua Fri Apr 7 17:59:42 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 7 Apr 2017 20:59:42 +0300 Subject: CGNAT In-Reply-To: <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> Message-ID: <58E7D38E.9000404@netassist.ua> BTW, does somebody check how implementing a native IPv6 decrease actual load of CGNAT? On 06.04.17 23:33, Aaron Gould wrote: > Last year I evaluated Cisco ASR9006/VSM-500 and Juniper MX104/MS-MIC-16G in > my lab. > > I went with MX104/MS-MIC-16G. I love it. > > I deployed (2) MX104's. Each MX104 has a single MX-MIC-16G card in it. I > integrated this CGNAT with MPLS L3VPN's for NAT Inside vrf and NAT outside > vrf. Both MX104's learn 0/0 route for outside and send a 0/0 route for > inside to all the PE's that have DSLAMs connected to them. So each PE with > DSL connected to it learns default route towards 2 equal cost MX104's. I > could easily add a third MX104 to this modular architecture. > > I have 7,000 DSL broadband customers behind it. Peak time throughput is > hitting up at 4 gbps... I see a little over 100,000 service flows > (translations) at peak time > > I think each MX104 MS-MIC-16G can able about ~7 million translations and > about 7 gbps of cgnat throughput... so I'm good. > > I have a /25 for each MX104 outside public address pool (so /24 total for > both MX104's)... pretty sweet how I use /24 for ~7,000 customers :) > > I'll freeze this probably for DSL and not put anything else behind it. I > want to leave well-enough alone. > > If I move forward with CGNAT'ing Cable Modem (~6,000 more subsrcibers) I'll > probably roll-out (2) more MX104's with a new vrf for that... > > If I move forward with CGNAT'ing FTTH (~20,000 more subsrcibers) I'll > probably roll-out (2) MX240/480/960 with MS-MPC... I feel I'd want/need > something beefier for FTTH... > > - Aaron > > > From cscora at apnic.net Fri Apr 7 18:02:49 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Apr 2017 04:02:49 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170407180249.46F42C44A1@thyme.apnic.net> 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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at 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 08 Apr, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 642751 Prefixes after maximum aggregation (per Origin AS): 250189 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 310009 Total ASes present in the Internet Routing Table: 56796 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49177 Origin ASes announcing only one prefix: 21797 Transit ASes present in the Internet Routing Table: 7619 Transit-only ASes present in the Internet Routing Table: 223 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 73 Numnber of instances of unregistered ASNs: 74 Number of 32-bit ASNs allocated by the RIRs: 18044 Number of 32-bit ASNs visible in the Routing Table: 14026 Prefixes from 32-bit ASNs in the Routing Table: 56775 Number of bogon 32-bit ASNs visible in the Routing Table: 43 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 412 Number of addresses announced to Internet: 2841742212 Equivalent to 169 /8s, 97 /16s and 139 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.5 Total number of prefixes smaller than registry allocations: 214349 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 175591 Total APNIC prefixes after maximum aggregation: 50325 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 174783 Unique aggregates announced from the APNIC address blocks: 72288 APNIC Region origin ASes present in the Internet Routing Table: 7988 APNIC Prefixes per ASN: 21.88 APNIC Region origin ASes announcing only one prefix: 2237 APNIC Region transit ASes present in the Internet Routing Table: 1126 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2828 Number of APNIC addresses announced to Internet: 762664324 Equivalent to 45 /8s, 117 /16s and 85 /24s APNIC AS Blocks 4608-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: 195706 Total ARIN prefixes after maximum aggregation: 93686 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 197959 Unique aggregates announced from the ARIN address blocks: 90655 ARIN Region origin ASes present in the Internet Routing Table: 17863 ARIN Prefixes per ASN: 11.08 ARIN Region origin ASes announcing only one prefix: 6643 ARIN Region transit ASes present in the Internet Routing Table: 1761 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 34 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1888 Number of ARIN addresses announced to Internet: 1108062880 Equivalent to 66 /8s, 11 /16s and 178 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 174069 Total RIPE prefixes after maximum aggregation: 84644 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 169509 Unique aggregates announced from the RIPE address blocks: 101592 RIPE Region origin ASes present in the Internet Routing Table: 23887 RIPE Prefixes per ASN: 7.10 RIPE Region origin ASes announcing only one prefix: 11040 RIPE Region transit ASes present in the Internet Routing Table: 3392 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5713 Number of RIPE addresses announced to Internet: 711008384 Equivalent to 42 /8s, 97 /16s and 32 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 80417 Total LACNIC prefixes after maximum aggregation: 17772 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 81622 Unique aggregates announced from the LACNIC address blocks: 38229 LACNIC Region origin ASes present in the Internet Routing Table: 5776 LACNIC Prefixes per ASN: 14.13 LACNIC Region origin ASes announcing only one prefix: 1555 LACNIC Region transit ASes present in the Internet Routing Table: 1050 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3296 Number of LACNIC addresses announced to Internet: 170352864 Equivalent to 10 /8s, 39 /16s and 96 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16861 Total AfriNIC prefixes after maximum aggregation: 3702 AfriNIC Deaggregation factor: 4.55 Prefixes being announced from the AfriNIC address blocks: 18466 Unique aggregates announced from the AfriNIC address blocks: 6885 AfriNIC Region origin ASes present in the Internet Routing Table: 1032 AfriNIC Prefixes per ASN: 17.89 AfriNIC Region origin ASes announcing only one prefix: 322 AfriNIC Region transit ASes present in the Internet Routing Table: 204 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 20 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 301 Number of AfriNIC addresses announced to Internet: 89177600 Equivalent to 5 /8s, 80 /16s and 190 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5569 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3774 391 265 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2991 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2760 11150 755 KIXS-AS-KR Korea Telecom, KR 9829 2732 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2195 8698 33 CMNET-GD Guangdong Mobile Communication 45899 2135 1372 112 VNPT-AS-VN VNPT Corp, VN 4755 2069 421 220 TATACOMM-AS TATA Communications formerl 9583 1573 121 541 SIFY-AS-IN Sify Limited, IN 4808 1568 1791 447 CHINA169-BJ China Unicom Beijing Provin Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3692 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3377 1333 83 SHAW - Shaw Communications Inc., CA 18566 2186 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1986 2107 404 CHARTER-NET-HKY-NC - Charter Communicat 209 1790 5067 637 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1760 3321 563 AMAZON-02 - Amazon.com, Inc., US 30036 1729 321 378 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1684 854 231 ITCDELTA - Earthlink, Inc., US 701 1571 10580 645 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS, SA 8551 3250 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2968 1071 2109 AKAMAI-ASN1, US 9121 2690 1691 17 TTNET, TR 34984 2009 328 385 TELLCOM-AS, TR 13188 1643 99 51 TRIOLAN, UA 12479 1542 1043 53 UNI2-AS, ES 12389 1378 1288 571 ROSTELECOM-AS, RU 9198 1323 352 23 KAZTELECOM-AS, KZ 6849 1252 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3541 546 149 Telmex Colombia S.A., CO 8151 2515 3393 551 Uninet S.A. de C.V., MX 11830 1820 369 57 Instituto Costarricense de Electricidad 7303 1555 1003 247 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1262 377 27 Telefonica del Peru S.A.A., PE 28573 1083 2294 182 CLARO S.A., BR 3816 1020 488 182 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 1001 280 35 Techtel LMDS Comunicaciones Interactiva 17072 940 118 407 TOTAL PLAY TELECOMUNICACIONES SA DE CV, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1267 399 42 LINKdotNET-AS, EG 36903 717 360 122 MT-MPLS, MA 37611 699 67 6 Afrihost, ZA 36992 622 1375 26 ETISALAT-MISR, EG 24835 497 722 14 RAYA-AS, EG 8452 450 1730 17 TE-AS TE-AS, EG 37492 399 318 73 ORANGE-, TN 29571 367 36 10 CITelecom-AS, CI 15399 343 35 7 WANANCHI-, KE 2018 288 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5569 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3774 391 265 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3692 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3541 546 149 Telmex Colombia S.A., CO 6327 3377 1333 83 SHAW - Shaw Communications Inc., CA 39891 3334 171 18 ALJAWWALSTC-AS, SA 8551 3250 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2991 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2968 1071 2109 AKAMAI-ASN1, US 4766 2760 11150 755 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3692 3540 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3774 3509 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3541 3392 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS, SA 6327 3377 3294 SHAW - Shaw Communications Inc., CA 8551 3250 3209 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2991 2919 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2690 2673 TTNET, TR 9829 2732 2192 BSNL-NIB National Internet Backbone, IN 9808 2195 2162 CMNET-GD Guangdong Mobile Communication Co.Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.142.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:281 /13:538 /14:1044 /15:1827 /16:13232 /17:7585 /18:13377 /19:24696 /20:38388 /21:41313 /22:75924 /23:63107 /24:359886 /25:558 /26:413 /27:297 /28:40 /29:25 /30:25 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3168 3377 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS, SA 22773 2859 3692 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2729 3250 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2079 2186 MEGAPATH5-US - MegaPath Corporation, US 9121 1906 2690 TTNET, TR 30036 1535 1729 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1461 3541 Telmex Colombia S.A., CO 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1368 1643 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1610 2:852 4:26 5:2437 6:34 8:1066 12:1822 13:108 14:1797 15:22 16:2 17:115 18:130 19:1 20:56 23:2200 24:1857 25:2 27:2379 31:1892 32:89 33:5 35:19 36:391 37:2547 38:1349 39:45 40:99 41:2956 42:466 43:1902 44:68 45:2497 46:2753 47:115 49:1177 50:967 51:18 52:802 54:360 55:6 56:4 57:41 58:1661 59:1020 60:387 61:1944 62:1522 63:1912 64:4580 65:2209 66:4534 67:2266 68:1191 69:3325 70:1305 71:568 72:2158 74:2631 75:404 76:427 77:1467 78:1659 79:2159 80:1368 81:1419 82:967 83:733 84:877 85:1792 86:489 87:1153 88:800 89:2050 90:168 91:6134 92:1028 93:2390 94:2344 95:2830 96:572 97:359 98:957 99:88 100:155 101:1258 103:14215 104:2817 105:171 106:499 107:1578 108:812 109:3351 110:1336 111:1736 112:1164 113:1351 114:1035 115:1805 116:1791 117:1687 118:2143 119:1585 120:967 121:1096 122:2196 123:1831 124:1538 125:1857 128:750 129:621 130:448 131:1413 132:520 133:190 134:616 135:219 136:516 137:431 138:1876 139:423 140:379 141:541 142:744 143:936 144:770 145:169 146:1029 147:667 148:1376 149:557 150:714 151:948 152:751 153:299 154:793 155:737 156:565 157:613 158:445 159:1458 160:567 161:748 162:2464 163:517 164:803 165:1166 166:387 167:1232 168:2612 169:770 170:3102 171:291 172:999 173:1822 174:809 175:733 176:1824 177:4011 178:2489 179:1129 180:2198 181:1855 182:2291 183:978 184:842 185:9264 186:3242 187:2172 188:2622 189:1782 190:8125 191:1264 192:9372 193:5784 194:4655 195:3846 196:2019 197:1271 198:5552 199:5871 200:7368 201:4131 202:10285 203:9829 204:4469 205:2759 206:3001 207:3120 208:3912 209:3958 210:3976 211:2113 212:2821 213:2473 214:862 215:66 216:5872 217:2059 218:828 219:605 220:1668 221:908 222:737 223:1167 End of report From swmike at swm.pp.se Fri Apr 7 18:03:54 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Apr 2017 20:03:54 +0200 (CEST) Subject: CGNAT In-Reply-To: <58E7D38E.9000404@netassist.ua> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> <58E7D38E.9000404@netassist.ua> Message-ID: On Fri, 7 Apr 2017, Max Tulyev wrote: > BTW, does somebody check how implementing a native IPv6 decrease actual > load of CGNAT? Reports are that 30-50% of traffic will be IPv6 when you enable dual stack. This would be traffic that will not traverse your CGNAT. -- Mikael Abrahamsson email: swmike at swm.pp.se From aaron1 at gvtc.com Fri Apr 7 18:11:23 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 7 Apr 2017 13:11:23 -0500 Subject: CGNAT In-Reply-To: <58E7D38E.9000404@netassist.ua> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> <58E7D38E.9000404@netassist.ua> Message-ID: <000401d2afca$5d9d9a30$18d8ce90$@gvtc.com> Thanks Max, I've thought about that and tested some ipv6 (6vpe, mpls l3vpn w/ipv6 dual stacked) in my network. In my CGNAT testing for my 7,000 dsl customers, I've already tested the inter-vrf route leaks that will be required for ipv6-flow-around to bypass the IPv4 CGNAT boundary.... so, I have tested dual stacking my dsl customers with v4/v6 and seen that the v4 does flow via cgnat and v6 does bypass nat. I could dig up some ios(xr)/junos inter-vrf route leak/policy configs if anyone could benefit from that. I'm actually anxious to get started on my ipv6 deployment in my dsl space... as you have eluded to Max, this would push out the life of my ipv4 cgnat juniper mx104/ms-mic-16g boundary since we would expect the ipv6 traffic to flow naturally to my internet pipes un-natted and thus relive the nat nodes. ...and as more and more ipv6 is adopted in the world, the nat44/napt cgnat boundary is less and less needed.... until ultimately, we are in a ipv6-only world. -Aaron From pshem.k at gmail.com Sat Apr 8 01:04:10 2017 From: pshem.k at gmail.com (Pshem Kowalczyk) Date: Sat, 08 Apr 2017 01:04:10 +0000 Subject: CGNAT In-Reply-To: References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> <58E7D38E.9000404@netassist.ua> Message-ID: I can confirm that percentage (at least with residential customer base). All big content providers and a number of CDNs will do IPv6 by default. One thing that will heavily affect this is the CPE equipment (which might not have IPv6 enabled or even be capable of it). kind regards Pshem On Sat, 8 Apr 2017 at 06:19 Mikael Abrahamsson wrote: > On Fri, 7 Apr 2017, Max Tulyev wrote: > > > BTW, does somebody check how implementing a native IPv6 decrease actual > > load of CGNAT? > > Reports are that 30-50% of traffic will be IPv6 when you enable dual > stack. This would be traffic that will not traverse your CGNAT. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From Rich.Compton at charter.com Thu Apr 6 20:48:39 2017 From: Rich.Compton at charter.com (Compton, Rich A) Date: Thu, 6 Apr 2017 20:48:39 +0000 Subject: CGNAT In-Reply-To: <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> Message-ID: Hi Aaron, thanks for the info. I?m curious what you or others do about DDoS attacks to CGNAT devices. It seems that a single attack could affect the thousands of customers that use those devices. Also, do you have issues detecting attacks vs. legitimate traffic when you have so much traffic destined to a small group of IPs? Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112 On 4/6/17, 2:33 PM, "NANOG on behalf of Aaron Gould" wrote: >Last year I evaluated Cisco ASR9006/VSM-500 and Juniper MX104/MS-MIC-16G >in >my lab. > >I went with MX104/MS-MIC-16G. I love it. > >I deployed (2) MX104's. Each MX104 has a single MX-MIC-16G card in it. I >integrated this CGNAT with MPLS L3VPN's for NAT Inside vrf and NAT outside >vrf. Both MX104's learn 0/0 route for outside and send a 0/0 route for >inside to all the PE's that have DSLAMs connected to them. So each PE >with >DSL connected to it learns default route towards 2 equal cost MX104's. I >could easily add a third MX104 to this modular architecture. > >I have 7,000 DSL broadband customers behind it. Peak time throughput is >hitting up at 4 gbps... I see a little over 100,000 service flows >(translations) at peak time > >I think each MX104 MS-MIC-16G can able about ~7 million translations and >about 7 gbps of cgnat throughput... so I'm good. > >I have a /25 for each MX104 outside public address pool (so /24 total for >both MX104's)... pretty sweet how I use /24 for ~7,000 customers :) > >I'll freeze this probably for DSL and not put anything else behind it. I >want to leave well-enough alone. > >If I move forward with CGNAT'ing Cable Modem (~6,000 more subsrcibers) >I'll >probably roll-out (2) more MX104's with a new vrf for that... > >If I move forward with CGNAT'ing FTTH (~20,000 more subsrcibers) I'll >probably roll-out (2) MX240/480/960 with MS-MPC... I feel I'd want/need >something beefier for FTTH... > >- Aaron > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From Anthony.Hunnicutt at windstream.com Fri Apr 7 12:36:39 2017 From: Anthony.Hunnicutt at windstream.com (Hunnicutt, Anthony) Date: Fri, 7 Apr 2017 12:36:39 +0000 Subject: competent earthlink abuse contact please In-Reply-To: References: Message-ID: <80D393F3-BE97-46FB-9673-22A9ECB70DE2@windstream.com> Dan, I?ll send you a message directly. I can get you in touch with someone. -- Anthony Hunnicutt Windstream On 4/6/17, 5:41 PM, "NANOG on behalf of Dan Hollis" wrote: A competent earthlink abuse contact please? I am getting the runaround from people who are unable to read headers. -Dan This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From bryn.sadler at essensys.tech Fri Apr 7 15:30:37 2017 From: bryn.sadler at essensys.tech (Bryn Sadler) Date: Fri, 7 Apr 2017 15:30:37 +0000 Subject: GoDaddy Contact Message-ID: <55E98BEF-2A41-41D2-93D4-7630BA32D654@essensys.co.uk> Hi, anyone on-list from GoDaddy that might be able to help out with an issue we?re seeing? If so please contact me off-list: bryn.sadler at essensys.tech Thanks, essensys Bryn Sadler Chief Technical Officer T: +44 (0) 20 3102 5254 | M: +44 (0) 7872 684 671 W: www.essensys.tech The Key Metrics for Workspace Success The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately by reply. Please consider the environment when reading this email and only print a copy if you think it's really necessary. essensys Ltd | Registered Office: Aldgate Tower, 2 Leman Street, London E1 8FA | Registration No. 05959557 ==++==++ From ed.lopez at corsa.com Fri Apr 7 18:13:33 2017 From: ed.lopez at corsa.com (Ed Lopez) Date: Fri, 7 Apr 2017 14:13:33 -0400 Subject: CGNAT In-Reply-To: <000201d2afc7$2d821c20$88865460$@gvtc.com> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> <000201d2afc7$2d821c20$88865460$@gvtc.com> Message-ID: A lot depends on the CGNAT features you are looking to support, some considerations: - Are you looking for port block allocation for bulk logging, where a given subscriber is given a block of source TCP/UDP ports on a translated IP address - How many translations and session rate are you looking to support - Do you require Port Control Protocol (PCP) support for inbound pinholing reservations? Do your subscribers support uPnP to PCP translation? - Are you looking to support RFC 6598 (carrier use of 100.64.0.0/10 for CGNAT)? - Are you looking to support DS-Lite (RFC 6333) or lw4o6 (RFC 7596)? Both have significantly different requirements relative to CGNAT (DS-Lite assumes translation of subscriber RFC 1918 addresses tracking their IPv6 address in the translation table, lw4o6 assumes translation from RFC 1918 to RFC 6598 at the subscriber/B4 prior to IPv6 encapsulation plus translation of RFC 6598 to public at the CGNAT/AFTR) Generally, I tend to recommend F5 BIG-IP from a CGNAT feature standpoint - Ed On Fri, Apr 7, 2017 at 1:48 PM, Aaron Gould wrote: > Thanks Rich, you bring up some good points. Yes it would seem that an > attack aimed at a target IP address would in-fact now have a greater > surface > since that IP address is being used by many people. When we > remotely-trigger-black-hole (RTBH) route an ip address (/32 host route) > into > a black hole to stop an attack.... you're right, now you've completed the > ddos, not only for one customer, but hundreds or thousands that were using > that public ip address through the NAT appliance. ...to which I've told my > NOC to not act on any of the /24's-worth of address space the we use for > NAT. > > Interestingly, the nature of NAT is that it doesn't allow in-bound traffic > unless a previous out-bound packet had been sent from customer-side to > internet-side and caused the NAT translation to be built.... therefore, an > outside-initiated DDoS attack would be automatically blocked by a NAT > boundary*. This would cause the DDoS to not go as far as it did in the > non-nat scenario. ...so with cgnat you've caused your reach of DDoS to be > shortened. ...but of course this doesn't cause the DDoS to not occur and > to > not reach the NAT boundary...the attack still arrives. You have to > continue > with other layers of security, defense and mitigation in other areas/layers > of your network. > > - Aaron > > * (I guess unless they were able to guess-spoof the exact ip address and > port number of an existing nat session, but then it would seem that they > would only reach that same port-address-translated session > destination...which I think would be a single ip address endpoint and port > number) > > > -- *Ed Lopez* | *Security Architect* ed.lopez at corsa.com |11 Hines Rd (suite 203) | Ottawa, Ontario K2K 2X1 Canada Mobile +1.703.220.0988 | www.corsa.com *Provide line-rate mitigation against DDoS attacks using the Corsa NSE7000 Series. * *Learn how to make your network better with Corsa Performance SDN . * *This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments and delete this message and any attachments immediately.* From arnold at nipper.de Mon Apr 10 08:21:01 2017 From: arnold at nipper.de (Arnold Nipper) Date: Mon, 10 Apr 2017 10:21:01 +0200 Subject: Call for presentations EPF12, 18th - 20th September, Lisbon sent to NANOG Message-ID: Dear all, AMS-IX, DE-CIX, LINX, Netnod are happy to host the 12th European Peering Forum (EPF) in Lisbon, Portugal from the 18th - 20st September 2017. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection and Peering Internet Governance and Regulatory TopicS * Economic and Product Trends * Peering/Interconnection Strategy * Interesting findings about peering * 100GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee . Please include: * Author's name and e-mail * Presentation title * Abstract * Slides (if available) * Time requested Deadlines ========= Presentation Abstract Deadline 17/07/2017 12:00 UTC Final Selection of Speakers 28/07/2017 Presentation Slides Submission Deadline 04/09/2017 12:00 UTC More information about the event and other activities around EPF12 may be found at https://peering-forum.eu/ Best regards, Arnold On behalf of the EPF hosts -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From nanog at radu-adrian.feurdean.net Mon Apr 10 10:11:32 2017 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Mon, 10 Apr 2017 12:11:32 +0200 Subject: CGNAT In-Reply-To: References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> <58E7D38E.9000404@netassist.ua> Message-ID: <1491819092.1272244.939792200.718098E5@webmail.messagingengine.com> On Fri, Apr 7, 2017, at 20:03, Mikael Abrahamsson wrote: > On Fri, 7 Apr 2017, Max Tulyev wrote: > > > BTW, does somebody check how implementing a native IPv6 decrease actual > > load of CGNAT? > > Reports are that 30-50% of traffic will be IPv6 when you enable dual > stack. This would be traffic that will not traverse your CGNAT. My data on customers supposed to be 100% dual-stack (unless they explicitely disable IPv6 on their side, which some of them do) says 25% on best days. It used to be up to 35% in late 2015. For reason unknown, it was going slightly down during 2016, with a sudden extra decrease in january this year. From achatz at forthnet.gr Mon Apr 10 12:20:35 2017 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Mon, 10 Apr 2017 15:20:35 +0300 Subject: CGNAT In-Reply-To: <1491819092.1272244.939792200.718098E5@webmail.messagingengine.com> References: <49162897-2AF1-4063-A381-C7A4572ABC28@hrins.net> <000001d2af15$14a94fa0$3dfbeee0$@gvtc.com> <58E7D38E.9000404@netassist.ua> <1491819092.1272244.939792200.718098E5@webmail.messagingengine.com> Message-ID: With a ~59% dual-stack percentage and a 8% ds-lite percentage (aka 67% of our subscriber base has IPv6), we get around 40% of IPv6 traffic. -- Tassos Radu-Adrian Feurdean wrote on 10/4/2017 1:11 ??: > On Fri, Apr 7, 2017, at 20:03, Mikael Abrahamsson wrote: >> On Fri, 7 Apr 2017, Max Tulyev wrote: >> >>> BTW, does somebody check how implementing a native IPv6 decrease actual >>> load of CGNAT? >> Reports are that 30-50% of traffic will be IPv6 when you enable dual >> stack. This would be traffic that will not traverse your CGNAT. > My data on customers supposed to be 100% dual-stack (unless they > explicitely disable IPv6 on their side, which some of them do) says 25% > on best days. It used to be up to 35% in late 2015. > For reason unknown, it was going slightly down during 2016, with a > sudden extra decrease in january this year. > From randy at psg.com Mon Apr 10 16:00:18 2017 From: randy at psg.com (Randy Bush) Date: Mon, 10 Apr 2017 09:00:18 -0700 Subject: G root pmtu? Message-ID: it seems that G root ops are blocking dns ops mail servers. the more i think about that the sicker i think some folk out there are. but anyway, anyone else seeing this kind of problem with g root? http://dnsviz.net/d/gn/dnssec/ whines gn/DS (alg 8, id 38486): No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2001:500:12::d0d, UDP_0_EDNS0_32768_4096) randy From nanog at ics-il.net Tue Apr 11 22:57:16 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 11 Apr 2017 17:57:16 -0500 (CDT) Subject: SLA Monitoring Message-ID: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> What do you guys use for monitoring of SLAs, be it an upstream or a downstream SLA? I know of a couple services, just looking to see who's doing what and how they like it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From jason at unlimitednet.us Wed Apr 12 12:35:54 2017 From: jason at unlimitednet.us (Jason Canady) Date: Wed, 12 Apr 2017 08:35:54 -0400 Subject: SLA Monitoring In-Reply-To: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> References: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> Message-ID: We use various tools for monitoring here. Pingdom for external monitoring, Observium for internal and SmokePing for internal/external. As far as Pingdom goes, we ended up paying for 3 years to lock in pricing because it keeps going up and the service doesn't improve, but it is useful. I need to find an alternative prior to the next renewal. -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure On 4/11/17 6:57 PM, Mike Hammett wrote: > What do you guys use for monitoring of SLAs, be it an upstream or a downstream SLA? I know of a couple services, just looking to see who's doing what and how they like it. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com From saku at ytti.fi Wed Apr 12 16:17:14 2017 From: saku at ytti.fi (Saku Ytti) Date: Wed, 12 Apr 2017 19:17:14 +0300 Subject: SLA Monitoring In-Reply-To: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> References: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> Message-ID: On 12 April 2017 at 01:57, Mike Hammett wrote: Hey, > What do you guys use for monitoring of SLAs, be it an upstream or a downstream SLA? I know of a couple services, just looking to see who's doing what and how they like it. It might be useful to understand what type of data are you expecting out. Bunch of kit out there Accedian, Creanord, Netrounds, JDSU, Exfo, Polystar... Personally for me important things are: a) full-mesh, any pop to any pop b) high resolution, I want to know at least down to 10ms (100pps * cos * pops - may not be trivial amount of traffic) c) multiple CoS for all paths d) ability to discriminate measurement by SPORT (to troubleshoot ECMP issues) e) 1us or better precision for 2way jitter, latency f) good API to configure, to get data out, to get alerts out g) verify that received data is same as send (to find out if network has mangled bits) - this is very rare feature for some reason 1us or better precision basically removes all virtualised setups, because SR-IOV does not provide access to HW timestamping today. So you'll need dedicated HW for it, and vast majority of these shops only offer HW timestamping in the the upper range of the products. Personally I like Creanord, in previous life I've worked with them and found them to be knowledgeable and reactive partner. They've recently released new small/affordable boxes with HW timestamping. But are lacking in some department, like no data validity checking today, and GUI creation of full-mesh measurement is quite a chore as you need to individually pick interfaces. Latter isn't so big deal for me, as I'd do it programmatically anyhow, but may be big deal to others. I know that both are on the table to be fixed. If precision and resolution are not important and you're happy to write your tooling to present the data and alert, you can probably get away with CSCO IP SLA and/or JNPR RPM. Coworker of mine has written very convenient and high performance IP SLA responder, so that you don't have to buy several expensive Cisco boxes just to respond to the queries - https://github.com/cmouse/ip-sla-responder -- ++ytti From alan at irisns.com Wed Apr 12 13:40:28 2017 From: alan at irisns.com (Alan Kemp) Date: Wed, 12 Apr 2017 15:40:28 +0200 Subject: SLA Monitoring In-Reply-To: References: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Mike, We have customers that use Cisco IPSLA or juniper RPM to the actual SLA test, then use an NMS system to collect and report on that data. So I suppose depending on what you mean by monitoring there are a few options. 1. Real time graphing collected via SNMP 2. Proactive alerting based on threshold configuration 3. Reporting on SLA based on contractual obligations. 4. Central provisioning of the individual tests. I?m a little biased as I work for a monitoring company, but if you let me know what you mean by monitoring I can try help out. regards Alan > On 12 Apr 2017, at 2:35 PM, Jason Canady wrote: > > We use various tools for monitoring here. Pingdom for external monitoring, Observium for internal and SmokePing for internal/external. > > As far as Pingdom goes, we ended up paying for 3 years to lock in pricing because it keeps going up and the service doesn't improve, but it is useful. I need to find an alternative prior to the next renewal. > > -- > > Jason Canady > Unlimited Net, LLC > Responsive, Reliable, Secure > > On 4/11/17 6:57 PM, Mike Hammett wrote: >> What do you guys use for monitoring of SLAs, be it an upstream or a downstream SLA? I know of a couple services, just looking to see who's doing what and how they like it. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com > -- Alan Kemp Support: 0861 IRISNS (474767) or +27 21140 IRIS (4747) Mobile: +27 83 257 5970 IRIS Network Systems From kevin.j.wright1.civ at mail.mil Wed Apr 12 14:39:29 2017 From: kevin.j.wright1.civ at mail.mil (Wright, Kevin J CIV DISA ISC (US)) Date: Wed, 12 Apr 2017 14:39:29 +0000 Subject: G root pmtu? Message-ID: <555676BCDFFF0E40891306F0FE41B75D8EDAFC62@UCOLHPTZ.easf.csd.disa.mil> ---- Randy Bush wrote: > it seems that G root ops are blocking dns ops mail > servers. the more i think about that the sicker i think > some folk out there are. > G-Root ops are not blocking dns ops mail servers. If anyone has issues reaching us, please let me know. Also, the G-Root ops are not sick. At least not in the way implied above. ;-) Cheers, Kevin Kevin Wright DoD NIC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5575 bytes Desc: not available URL: From mikec at callagy.org Wed Apr 12 01:46:59 2017 From: mikec at callagy.org (Mike Callagy) Date: Tue, 11 Apr 2017 18:46:59 -0700 Subject: Yahoo Geo Location Message-ID: Does anyone know who Yahoo uses for geo location? I've got a /23 that has moved and I'm unable to find anything definitive regarding Yahoo. I'm already working with Maxmind and Google but Yahoo is the outlier. Thanks in advance, Mike. From nanog2011 at yahoo.com Wed Apr 12 02:07:58 2017 From: nanog2011 at yahoo.com (T Kawasaki) Date: Wed, 12 Apr 2017 02:07:58 +0000 (UTC) Subject: DNS issue on mme.gov.br References: <530809663.98594.1491962878348.ref@mail.yahoo.com> Message-ID: <530809663.98594.1491962878348@mail.yahoo.com> Any administrator for mme.gov.br there?if so, please contact me off line. We are having DNS resolution issue from some of our data centers. email address: tkawasa at us.ibm.com or tatsuyak at gmail.com. Tatsuya From ESundberg at nitelusa.com Thu Apr 13 21:37:07 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Thu, 13 Apr 2017 21:37:07 +0000 Subject: 10G MetroE 1-2U Switch Message-ID: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Hey Nanog, Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. Requirements MEF compliant 1-2U small foot print 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI Cost effect 10G Ports 100G Not required Looking at the ASR920's - Great box for 1G but not enough 10G Ports Only 4 NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. Any other platforms I should be looking at? Ciena, Brocade, Juniper? Thanks in advance! -Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From colton.conor at gmail.com Thu Apr 13 21:44:19 2017 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 13 Apr 2017 16:44:19 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: I looked at all three of these solutions, and ended up going with the Juniper ACX5048. Similar hardware wise to the NCS as it has the Broadcom chipset, but much more feature rich than Cisco. On Thu, Apr 13, 2017 at 4:37 PM, Erik Sundberg wrote: > Hey Nanog, > > Looking for a new metroE Edge switch that has more that 10x 10G ports. I > am having a hard time finding anything worthwhile without buying a full > blown ASR9K Chassis or another vendor's chassis. > > Requirements > MEF compliant > 1-2U small foot print > 10G Ports will be used for ENNI's and UNI Ports > Prefer MPLS support for L2VPN's (EoMPLS and VPLS) > QOS per Sub interface\vlan on a ENNI > Cost effect 10G Ports > 100G Not required > > > Looking at the > ASR920's - Great box for 1G but not enough 10G Ports Only 4 > NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS > issues :/ > ASR900 - Looks good, but was hoping for a smaller foot print. If I > remember right the 8x10G Cards can't go in every slot. > > Any other platforms I should be looking at? > > Ciena, Brocade, Juniper? > > > > Thanks in advance! > > -Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From valdis.kletnieks at vt.edu Thu Apr 13 21:54:01 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 13 Apr 2017 17:54:01 -0400 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: <46658.1492120441@turing-police.cc.vt.edu> On Thu, 13 Apr 2017 21:37:07 -0000, Erik Sundberg said: > Looking for a new metroE Edge switch that has more that 10x 10G ports. > 100G Not required Did you mean that downlink 100G is not needed (but needed on the uplink side), or are you planning to use a 40G as an uplink, or are you positive enough that you'll never get a 10G burst on multiple ports to need more than 10G uplink? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From kvicknair at reservetele.com Thu Apr 13 21:59:22 2017 From: kvicknair at reservetele.com (Kody Vicknair) Date: Thu, 13 Apr 2017 21:59:22 +0000 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: <3979AE529B56AB47942E2423B707F16E64BF4A57@RTC-EXCH01.RESERVE.LDS> Have you taken a look at the Juniper QFX series? I use these for video multicast and I'm not 100% sure they have support for all the features you've requested, BUT I do know of a competitor that uses them for cheap 10G VPLS deployment. It might be worth looking into. If you need a Juniper engineer to bounce your questions off of, I know a guy... I'd start here: http://www.juniper.net/us/en/products-services/switching/qfx-series/qfx5100/ Kody Vicknair Network Engineer Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces+kvicknair=reservetele.com at nanog.org] On Behalf Of Erik Sundberg Sent: Thursday, April 13, 2017 4:37 PM To: nanog at nanog.org Subject: 10G MetroE 1-2U Switch Hey Nanog, Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. Requirements MEF compliant 1-2U small foot print 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI Cost effect 10G Ports 100G Not required Looking at the ASR920's - Great box for 1G but not enough 10G Ports Only 4 NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. Any other platforms I should be looking at? Ciena, Brocade, Juniper? Thanks in advance! -Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From holbor at sonss.net Thu Apr 13 22:09:55 2017 From: holbor at sonss.net (Richard Holbo) Date: Thu, 13 Apr 2017 15:09:55 -0700 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: I have used several of these Huawei S6700 switches with no issues, fast easy to configure and support pretty much everything you mention. http://e.huawei.com/en/marketing-material/global/products/enterprise_network/switches/s6700/HUAWEI%20S6700%20Series%2010%20GE%20Switch%20Data%20Sheet /rh On Thu, Apr 13, 2017 at 2:37 PM, Erik Sundberg wrote: > Hey Nanog, > > Looking for a new metroE Edge switch that has more that 10x 10G ports. I > am having a hard time finding anything worthwhile without buying a full > blown ASR9K Chassis or another vendor's chassis. > > Requirements > MEF compliant > 1-2U small foot print > 10G Ports will be used for ENNI's and UNI Ports > Prefer MPLS support for L2VPN's (EoMPLS and VPLS) > QOS per Sub interface\vlan on a ENNI > Cost effect 10G Ports > 100G Not required > > > Looking at the > ASR920's - Great box for 1G but not enough 10G Ports Only 4 > NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS > issues :/ > ASR900 - Looks good, but was hoping for a smaller foot print. If I > remember right the 8x10G Cards can't go in every slot. > > Any other platforms I should be looking at? > > Ciena, Brocade, Juniper? > > > > Thanks in advance! > > -Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From dhubbard at dino.hostasaurus.com Thu Apr 13 22:12:19 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 13 Apr 2017 22:12:19 +0000 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: <4284CEBB-8767-42A3-962A-C56D07224204@dino.hostasaurus.com> Would Arista 7280R work? Gets you 48+ 10gig and a couple QSFP ports even in the cheapest model. I believe it has the features you want. Haven?t done MPLS with it, but I?ve got some running OSPF/OSPFv3 with no issues. On 4/13/17, 5:37 PM, "NANOG on behalf of Erik Sundberg" wrote: Hey Nanog, Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. Requirements MEF compliant 1-2U small foot print 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI Cost effect 10G Ports 100G Not required Looking at the ASR920's - Great box for 1G but not enough 10G Ports Only 4 NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. Any other platforms I should be looking at? Ciena, Brocade, Juniper? Thanks in advance! -Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From rjacobs at pslightwave.com Thu Apr 13 22:16:42 2017 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Thu, 13 Apr 2017 22:16:42 +0000 Subject: 10G MetroE 1-2U Switch In-Reply-To: References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads>, Message-ID: Ciena 5160. 24 port sfp+. 1u D.C. Or ac dual PSU. MEF certified. Price points good Get Outlook for iOS ________________________________ From: NANOG on behalf of Richard Holbo Sent: Thursday, April 13, 2017 5:09:55 PM To: Erik Sundberg Cc: nanog at nanog.org Subject: Re: 10G MetroE 1-2U Switch I have used several of these Huawei S6700 switches with no issues, fast easy to configure and support pretty much everything you mention. http://e.huawei.com/en/marketing-material/global/products/enterprise_network/switches/s6700/HUAWEI%20S6700%20Series%2010%20GE%20Switch%20Data%20Sheet /rh On Thu, Apr 13, 2017 at 2:37 PM, Erik Sundberg wrote: > Hey Nanog, > > Looking for a new metroE Edge switch that has more that 10x 10G ports. I > am having a hard time finding anything worthwhile without buying a full > blown ASR9K Chassis or another vendor's chassis. > > Requirements > MEF compliant > 1-2U small foot print > 10G Ports will be used for ENNI's and UNI Ports > Prefer MPLS support for L2VPN's (EoMPLS and VPLS) > QOS per Sub interface\vlan on a ENNI > Cost effect 10G Ports > 100G Not required > > > Looking at the > ASR920's - Great box for 1G but not enough 10G Ports Only 4 > NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS > issues :/ > ASR900 - Looks good, but was hoping for a smaller foot print. If I > remember right the 8x10G Cards can't go in every slot. > > Any other platforms I should be looking at? > > Ciena, Brocade, Juniper? > > > > Thanks in advance! > > -Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From aaron1 at gvtc.com Thu Apr 13 22:41:29 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 13 Apr 2017 17:41:29 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: <000d01d2b4a7$182d8460$48888d20$@gvtc.com> Hi Eric, A year or 2 ago, I did a good bit of work looking at various MPLS-capable-PE boxes as I was looking to replace the investment of Cisco ME3600's that couldn't keep up the pace of our FTTH 10 gig link expansions... that ME3600 only had (2) 10 gig ports. Several links below are just a quick search I did on google to find some of this topics/discussions from the community. https://www.juniper.net/assets/kr/kr/local/pdf/case-studies/3520578-en.pdf https://lists.gt.net/nsp/juniper/54965 https://www.mail-archive.com/juniper-nsp at puck.nether.net/msg23974.html https://marc.info/?l=cisco-nsp&m=148839385119158&w=3 https://marc.info/?a=133372064700006&r=1&w=3 https://marc.info/?a=148839164700003&r=1&w=3 https://lists.gt.net/nsp/juniper/58182 https://puck.nether.net/pipermail/juniper-nsp/2015-October/031353.html https://lists.gt.net/nsp/juniper/58241 -----Original Message----- From: NANOG [mailto:nanog-bounces+aaron1=gvtc.com at nanog.org] On Behalf Of Erik Sundberg Sent: Thursday, April 13, 2017 4:37 PM To: nanog at nanog.org Subject: 10G MetroE 1-2U Switch Hey Nanog, Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. Requirements MEF compliant 1-2U small foot print 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI Cost effect 10G Ports 100G Not required Looking at the ASR920's - Great box for 1G but not enough 10G Ports Only 4 NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. Any other platforms I should be looking at? Ciena, Brocade, Juniper? Thanks in advance! -Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From aaron1 at gvtc.com Thu Apr 13 22:42:58 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 13 Apr 2017 17:42:58 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: <001501d2b4a7$4d095100$e71bf300$@gvtc.com> Yeah, I settled on the ACX5048 too. I've since replaced about (25) Cisco ME3600's with ACX5048's. I'm doing MPLS L2VPN's and L3VPN's on the ACX5048. It's pretty nice and stable. -Aaron From aaron1 at gvtc.com Thu Apr 13 22:46:45 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 13 Apr 2017 17:46:45 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <3979AE529B56AB47942E2423B707F16E64BF4A57@RTC-EXCH01.RESERVE.LDS> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <3979AE529B56AB47942E2423B707F16E64BF4A57@RTC-EXCH01.RESERVE.LDS> Message-ID: <001701d2b4a7$d4693b10$7d3bb130$@gvtc.com> I'm pretty sure that the Juniper QFX5100 and the Juniper ACX5048 are some box with different Junos and features allowed/disallowed...somehow. (lookup pictures on google and juniper.net... pretty sure identical box) As I recall, the QFX5100 has more data-center-type things like virtual chass/mc-lag and less MPLS-edge-agg... As I recall (actually know from deploying 25 of them now), the ACX5048 has more MPLS-edge-agg and less data-center-type things like virtual chass/mc-lag -Aaron From aaron1 at gvtc.com Thu Apr 13 22:47:49 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 13 Apr 2017 17:47:49 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads>, Message-ID: <001901d2b4a7$faa01920$efe04b60$@gvtc.com> Pretty sure I looked at the ciena 51xx and I found that it does not have mpls in it... pretty sure Erik needs mpls... -Aaron From ESundberg at nitelusa.com Fri Apr 14 00:10:57 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 14 Apr 2017 00:10:57 +0000 Subject: 10G MetroE 1-2U Switch In-Reply-To: <000d01d2b4a7$182d8460$48888d20$@gvtc.com> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <000d01d2b4a7$182d8460$48888d20$@gvtc.com> Message-ID: <495D0934DA46854A9CA758393724D590754A4F55@NI-MAIL02.nii.ads> Guys thanks for the feedback and direction. Some follow up to some of the questions\comments -MPLS support is preferreded. -Uplinks to the core would be LACP Bundles at Nx10G. The majority of the traffic on the customer facing 10G ENNI's will be 10-100M EVC's. We would configure 10G Port with 2G CIR on this device, just not full 10G UNI Ports they would be put on a different device. -MEF Required -Erik -----Original Message----- From: Aaron Gould [mailto:aaron1 at gvtc.com] Sent: Thursday, April 13, 2017 5:41 PM To: Erik Sundberg; nanog at nanog.org Subject: RE: 10G MetroE 1-2U Switch Hi Eric, A year or 2 ago, I did a good bit of work looking at various MPLS-capable-PE boxes as I was looking to replace the investment of Cisco ME3600's that couldn't keep up the pace of our FTTH 10 gig link expansions... that ME3600 only had (2) 10 gig ports. Several links below are just a quick search I did on google to find some of this topics/discussions from the community. https://www.juniper.net/assets/kr/kr/local/pdf/case-studies/3520578-en.pdf https://lists.gt.net/nsp/juniper/54965 https://www.mail-archive.com/juniper-nsp at puck.nether.net/msg23974.html https://marc.info/?l=cisco-nsp&m=148839385119158&w=3 https://marc.info/?a=133372064700006&r=1&w=3 https://marc.info/?a=148839164700003&r=1&w=3 https://lists.gt.net/nsp/juniper/58182 https://puck.nether.net/pipermail/juniper-nsp/2015-October/031353.html https://lists.gt.net/nsp/juniper/58241 -----Original Message----- From: NANOG [mailto:nanog-bounces+aaron1=gvtc.com at nanog.org] On Behalf Of Erik Sundberg Sent: Thursday, April 13, 2017 4:37 PM To: nanog at nanog.org Subject: 10G MetroE 1-2U Switch Hey Nanog, Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. Requirements MEF compliant 1-2U small foot print 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI Cost effect 10G Ports 100G Not required Looking at the ASR920's - Great box for 1G but not enough 10G Ports Only 4 NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. Any other platforms I should be looking at? Ciena, Brocade, Juniper? Thanks in advance! -Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From mpetach at netflight.com Fri Apr 14 05:44:02 2017 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 13 Apr 2017 22:44:02 -0700 Subject: Yahoo Geo Location In-Reply-To: References: Message-ID: Hi hi, Sorry, a bit behind in my email, apologies for that. Ping me the /23 in private email and I'll see what we can do about it. Thanks! Matt On Tue, Apr 11, 2017 at 6:46 PM, Mike Callagy wrote: > Does anyone know who Yahoo uses for geo location? I've got a /23 that has > moved and I'm unable to find anything definitive regarding Yahoo. I'm > already working with Maxmind and Google but Yahoo is the outlier. > > Thanks in advance, > Mike. > From baldur.norddahl at gmail.com Fri Apr 14 10:02:28 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 14 Apr 2017 12:02:28 +0200 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: The ZTE ZXR10 5960 will do MPLS for about 3k USD: http://www.edgetech.lv/wp-content/uploads/2015/03/ZTE-ZXR10-5960-Series-All-10-Gigabit-Switch-Datasheet.pdf 24x 10G and 2x 40G We use them for L2VPN (VPLS). I have not done QOS on this hardware, so I can not say how well that works. Regards, Baldur Den 13/04/2017 kl. 23.37 skrev Erik Sundberg: > Hey Nanog, > > Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. > > Requirements > MEF compliant > 1-2U small foot print > 10G Ports will be used for ENNI's and UNI Ports > Prefer MPLS support for L2VPN's (EoMPLS and VPLS) > QOS per Sub interface\vlan on a ENNI > Cost effect 10G Ports > 100G Not required > > > Looking at the > ASR920's - Great box for 1G but not enough 10G Ports Only 4 > NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ > ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. > > Any other platforms I should be looking at? > > Ciena, Brocade, Juniper? > > > > Thanks in advance! > > -Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From aaron1 at gvtc.com Fri Apr 14 12:40:29 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 14 Apr 2017 07:40:29 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A4F55@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <000d01d2b4a7$182d8460$48888d20$@gvtc.com> <495D0934DA46854A9CA758393724D590754A4F55@NI-MAIL02.nii.ads> Message-ID: <000001d2b51c$4cb94e10$e62bea30$@gvtc.com> Yw Erik, also, since I'm fond/familiar with my newly deployed Juniper ACX5048's.... here's the MEF info...it's on there. https://www.mef.net/certification/equipment_details?company=001U0000007RJ6dI AG - Aaron From aaron1 at gvtc.com Fri Apr 14 12:45:58 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 14 Apr 2017 07:45:58 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: <000201d2b51d$10f0a0d0$32d1e270$@gvtc.com> Wow, 10 gig and 40 gig, mpls, etc, etc for $3,000 ?! Who is ZTE ? I usually try to stay with big names...Juniper, Cisco, etc... is ZTE well-known and reputable ? -Aaron From nanog at ics-il.net Fri Apr 14 12:53:01 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 14 Apr 2017 07:53:01 -0500 (CDT) Subject: 10G MetroE 1-2U Switch In-Reply-To: <000201d2b51d$10f0a0d0$32d1e270$@gvtc.com> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <000201d2b51d$10f0a0d0$32d1e270$@gvtc.com> Message-ID: <1721930352.10186.1492174376625.JavaMail.mhammett@ThunderFuck> https://en.wikipedia.org/wiki/ZTE Almost $12B in revenue in 2014, so not small. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Aaron Gould" To: "Baldur Norddahl" , nanog at nanog.org Sent: Friday, April 14, 2017 7:45:58 AM Subject: RE: 10G MetroE 1-2U Switch Wow, 10 gig and 40 gig, mpls, etc, etc for $3,000 ?! Who is ZTE ? I usually try to stay with big names...Juniper, Cisco, etc... is ZTE well-known and reputable ? -Aaron From dhubbard at dino.hostasaurus.com Fri Apr 14 13:51:13 2017 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 14 Apr 2017 13:51:13 +0000 Subject: Anyone using Arista 7280R as edge router? Message-ID: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Hey all, have some Brocade MLXe?s that can no longer handle a full v4 and v6 route table while also having VRF support (dumb CAM profile limitations in the software). Mine don?t do anything fancy; just BGP to a few upstream peers and OSPF/OSPFv3 to the inside, management VRF, some ACL?s. I?m looking at the ASR9001 with add-on ports since I need (10) 10gig. However, I?ve also been running some Arista 7280SE?s for the past 18 months with no issues, and they want me to consider their 7280R since it would give me more ports, in addition to some higher speed ports, which would be nice if I ever want to upgrade some of our peering to 40 or 100gig. Arista?s specs say the 7500R / 7280R can handle 1M ipv4+ipv6 routes in hardware (FIB): https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf In theory, it would last at least a few years if the v4 table doesn?t get too crazy between now and then. Curious if anyone has deployed a 7500R or 7280R in this role and what the feedback has been? The 9001?s 4M ?credits? for the combo of v4 +(2)v6 routes obviously goes much further, but I think either one would make it to their expected end of life, or if not on the Arista side, I?d probably have spent half as much. Thanks, David From ESundberg at nitelusa.com Fri Apr 14 15:30:01 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 14 Apr 2017 15:30:01 +0000 Subject: 10G MetroE 1-2U Switch In-Reply-To: <000001d2b51c$4cb94e10$e62bea30$@gvtc.com> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <000d01d2b4a7$182d8460$48888d20$@gvtc.com> <495D0934DA46854A9CA758393724D590754A4F55@NI-MAIL02.nii.ads> <000001d2b51c$4cb94e10$e62bea30$@gvtc.com> Message-ID: <495D0934DA46854A9CA758393724D590754A623E@NI-MAIL02.nii.ads> Aaron, Do you know if the ACS5048 has any QOS limitations on this platform? Is each EVC on a ENNI able to have a separate QOS policy or is it port based? Just wondering how it would compare to the Cisco NCS5001\NCS5501 Thanks Erik Erik Sundberg Sr. Network Engineering Network Engineering Department p: 773.661.5532 c: 708.710.7419 e: esundberg at nitelusa.com Main: 888.450.2100 NOC 24/7: 866.892.0915 350 North Orleans Street, Suite 1300N Chicago, IL 60654 www.nitelusa.com Managed Telecom Services MPLS | Ethernet | Private Line | Internet | Voice | Security -----Original Message----- From: Aaron Gould [mailto:aaron1 at gvtc.com] Sent: Friday, April 14, 2017 7:40 AM To: Erik Sundberg; nanog at nanog.org Subject: RE: 10G MetroE 1-2U Switch Yw Erik, also, since I'm fond/familiar with my newly deployed Juniper ACX5048's.... here's the MEF info...it's on there. https://www.mef.net/certification/equipment_details?company=001U0000007RJ6dI AG - Aaron ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From aaron1 at gvtc.com Fri Apr 14 16:17:43 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 14 Apr 2017 11:17:43 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <495D0934DA46854A9CA758393724D590754A623E@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <000d01d2b4a7$182d8460$48888d20$@gvtc.com> <495D0934DA46854A9CA758393724D590754A4F55@NI-MAIL02.nii.ads> <000001d2b51c$4cb94e10$e62bea30$@gvtc.com> <495D0934DA46854A9CA758393724D590754A623E@NI-MAIL02.nii.ads> Message-ID: <000401d2b53a$a5959520$f0c0bf60$@gvtc.com> Sorry Erik, I'm not well versed on the ACX5048 qos at the moment.....I'm just now undergoing a qos project which will require me to learn more about the gear in my network, to include the sub-rings of acx5048's. Perhaps check back with me in a while and I might know more. I am not handling my ENNI's on any acx5048's.... and I'm not policing any of my cell backhaul on acx5048's.... I put regulator's (Accedian's name for policers) on my MetroNID's which hang off the ACX5048's so I haven't had to do that. Again, sorry, I can't help with that at the moment. Hopefully others on the list can respond... or check the good ole Juniper NSP mail list... juniper-nsp at puck.nether.net Or check here... http://www.juniper.net/techpubs/en_US/junos/information-products/pathway-pag es/acx-series/index.html http://www.jnpr.net/techpubs/en_US/junos15.1x54-D60/information-products/pat hway-pages/acx-series/acx-series-151x54d60.pdf Class Of Service - Part 7 (page 775/2870) - Aaron From tyler at tgconrad.com Fri Apr 14 17:25:47 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Fri, 14 Apr 2017 10:25:47 -0700 Subject: Anyone using Arista 7280R as edge router? In-Reply-To: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> References: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Message-ID: I've deployed a 7280SR in that role. Needs the FLX model/license, and a special TCAM optimization command to install all the routes in hardware. Right now, just pulling a single v4 feed, expanding to a second soon; no v6 yet. Overall, no major issues with it, but Arista seems to be pretty close-lipped about the secret sauce in Flexroute that lets it scale over 1M. On Fri, Apr 14, 2017 at 6:51 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Hey all, have some Brocade MLXe?s that can no longer handle a full v4 and > v6 route table while also having VRF support (dumb CAM profile limitations > in the software). Mine don?t do anything fancy; just BGP to a few upstream > peers and OSPF/OSPFv3 to the inside, management VRF, some ACL?s. I?m > looking at the ASR9001 with add-on ports since I need (10) 10gig. However, > I?ve also been running some Arista 7280SE?s for the past 18 months with no > issues, and they want me to consider their 7280R since it would give me > more ports, in addition to some higher speed ports, which would be nice if > I ever want to upgrade some of our peering to 40 or 100gig. > > Arista?s specs say the 7500R / 7280R can handle 1M ipv4+ipv6 routes in > hardware (FIB): > > https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf > > In theory, it would last at least a few years if the v4 table doesn?t get > too crazy between now and then. > > Curious if anyone has deployed a 7500R or 7280R in this role and what the > feedback has been? > > The 9001?s 4M ?credits? for the combo of v4 +(2)v6 routes obviously goes > much further, but I think either one would make it to their expected end of > life, or if not on the Arista side, I?d probably have spent half as much. > > Thanks, > > David > From gdupin at taho.fr Fri Apr 14 12:59:56 2017 From: gdupin at taho.fr (Ge Dupin) Date: Fri, 14 Apr 2017 14:59:56 +0200 Subject: 10G MetroE 1-2U Switch In-Reply-To: <1721930352.10186.1492174376625.JavaMail.mhammett@ThunderFuck> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <000201d2b51d$10f0a0d0$32d1e270$@gvtc.com> <1721930352.10186.1492174376625.JavaMail.mhammett@ThunderFuck> Message-ID: <8D0E70A0-865C-4200-A0A8-D14B6BB51864@taho.fr> They are well known ! Are they reputable ? :) Regards Ge Dupin > Le 14 avr. 2017 ? 14:53, Mike Hammett a ?crit : > > https://en.wikipedia.org/wiki/ZTE > > Almost $12B in revenue in 2014, so not small. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Aaron Gould" > To: "Baldur Norddahl" , nanog at nanog.org > Sent: Friday, April 14, 2017 7:45:58 AM > Subject: RE: 10G MetroE 1-2U Switch > > Wow, 10 gig and 40 gig, mpls, etc, etc for $3,000 ?! Who is ZTE ? I > usually try to stay with big names...Juniper, Cisco, etc... is ZTE > well-known and reputable ? > > -Aaron > > > From kclapp at fairpoint.com Fri Apr 14 13:28:46 2017 From: kclapp at fairpoint.com (Clapp, Karl) Date: Fri, 14 Apr 2017 13:28:46 +0000 Subject: 10G MetroE 1-2U Switch In-Reply-To: References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> Message-ID: <7866529CA071BA42832083782418C788FC03D488@0NH1C2P10.fairpoint.com> Anyone has a ZTE sales contact in the US, specifically in the New England region? Seems like something I may want to look into.. Tired of SmartNet.. Regards.. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl Sent: Friday, April 14, 2017 6:02 AM To: nanog at nanog.org Subject: Re: 10G MetroE 1-2U Switch The ZTE ZXR10 5960 will do MPLS for about 3k USD: http://www.edgetech.lv/wp-content/uploads/2015/03/ZTE-ZXR10-5960-Series-All-10-Gigabit-Switch-Datasheet.pdf 24x 10G and 2x 40G We use them for L2VPN (VPLS). I have not done QOS on this hardware, so I can not say how well that works. Regards, Baldur Den 13/04/2017 kl. 23.37 skrev Erik Sundberg: > Hey Nanog, > > Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. > > Requirements > MEF compliant > 1-2U small foot print > 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support > for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI > Cost effect 10G Ports 100G Not required > > > Looking at the > ASR920's - Great box for 1G but not enough 10G Ports Only 4 > NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ > ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. > > Any other platforms I should be looking at? > > Ciena, Brocade, Juniper? > > > > Thanks in advance! > > -Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From tyler at tgconrad.com Fri Apr 14 18:17:23 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Fri, 14 Apr 2017 11:17:23 -0700 Subject: 10G MetroE 1-2U Switch In-Reply-To: <4284CEBB-8767-42A3-962A-C56D07224204@dino.hostasaurus.com> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <4284CEBB-8767-42A3-962A-C56D07224204@dino.hostasaurus.com> Message-ID: I'd avoid the 7280R for this. Works great as a P router for cheap, fast label switching, but their VRF implementation is lacking with both route-leaking and MP-BGP address family (other than standard ipv4+ipv6) support being nonexistent. On Thu, Apr 13, 2017 at 3:12 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Would Arista 7280R work? Gets you 48+ 10gig and a couple QSFP ports even > in the cheapest model. I believe it has the features you want. Haven?t > done MPLS with it, but I?ve got some running OSPF/OSPFv3 with no issues. > > On 4/13/17, 5:37 PM, "NANOG on behalf of Erik Sundberg" > ESundberg at nitelusa.com> wrote: > > Hey Nanog, > > Looking for a new metroE Edge switch that has more that 10x 10G ports. > I am having a hard time finding anything worthwhile without buying a full > blown ASR9K Chassis or another vendor's chassis. > > Requirements > MEF compliant > 1-2U small foot print > 10G Ports will be used for ENNI's and UNI Ports > Prefer MPLS support for L2VPN's (EoMPLS and VPLS) > QOS per Sub interface\vlan on a ENNI > Cost effect 10G Ports > 100G Not required > > > Looking at the > ASR920's - Great box for 1G but not enough 10G Ports Only 4 > NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & > QOS issues :/ > ASR900 - Looks good, but was hoping for a smaller foot print. If I > remember right the 8x10G Cards can't go in every slot. > > Any other platforms I should be looking at? > > Ciena, Brocade, Juniper? > > > > Thanks in advance! > > -Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > From jflowers at atlassian.com Fri Apr 14 19:15:23 2017 From: jflowers at atlassian.com (Joe Flowers) Date: Fri, 14 Apr 2017 12:15:23 -0700 Subject: SLA Monitoring In-Reply-To: References: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> Message-ID: LogicMonitor is an excellent all-inclusive SaaS solution: https://www.logicmonitor.com/ ? On Wed, Apr 12, 2017 at 6:40 AM, Alan Kemp wrote: > Hi Mike, > > We have customers that use Cisco IPSLA or juniper RPM to the actual SLA > test, then use an NMS system to collect and report on that data. > > So I suppose depending on what you mean by monitoring there are a few > options. > 1. Real time graphing collected via SNMP > 2. Proactive alerting based on threshold configuration > 3. Reporting on SLA based on contractual obligations. > 4. Central provisioning of the individual tests. > > I?m a little biased as I work for a monitoring company, but if you let me > know what you mean by monitoring I can try help out. > > regards > > Alan > > > On 12 Apr 2017, at 2:35 PM, Jason Canady wrote: > > > > We use various tools for monitoring here. Pingdom for external > monitoring, Observium for internal and SmokePing for internal/external. > > > > As far as Pingdom goes, we ended up paying for 3 years to lock in > pricing because it keeps going up and the service doesn't improve, but it > is useful. I need to find an alternative prior to the next renewal. > > > > -- > > > > Jason Canady > > Unlimited Net, LLC > > Responsive, Reliable, Secure > > > > On 4/11/17 6:57 PM, Mike Hammett wrote: > >> What do you guys use for monitoring of SLAs, be it an upstream or a > downstream SLA? I know of a couple services, just looking to see who's > doing what and how they like it. > >> > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest-IX > >> http://www.midwest-ix.com > > > > -- > Alan Kemp > Support: 0861 IRISNS (474767) or +27 21140 IRIS (4747) > Mobile: +27 83 257 5970 > IRIS Network Systems > > > > > > > -- Joe Flowers Systems Engineer 512.666.0611 jflowers at atlassian.com From tyler at tgconrad.com Fri Apr 14 19:27:06 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Fri, 14 Apr 2017 12:27:06 -0700 Subject: SLA Monitoring In-Reply-To: References: <959343859.6018.1491951432607.JavaMail.mhammett@ThunderFuck> Message-ID: Thousandeyes works well, but it's also really expensive. On Fri, Apr 14, 2017 at 12:15 PM, Joe Flowers wrote: > LogicMonitor is an excellent all-inclusive SaaS solution: > https://www.logicmonitor.com/ > ? > > On Wed, Apr 12, 2017 at 6:40 AM, Alan Kemp wrote: > > > Hi Mike, > > > > We have customers that use Cisco IPSLA or juniper RPM to the actual SLA > > test, then use an NMS system to collect and report on that data. > > > > So I suppose depending on what you mean by monitoring there are a few > > options. > > 1. Real time graphing collected via SNMP > > 2. Proactive alerting based on threshold configuration > > 3. Reporting on SLA based on contractual obligations. > > 4. Central provisioning of the individual tests. > > > > I?m a little biased as I work for a monitoring company, but if you let me > > know what you mean by monitoring I can try help out. > > > > regards > > > > Alan > > > > > On 12 Apr 2017, at 2:35 PM, Jason Canady > wrote: > > > > > > We use various tools for monitoring here. Pingdom for external > > monitoring, Observium for internal and SmokePing for internal/external. > > > > > > As far as Pingdom goes, we ended up paying for 3 years to lock in > > pricing because it keeps going up and the service doesn't improve, but it > > is useful. I need to find an alternative prior to the next renewal. > > > > > > -- > > > > > > Jason Canady > > > Unlimited Net, LLC > > > Responsive, Reliable, Secure > > > > > > On 4/11/17 6:57 PM, Mike Hammett wrote: > > >> What do you guys use for monitoring of SLAs, be it an upstream or a > > downstream SLA? I know of a couple services, just looking to see who's > > doing what and how they like it. > > >> > > >> > > >> > > >> > > >> ----- > > >> Mike Hammett > > >> Intelligent Computing Solutions > > >> http://www.ics-il.com > > >> > > >> Midwest-IX > > >> http://www.midwest-ix.com > > > > > > > -- > > Alan Kemp > > Support: 0861 IRISNS (474767) or +27 21140 IRIS (4747) > > Mobile: +27 83 257 5970 > > IRIS Network Systems > > > > > > > > > > > > > > > > > -- > Joe Flowers > > Systems Engineer > > 512.666.0611 > > jflowers at atlassian.com > > > > From bedard.phil at gmail.com Fri Apr 14 19:44:19 2017 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 14 Apr 2017 15:44:19 -0400 Subject: Anyone using Arista 7280R as edge router? In-Reply-To: References: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Message-ID: There isn?t really anything super special about it if you know about the memory space on the Jericho chipset and the LPM/EPM tables. Cisco is doing relatively the same things with their 5502 platform, it supports 1M FIB entries in the base memory model. Most of it banks on the fact the bulk of the table is made up of /24 prefixes, and where it doesn?t optimization techniques can be done to make them /24s. Thanks, Phil -----Original Message----- From: NANOG on behalf of Tyler Conrad Date: Friday, April 14, 2017 at 13:25 To: David Hubbard Cc: "nanog at nanog.org" Subject: Re: Anyone using Arista 7280R as edge router? I've deployed a 7280SR in that role. Needs the FLX model/license, and a special TCAM optimization command to install all the routes in hardware. Right now, just pulling a single v4 feed, expanding to a second soon; no v6 yet. Overall, no major issues with it, but Arista seems to be pretty close-lipped about the secret sauce in Flexroute that lets it scale over 1M. On Fri, Apr 14, 2017 at 6:51 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Hey all, have some Brocade MLXe?s that can no longer handle a full v4 and > v6 route table while also having VRF support (dumb CAM profile limitations > in the software). Mine don?t do anything fancy; just BGP to a few upstream > peers and OSPF/OSPFv3 to the inside, management VRF, some ACL?s. I?m > looking at the ASR9001 with add-on ports since I need (10) 10gig. However, > I?ve also been running some Arista 7280SE?s for the past 18 months with no > issues, and they want me to consider their 7280R since it would give me > more ports, in addition to some higher speed ports, which would be nice if > I ever want to upgrade some of our peering to 40 or 100gig. > > Arista?s specs say the 7500R / 7280R can handle 1M ipv4+ipv6 routes in > hardware (FIB): > > https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf > > In theory, it would last at least a few years if the v4 table doesn?t get > too crazy between now and then. > > Curious if anyone has deployed a 7500R or 7280R in this role and what the > feedback has been? > > The 9001?s 4M ?credits? for the combo of v4 +(2)v6 routes obviously goes > much further, but I think either one would make it to their expected end of > life, or if not on the Arista side, I?d probably have spent half as much. > > Thanks, > > David > From benno at NLnetLabs.nl Fri Apr 14 20:58:21 2017 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 14 Apr 2017 22:58:21 +0200 Subject: RIPE 74 call for late submissions, LTs, and one tutorial and BoF Message-ID: Dear colleagues, Brief version: The RIPE PC invites submissions for plenary, tutorial, BoF and Lightning Talks. Longer version: As distinct from previous RIPE meetings, the RIPE Programme Committee decided to keep two plenary slots open for so-called ?late submission?. These plenary slots gives the community the opportunity to submit presentations that report on recent developments, issues, security incidents, etc., that are relevant to the RIPE audience. Independent from the realisation of late submissions, the PC has received a fair amount of high-quality submissions for the first deadline on March 12th. From these submissions, we have selected 14 presentations to complete the RIPE 74 plenary programme and no second CFP with a deadline in April was required. For the tutorials and BoFs we have one slot for each available: - Monday morning, 2 hour tutorial slot - evening, 1 hour BoF slot Also please consider to submit Lightning Talks for the Monday plenary. During the week of the RIPE meeting we will accept LTs for Tuesday and Friday. Please submit your plenary ?late submission?, tutorial or BoF submission via the PC submission system, https://ripe74.ripe.net/submit-topic/submission-form/. The deadline for the submissions is *April 26th*. Kind regards, Benno Overeinder RIPE PC Chair https://ripe74.ripe.net/programme/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 74 will take place from 8-12 May 2017 in Budapest, Hungary. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 74. See the full descriptions of the different presentation formats, https://ripe74.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 26 April 2017. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe74.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. Allocation of lightning talks will start a few days before the meeting, and will continue throughout the meeting. During the meeting, they may be announced on the day before the talk or even on the same day as the talk. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From jk at ip-clear.de Sat Apr 15 00:51:15 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Sat, 15 Apr 2017 08:51:15 +0800 Subject: Anyone using Arista 7280R as edge router? In-Reply-To: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> References: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Message-ID: Hi, maybe biased but most obvious for the MLXE: Replace the MLXE linecard with a BR-MLX-10GX10-X2 (can be upgraded to 20 ports later) and run multi-service-6? J?rg On 14 Apr 2017, at 21:51, David Hubbard wrote: > Hey all, have some Brocade MLXe?s that can no longer handle a full > v4 and v6 route table while also having VRF support (dumb CAM profile > limitations in the software). Mine don?t do anything fancy; just > BGP to a few upstream peers and OSPF/OSPFv3 to the inside, management > VRF, some ACL?s. I?m looking at the ASR9001 with add-on ports > since I need (10) 10gig. However, I?ve also been running some > Arista 7280SE?s for the past 18 months with no issues, and they want > me to consider their 7280R since it would give me more ports, in > addition to some higher speed ports, which would be nice if I ever > want to upgrade some of our peering to 40 or 100gig. > From maxtul at netassist.ua Sun Apr 16 13:20:20 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Sun, 16 Apr 2017 16:20:20 +0300 Subject: Facebook more specific via Level3 ? In-Reply-To: <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> Message-ID: <58F36F94.3020402@netassist.ua> Hi, got the same from Kiev, Ukraine: dig fbcdn.com fbcdn.com. 300 IN A 31.13.74.1 which is slow and routed through USA and dig fbcdn.com @8.8.8.8 fbcdn.com. 299 IN A 31.13.93.3 which is fast and routed through Germany Same is for IPv6. Is there any solutions without dirty hacks? On 22.03.17 12:02, Radu-Adrian Feurdean wrote: > Hi, the load-balancing definitely doesn't choose the *nearest* mirror. > We are in France and unless we do dirty tricks, we *always* get directed > to US sites (as far as LA), with horrible performance. Everything since > end of December. As a consequence we let the dirty tricks in place > (query facebook.com and fbcdn.com on 8.8.8.8 instead of regular > recursive resolving) and we get directed to Frankfurt or Amsterdam > (never London or Paris). > From job at instituut.net Sun Apr 16 13:29:37 2017 From: job at instituut.net (Job Snijders) Date: Sun, 16 Apr 2017 15:29:37 +0200 Subject: Facebook more specific via Level3 ? In-Reply-To: <58F36F94.3020402@netassist.ua> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> <58F36F94.3020402@netassist.ua> Message-ID: <20170416132937.5m3vc6iou2b7y3mt@Vurt.local> On Sun, Apr 16, 2017 at 04:20:20PM +0300, Max Tulyev wrote: > got the same from Kiev, Ukraine: > > dig fbcdn.com > fbcdn.com. 300 IN A 31.13.74.1 > which is slow and routed through USA > > and > dig fbcdn.com @8.8.8.8 > fbcdn.com. 299 IN A 31.13.93.3 > which is fast and routed through Germany > > Same is for IPv6. > > Is there any solutions without dirty hacks? As mentioned in this thread, talk to the Facebook NOC: On Tue, Mar 21, 2017 at 05:41:23PM +0000, Doug Porter wrote: > > Please reach out to noc at fb.com in the future." > Kind regards, Job From rod.beck at unitedcablecompany.com Sun Apr 16 16:39:59 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Sun, 16 Apr 2017 16:39:59 +0000 Subject: John Van Oppen - Wave Broadband In-Reply-To: <20170416132937.5m3vc6iou2b7y3mt@Vurt.local> References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> <58F36F94.3020402@netassist.ua>,<20170416132937.5m3vc6iou2b7y3mt@Vurt.local> Message-ID: If John is on the list, please have him contact me. Thanks. Regards, Roderick. Sales Cross Lake SeaX-1 and SeaX-2 From karim.adel at gmail.com Sun Apr 16 20:13:59 2017 From: karim.adel at gmail.com (Kasper Adel) Date: Sun, 16 Apr 2017 13:13:59 -0700 Subject: SD-WAN for enlightened Message-ID: Hi, I'm not sure if the buzzword SD-WAN is used to compensate for another buzzword that got over-utilized (SDN) or it is a true 'new and improved' way of doing things that has some innovation into it. I heard different explanation from different vendors: 1) appliances (+ controller) placed in-line to put traffic in tunnels based on policy, with some DPI and traffic tagging...(to do performance/policy based routing) over an expensive link (MPLS) and a cheap one (broadband) with some 'firewall-like' filtering capabilities. 2) same as above, with a flavor of 'machine learning' to find a pattern for traffic to optimize utilization. 3) a controller that instantiates and tears down tunnels from 'classic routers' based on external policies and Network based features to do performance based routing over an expensive link (MPLS) and a cheap one (broadband) with encryption. Is the above a decent high-level summary? Has anyone tried any of these solutions, any general feedback ? Cheers, Kim From mehmet at akcin.net Mon Apr 17 11:52:30 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 17 Apr 2017 11:52:30 +0000 Subject: Interconnection Track In-Reply-To: References: Message-ID: Thank you very much for sending privately and publicly an overwhelming number of suggestions. I do appreciate you taking time and writing things up in detail. I am doing my best with help of Greg H from PC to put these thoughts on paper. It looks like there is a great interest to make this track focusing on tooling and automation as well as introductions of new game changing ixps. I would like to invite all new IXPs to come and talk about what they offer (ie denver-ix) I also would like to invite any existing IXPs to announce price discounts to their services. This is the only update we will have time in this interconnection track. Unfortunately no graphs, other updates. Few questions, Seattle is beautiful in summer and I hope to have many of you in person in beautiful washington state, but for those who can't travel, should we record / live stream this session? (Historically we did keep peering track off the grid... i believe) Would it be interesting to focus on peering challenges globally or strictly focus on north america? Last but not least, If you have a tool you want to talk about in interconnection track that is directly involved with peering setup, etc. please do contact me offlist. Cheers! Looking forward to it. On Sat, Apr 1, 2017 at 1:36 PM Mehmet Akcin wrote: > Hello, > > As promised few months ago publically I have volunteered to bring together > content to have Peering Track back to agenda. Now called "Interconnection > Track" > > I would like to ask those who will attend, have attended in person in the > past or those who have organized similar events to chime in and help > suggest topics to cover in this 90 min session. > > I must say, Interconnection Track has been a major part if NANOG for many > years. We have watched those who we consider as legends to discuss very > important topics there. > > Please try to make your suggestion in order of importance for you as well > as from community. > > I can try to do my best with help of few folks to bring this track back > but you can help make it even better so please take a moment and send me > your suggestions. > > Thanks in advance! > > Mehmet > From bevan at slattery.net.au Mon Apr 17 13:03:36 2017 From: bevan at slattery.net.au (Bevan Slattery) Date: Mon, 17 Apr 2017 23:03:36 +1000 Subject: Interconnection Track In-Reply-To: References: Message-ID: Hi! Love the interconnection track. Great stuff. But I can't help but think limiting interconnection to the peering/IXP view seems to be looking at interconnection from the rear view mirror. I just think that changing the track name from peering/IXP to "Interconnection" has the optionality to be a bit more looking forward. Interconnection in the network world is becoming more sophisticated and important than just old school peering (hearing the gasps of horror from the Nanog peering cabal at that statement) ;) Cheers [b] > On 17 Apr 2017, at 9:52 pm, Mehmet Akcin wrote: > > Thank you very much for sending privately and publicly an overwhelming > number of suggestions. I do appreciate you taking time and writing things > up in detail. I am doing my best with help of Greg H from PC to put these > thoughts on paper. > > It looks like there is a great interest to make this track focusing on > tooling and automation as well as introductions of new game changing ixps. > > I would like to invite all new IXPs to come and talk about what they offer > (ie denver-ix) > > I also would like to invite any existing IXPs to announce price discounts > to their services. This is the only update we will have time in this > interconnection track. Unfortunately no graphs, other updates. > > Few questions, Seattle is beautiful in summer and I hope to have many of > you in person in beautiful washington state, but for those who can't > travel, should we record / live stream this session? (Historically we did > keep peering track off the grid... i believe) > > Would it be interesting to focus on peering challenges globally or strictly > focus on north america? > > Last but not least, If you have a tool you want to talk about in > interconnection track that is directly involved with peering setup, etc. > please do contact me offlist. > > Cheers! Looking forward to it. > >> On Sat, Apr 1, 2017 at 1:36 PM Mehmet Akcin wrote: >> >> Hello, >> >> As promised few months ago publically I have volunteered to bring together >> content to have Peering Track back to agenda. Now called "Interconnection >> Track" >> >> I would like to ask those who will attend, have attended in person in the >> past or those who have organized similar events to chime in and help >> suggest topics to cover in this 90 min session. >> >> I must say, Interconnection Track has been a major part if NANOG for many >> years. We have watched those who we consider as legends to discuss very >> important topics there. >> >> Please try to make your suggestion in order of importance for you as well >> as from community. >> >> I can try to do my best with help of few folks to bring this track back >> but you can help make it even better so please take a moment and send me >> your suggestions. >> >> Thanks in advance! >> >> Mehmet >> From dhill+nanog at mindcry.org Fri Apr 14 18:03:52 2017 From: dhill+nanog at mindcry.org (David Hill) Date: Fri, 14 Apr 2017 14:03:52 -0400 Subject: ATT (AS7018) cannot reach AS31334 Message-ID: <20170414180352.GA81567@c67c3dd65f017f13199878a6cf05e232bc4d0f5eb07f34f7> Hi - I am a ATT customer unable to reach AS31334. Is anyone on this list able to check into this? It works from non-ATT route-servers I have tested on. ATT route-server ---------------- rviews at route-server.ip.att.net> ping 2a02:8100:4:2::156e count 3 PING6(56=40+8+8 bytes) 2001:1890:111d:1::28 --> 2a02:8100:4:2::156e --- 2a02:8100:4:2::156e ping6 statistics --- 3 packets transmitted, 0 packets received, 100% packet loss Thank you, David From doug at sdnessentials.com Mon Apr 17 15:31:12 2017 From: doug at sdnessentials.com (Doug Marschke) Date: Mon, 17 Apr 2017 08:31:12 -0700 Subject: SD-WAN for enlightened In-Reply-To: References: Message-ID: <001401d2b78f$a5b69b60$f123d220$@sdnessentials.com> Hello Kasper, I will do my best to answer your SD-WAN question, but as you mentioned it is a buzzword that has a bit of confusion in its definitions. I would say that a SD-WAN solution should have the following elements: 1.) Ability to manage multiple WAN connection and choose the path based on user and machine criteria (The Hybrid WAN) 2.) A controller to manage the polices and operations of the SD-WAN devices 3.) Analytics on the network and application level 4.) A software overlay that abstracts and secures the underlying networks Currently there are a lot of solutions out there by many vendors. Some do all of these and some a subset, so it make the landscape a bit confusing. Lots of times vendors use SD-WAN when they are really just talking about Hybrid WAN (multiple connections) or WAN optimization. Doug Marschke CTO www.sdnessentials.com JNCIE-SP #41, JNCIE-ENT #3 415-902-5702 (cell) 415-340-3112 (office) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kasper Adel Sent: Sunday, April 16, 2017 1:14 PM To: NANOG list Subject: SD-WAN for enlightened Hi, I'm not sure if the buzzword SD-WAN is used to compensate for another buzzword that got over-utilized (SDN) or it is a true 'new and improved' way of doing things that has some innovation into it. I heard different explanation from different vendors: 1) appliances (+ controller) placed in-line to put traffic in tunnels based on policy, with some DPI and traffic tagging...(to do performance/policy based routing) over an expensive link (MPLS) and a cheap one (broadband) with some 'firewall-like' filtering capabilities. 2) same as above, with a flavor of 'machine learning' to find a pattern for traffic to optimize utilization. 3) a controller that instantiates and tears down tunnels from 'classic routers' based on external policies and Network based features to do performance based routing over an expensive link (MPLS) and a cheap one (broadband) with encryption. Is the above a decent high-level summary? Has anyone tried any of these solutions, any general feedback ? Cheers, Kim From xcellula at gmail.com Mon Apr 17 15:51:41 2017 From: xcellula at gmail.com (eric c) Date: Mon, 17 Apr 2017 10:51:41 -0500 Subject: route explorer alternative Message-ID: Good morning, Just looking at some tools that help from a visual standpoint when looking at routes from an overall network. Saw route explorer from Packet Design and it looks cool and wanted to know if there are any other that do that like they do it? Protocols like BGP/OSPF/ISIS/RSVP/TE Thanks! eric From rwoolleynanog at gmail.com Mon Apr 17 23:20:12 2017 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Mon, 17 Apr 2017 19:20:12 -0400 Subject: Anyone using Arista 7280R as edge router? In-Reply-To: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> References: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Message-ID: Yes, we (Netflix) have the Arista 7500R and 7280R widely deployed as edge routers. We're a few months away from shutting down the few remaining MXs and ASRs in our CDN. There was a thread from about a year ago that you might check out: https://mailman.nanog.org/pipermail/nanog/2016-April/085472.html Since then, route table growth hasn't changed appreciably. Also, Arista has added some features (notably route-map subroutine support and default-deny) that improve BGP policy functionality. If your use case allows you to use a default for those routes not heard via your direct peers, there are options to increase the functional scale (and thus to stretch the lifespan beyond ~4 years). In addition to filtering, there's support for selective route download, which will allow you to keep a full RIB with a more limited FIB. Regards, Ryan On Fri, Apr 14, 2017 at 9:51 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Hey all, have some Brocade MLXe?s that can no longer handle a full v4 and > v6 route table while also having VRF support (dumb CAM profile limitations > in the software). Mine don?t do anything fancy; just BGP to a few upstream > peers and OSPF/OSPFv3 to the inside, management VRF, some ACL?s. I?m > looking at the ASR9001 with add-on ports since I need (10) 10gig. However, > I?ve also been running some Arista 7280SE?s for the past 18 months with no > issues, and they want me to consider their 7280R since it would give me > more ports, in addition to some higher speed ports, which would be nice if > I ever want to upgrade some of our peering to 40 or 100gig. > > Arista?s specs say the 7500R / 7280R can handle 1M ipv4+ipv6 routes in > hardware (FIB): > > https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf > > In theory, it would last at least a few years if the v4 table doesn?t get > too crazy between now and then. > > Curious if anyone has deployed a 7500R or 7280R in this role and what the > feedback has been? > > The 9001?s 4M ?credits? for the combo of v4 +(2)v6 routes obviously goes > much further, but I think either one would make it to their expected end of > life, or if not on the Arista side, I?d probably have spent half as much. > > Thanks, > > David > From tom at ninjabadger.net Tue Apr 18 00:55:11 2017 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 18 Apr 2017 01:55:11 +0100 Subject: Anyone using Arista 7280R as edge router? In-Reply-To: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> References: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Message-ID: <1ab6ba25-d1d7-0b58-5a6b-10ea2cae1736@ninjabadger.net> On 14/04/17 14:51, David Hubbard wrote: > I?m looking at the ASR9001 with add-on ports since I need (10) 10gig. Be careful here; the 9001 won't support IOS-XR 64-bit as far as anyone can make out, and there is a semi-confirmed successor already on its way up ("9901"). Be sure to mention this if you're speaking to Cisco. :) At that sort of bandwidth, however, something that wasn't viable when I last looked at it was Juniper's vMX. I'd be very intrigued in that as a solution today, assuming your requirements fit into 9001-sized chunks right now. The 7280R might suit you though, so don't rule it out on my account. The feature count has been coming on fast since I last evaluated it, late last year. -- Tom From tom at ninjabadger.net Tue Apr 18 01:08:05 2017 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 18 Apr 2017 02:08:05 +0100 Subject: 10G MetroE 1-2U Switch In-Reply-To: <001901d2b4a7$faa01920$efe04b60$@gvtc.com> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <001901d2b4a7$faa01920$efe04b60$@gvtc.com> Message-ID: <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> On 13/04/17 23:47, Aaron Gould wrote: > Pretty sure I looked at the ciena 51xx and I found that it does not have > mpls in it... pretty sure Erik needs mpls... The 5150 will 'do MPLS', which is pretty clear from their website. The references 5160, too. I wouldn't recommend it personally, but it is there. -- Tom From andrew at vianet.ca Tue Apr 18 04:05:29 2017 From: andrew at vianet.ca (Andrew K.) Date: Tue, 18 Apr 2017 00:05:29 -0400 Subject: route explorer alternative In-Reply-To: References: Message-ID: <3f6c24f5-d6f8-3fe3-c23c-96e70bc997a2@vianet.ca> I am currently demoing their product and am also interested inalternatives. Andrew. On 4/17/2017 11:51 AM, eric c wrote: > Good morning, > > Just looking at some tools that help from a visual standpoint when looking > at routes from an overall network. Saw route explorer from Packet Design > and it looks cool and wanted to know if there are any other that do that > like they do it? Protocols like BGP/OSPF/ISIS/RSVP/TE > > Thanks! > eric > From hugge at nordu.net Tue Apr 18 05:19:02 2017 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 18 Apr 2017 07:19:02 +0200 Subject: Anyone using Arista 7280R as edge router? In-Reply-To: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> References: <8634ECB9-4975-4969-9842-E95B20FADF97@dino.hostasaurus.com> Message-ID: <78f6ee98-599a-22d2-e2c5-96862d6248b3@nordu.net> On 14/04/17 15:51, David Hubbard wrote: > Hey all, have some Brocade MLXe?s that can no longer handle a full v4 and v6 route table while also having VRF support (dumb CAM profile limitations in the software). Mine don?t do anything fancy; just BGP to a few upstream peers and OSPF/OSPFv3 to the inside, management VRF, some ACL?s. I?m looking at the ASR9001 with add-on ports since I need (10) 10gig. However, I?ve also been running some Arista 7280SE?s for the past 18 months with no issues, and they want me to consider their 7280R since it would give me more ports, in addition to some higher speed ports, which would be nice if I ever want to upgrade some of our peering to 40 or 100gig. > > Arista?s specs say the 7500R / 7280R can handle 1M ipv4+ipv6 routes in hardware (FIB): > > https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf > > In theory, it would last at least a few years if the v4 table doesn?t get too crazy between now and then. > > Curious if anyone has deployed a 7500R or 7280R in this role and what the feedback has been? > > The 9001?s 4M ?credits? for the combo of v4 +(2)v6 routes obviously goes much further, but I think either one would make it to their expected end of life, or if not on the Arista side, I?d probably have spent half as much. > > Thanks, > > David > I have a bunch of 7280R in a edge-peering role in as2603 network. Works really well and now with the latest additions of subroutemaps and a very optimistic road-map for features i think these style boxes will definitely see more market. Comparing the price of a 7820R 1Tb box with like a Juniper MX with 1Tb worth of ports its not even on the same play-field. I wouldn't count on the 1M routes to last a lifetime but on the other hand its very easy to re-skill the box to something else. If we look at broadcoms road-map there is also new 7280s destined to come out quite soon with the Jericho+ chipset, broadcom promises 20-25% table-increase so we will see what arista, cisco and the others boils it down to when the chip has gotten a box wrapped around it. -- hugge From z at amused.net Tue Apr 18 13:21:15 2017 From: z at amused.net (Patrick Cole) Date: Tue, 18 Apr 2017 23:21:15 +1000 Subject: 10G MetroE 1-2U Switch In-Reply-To: <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <001901d2b4a7$faa01920$efe04b60$@gvtc.com> <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> Message-ID: <20170418132115.vxiw3jkhn2lubkji@amused.net> Yes, stay well away from the Ciena MPLS code... based on my experience with the CN5100/3900 series... Tue, Apr 18, 2017 at 02:08:05AM +0100, Tom Hill wrote: > On 13/04/17 23:47, Aaron Gould wrote: > > Pretty sure I looked at the ciena 51xx and I found that it does not have > > mpls in it... pretty sure Erik needs mpls... > > The 5150 will 'do MPLS', which is pretty clear from their website. The > references 5160, too. > > I wouldn't recommend it personally, but it is there. -- Patrick Cole Senior Network Specialist World Without Wires PO Box 869. Palm Beach, QLD, 4221 Ph: 0410 626 630 From john at vanoppen.com Sun Apr 16 17:17:25 2017 From: john at vanoppen.com (John van Oppen) Date: Sun, 16 Apr 2017 17:17:25 +0000 Subject: John Van Oppen - Wave Broadband In-Reply-To: References: <01dd01d2a264$17d91e20$478b5a60$@jaritsch.at> <01f901d2a27a$a8c24720$fa46d560$@jaritsch.at> <1490176932.2483603.919494848.3B91E17E@webmail.messagingengine.com> <58F36F94.3020402@netassist.ua>,<20170416132937.5m3vc6iou2b7y3mt@Vurt.local> Message-ID: Hi.... john at vanoppen.com if you need me or anything from 11404 in general. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rod Beck Sent: Sunday, April 16, 2017 9:40 AM To: nanog at nanog.org Subject: John Van Oppen - Wave Broadband If John is on the list, please have him contact me. Thanks. Regards, Roderick. Sales Cross Lake SeaX-1 and SeaX-2 From gabe at rtegroup.com Tue Apr 18 11:02:21 2017 From: gabe at rtegroup.com (Gabe Cole) Date: Tue, 18 Apr 2017 07:02:21 -0400 Subject: Telin/Telekom Indonesia Message-ID: <8DD32617-7242-48B7-B4B8-3B5192E987BE@rtegroup.com> Need a data center contact if anyone has one. Sent from my iPhone Gabe Cole gabe at rtegroup.com +1-617-303-8707 @datacenterguru From nimrodl at gmail.com Mon Apr 17 19:41:09 2017 From: nimrodl at gmail.com (Nimrod Levy) Date: Mon, 17 Apr 2017 19:41:09 +0000 Subject: ATT (AS7018) cannot reach AS31334 In-Reply-To: <20170414180352.GA81567@c67c3dd65f017f13199878a6cf05e232bc4d0f5eb07f34f7> References: <20170414180352.GA81567@c67c3dd65f017f13199878a6cf05e232bc4d0f5eb07f34f7> Message-ID: >From what I can see, 31334 is sending prefixes covering this IP to upstreams 1273 and 6939 (possibly others, but that's what I saw). Neither of these networks propagate those prefixes into 7018 directly or indirectly so we have no path to get there. I would encourage 31334 to check with their upstreams to understand why the routes don't get sent to 7018. -- Nimrod On Mon, Apr 17, 2017 at 10:28 AM David Hill wrote: > Hi - > > I am a ATT customer unable to reach AS31334. Is anyone on this list > able to check into this? It works from non-ATT route-servers I have > tested on. > > ATT route-server > ---------------- > rviews at route-server.ip.att.net> ping 2a02:8100:4:2::156e count 3 > PING6(56=40+8+8 bytes) 2001:1890:111d:1::28 --> 2a02:8100:4:2::156e > > --- 2a02:8100:4:2::156e ping6 statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss > > Thank you, > David > -- -- Nimrod From oliverdouglas at programmer.net Sun Apr 16 23:39:12 2017 From: oliverdouglas at programmer.net (Douglas Silva) Date: Mon, 17 Apr 2017 01:39:12 +0200 Subject: Fw: Re: SD-WAN for enlightened References: , Message-ID: From rwebb at ropeguru.com Tue Apr 18 19:26:56 2017 From: rwebb at ropeguru.com (rwebb) Date: Tue, 18 Apr 2017 15:26:56 -0400 Subject: weebly.com contact Message-ID: <1492543616303889713@ropeguru.com> ?Anyone from weebly.com on here that can contact me off list about a possibly phishing site being hosted with you? Thanks,Robert Webb From jwalter at weebly.com Tue Apr 18 20:59:37 2017 From: jwalter at weebly.com (Jeff Walter) Date: Tue, 18 Apr 2017 15:59:37 -0500 Subject: weebly.com contact In-Reply-To: <1492543616303889713@ropeguru.com> References: <1492543616303889713@ropeguru.com> Message-ID: Yes. Give me a moment. On Tue, Apr 18, 2017 at 2:26 PM, rwebb wrote: > ?Anyone from weebly.com on here that can contact me off list about a > possibly phishing site being hosted with you? > Thanks,Robert Webb > From ahmed.dalaali at hrins.net Wed Apr 19 12:19:25 2017 From: ahmed.dalaali at hrins.net (Ahmed Munaf) Date: Wed, 19 Apr 2017 15:19:25 +0300 Subject: A10 sales representative Message-ID: <4B5F47EB-EB9F-45CF-BEC7-4F1E1A843614@hrins.net> Anyone out here from A10 sales representative for MEA region please contact me off list. Regards, From rod.beck at unitedcablecompany.com Wed Apr 19 17:40:01 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 19 Apr 2017 17:40:01 +0000 Subject: Looking For List of MAN Providers Message-ID: In Seattle and Vancouver. Off list please. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Kir?ly utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221429846_image002.jpg][1467221477350_image005.png] From aaron1 at gvtc.com Wed Apr 19 20:05:42 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 19 Apr 2017 15:05:42 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <001901d2b4a7$faa01920$efe04b60$@gvtc.com> <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> Message-ID: <00a001d2b948$533dab20$f9b90160$@gvtc.com> Thanks Tom... I might be wrong, I thought I remembered Ciena not having the MPLS routing capabilities I needed... I do see this on their website... so maybe it does more MPLS L2/L3VPN capabilities than I remembered... I might have to take another look at this and talk to my Ciena POC and VAR... Thanks again. http://www.ciena.com/products/5160/ RFC 2205, 3031, 3036, 3985 MPLS PWE3 Pseudowire Emulation Edge-to-Edge RFC 5654 MPLS-Transport Profile (TP) LSP Static provisioning 1:1 Tunnel protection LSP BFD via Gal/Gach MPLS Virtual Private Wire Service (VPWS) RFC 4762 VPLS (Virtual Private LAN Service) and Hierarchical VPLS (H-VPLS) Provider Edge (PE-s) Functionality for VPLS and H-VPLS VPLS with multiple VPLS Mesh Virtual Circuits H-VPLS with Hub and Spoke Virtual Circuits MTU-s Functionality for H-VPLS deployment MTU-s Multi-homing (redundant VCs to different PE-s switches) MPLS Virtual Circuit as H-VPLS spoke Virtual Circuit PBB-TE Service Instance as H-VPLS spoke Virtual Circuit Q-in-Q Ethernet Virtual Circuit as H-VPLS spoke Virtual Circuit MPLS Label Switch Path (LSP) Tunnel Groups MPLS Label Switch Path (LSP) Tunnel Redundancy Layer 2 Control Frame Tunneling over MPLS Virtual Circuits RFC 3209 RSVP-TE (for MPLS Tunnel Signaling) RFC 3630 OSPF-TE (for MPLS Tunnel Routes) RFC 3784 IS-IS-TE (for MPLS Tunnel Routes) RFC 3036 LDP & Targeted LDP (for VPLS VC signaling) RFC 4090 MPLS Fast ReRoute signaling LSP Ping & Traceroute -Aaron From aaron1 at gvtc.com Wed Apr 19 20:06:42 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 19 Apr 2017 15:06:42 -0500 Subject: 10G MetroE 1-2U Switch In-Reply-To: <20170418132115.vxiw3jkhn2lubkji@amused.net> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <001901d2b4a7$faa01920$efe04b60$@gvtc.com> <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> <20170418132115.vxiw3jkhn2lubkji@amused.net> Message-ID: <00a201d2b948$774e4dd0$65eae970$@gvtc.com> Oh, ok... hmmm So what was the issue with Ciena and MPLS Patrick ? -Aaron From bill at herrin.us Wed Apr 19 21:21:32 2017 From: bill at herrin.us (William Herrin) Date: Wed, 19 Apr 2017 17:21:32 -0400 Subject: Lit buildings in Tysons Corner, VA? Message-ID: Hi folks, Does anyone have a map of who lights which buildings in Tysons Corner? Not the data centers themselves but the nearby office buildings. I'm trying to figure out who has service down westwood center drive, across from Equinix DC8/Tyco Road. Off list replies welcome; I'll summarize if I get any general-interest information. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mark at rudholm.com Wed Apr 19 23:12:39 2017 From: mark at rudholm.com (Mark Rudholm) Date: Wed, 19 Apr 2017 16:12:39 -0700 Subject: Vonage Security Contact Message-ID: <02d6e0bb-4d0a-694a-214a-b920067ff0a9@rudholm.com> Anyone on here from Vonage who can contact me about an IRS scam that's using a live Vonage number as a callback number? From ahebert at pubnix.net Fri Apr 21 13:07:49 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 21 Apr 2017 09:07:49 -0400 Subject: 10G MetroE 1-2U Switch In-Reply-To: <3979AE529B56AB47942E2423B707F16E64BF4A57@RTC-EXCH01.RESERVE.LDS> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <3979AE529B56AB47942E2423B707F16E64BF4A57@RTC-EXCH01.RESERVE.LDS> Message-ID: <75874d0a-c523-da97-fc8b-795916a74429@pubnix.net> Eeee... We're still in the mist of a battle royal with 6 QFX 5100 here =D We'll know who wins soon. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 04/13/17 17:59, Kody Vicknair wrote: > Have you taken a look at the Juniper QFX series? I use these for video multicast and I'm not 100% sure they have support for all the features you've requested, BUT I do know of a competitor that uses them for cheap 10G VPLS deployment. It might be worth looking into. If you need a Juniper engineer to bounce your questions off of, I know a guy... > > I'd start here: > > http://www.juniper.net/us/en/products-services/switching/qfx-series/qfx5100/ > > > > > Kody Vicknair > Network Engineer > > Tel: 985.536.1214 > Fax: 985.536.0300 > Email: kvicknair at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > _________________________________________________________________________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+kvicknair=reservetele.com at nanog.org] On Behalf Of Erik Sundberg > Sent: Thursday, April 13, 2017 4:37 PM > To: nanog at nanog.org > Subject: 10G MetroE 1-2U Switch > > Hey Nanog, > > Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. > > Requirements > MEF compliant > 1-2U small foot print > 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI Cost effect 10G Ports 100G Not required > > > Looking at the > ASR920's - Great box for 1G but not enough 10G Ports Only 4 > NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ > ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. > > Any other platforms I should be looking at? > > Ciena, Brocade, Juniper? > > > > Thanks in advance! > > -Erik > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From z at amused.net Fri Apr 21 13:45:06 2017 From: z at amused.net (Patrick Cole) Date: Fri, 21 Apr 2017 23:45:06 +1000 Subject: 10G MetroE 1-2U Switch In-Reply-To: <00a201d2b948$774e4dd0$65eae970$@gvtc.com> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <001901d2b4a7$faa01920$efe04b60$@gvtc.com> <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> <20170418132115.vxiw3jkhn2lubkji@amused.net> <00a201d2b948$774e4dd0$65eae970$@gvtc.com> Message-ID: <20170421134506.rbbvm5cudb72d7sw@amused.net> Aaron, The code is very green; the platform originally was inherited from Nortel and as such they invested heavily in PBB-TE first and foremost. To give you an idea they're currently at version 6.16 and the MPLS code was introduced in 6.10 (from memory). They support just enough OSPFv2 or IS-IS to implement basic MPLS TE functionality but it does not interop with any other vendor well at all from my testing. They only support protected active/standby LSP groups withI maximum 2 paths per group. Paths inside a group cannot be computed automatically and /must/ have EROs specified. They do not support Fast Reroute PLR/MP in any way and their product manager said they have no plans to do so in the future. They do support "signalling" desired FRR protection on an LSP, however, in my lab testing this is a moot point as they don't interop with our Cisco core gear. They seem to add GMPLS TLVs in to their PATH msgs with nil values even when you aren't using GMPLS, which Cisco doesn't like. I was able to get their gear to interop with our Brocade routers, but it was world of hurt of problems in production as they don't do make before break on LSPs or anything useful like that. Even when running only their gear in isolation, we had numerous extremely large service impacting problems with their software - things that as a software and network engineer by trade I can only put down to extremely badly written code. For example we had an issue where when BFD would flap on links rapidly through our network, the MPLS cross connect table would get misprogrammed with a bad value and then from that point onwards all transit LSPs would fail to signal through the node. Even further to this, the biggest issue I had is that their software was not written with enough easy-to-access diagnostic/debugging capability to be able to allow the vendor to triage and get to the root cause of issues. Most major issues never got solved because the things the vendor required you to troubleshoot were outragously inconvenient or massively service affecting in nature. Example; there was no way to send debugging via the network (syslog etc). In quite a few cases I had to break out in to the linux CLI and run their debug streaming program on all our nodes and use netcat to transport it back to our servers to capture it. They implement LDP signalled PWE and VPLS but the cli has a lot of really annoying nuances like, you can't change the LSP on a pseudowire without detaching it from its virtual switch (no make-before-break functionality exists either). We stuck with it for a while, hoping it would get better but every release seemed to bring different bugs, and the old ones never seemed to get fully fixed and would resurface in the future. I suspect they were dealing with race conditions in their code and they just never could seem to reproduce the conditions that would cause them in their lab. I think our microwave network tested their code in ways they never had before when storms rolled through. This might all be different on their larger packet optical devices I don't know - this all applies to the SA-OS on 39XX/51XX platform. We now use the ASR920 platform and comparatively it's night and day in terms of feature set and stability. Only thing I'm missing is lack of tunnel byte counters for use by auto-bw, but Cisco say this is coming in Everest... Regards, Patrick Wed, Apr 19, 2017 at 03:06:42PM -0500, Aaron Gould wrote: > Oh, ok... hmmm > > So what was the issue with Ciena and MPLS Patrick ? > > -Aaron > > -- Patrick Cole Senior Network Specialist World Without Wires PO Box 869. Palm Beach, QLD, 4221 Ph: 0410 626 630 From z at amused.net Fri Apr 21 14:06:49 2017 From: z at amused.net (Patrick Cole) Date: Sat, 22 Apr 2017 00:06:49 +1000 Subject: 10G MetroE 1-2U Switch In-Reply-To: <20170421134506.rbbvm5cudb72d7sw@amused.net> References: <495D0934DA46854A9CA758393724D590754A44B4@NI-MAIL02.nii.ads> <001901d2b4a7$faa01920$efe04b60$@gvtc.com> <3183def0-42a2-b647-c894-216a6cab5d01@ninjabadger.net> <20170418132115.vxiw3jkhn2lubkji@amused.net> <00a201d2b948$774e4dd0$65eae970$@gvtc.com> <20170421134506.rbbvm5cudb72d7sw@amused.net> Message-ID: <20170421140649.mnaodepcrjmhjkcl@amused.net> Sorry, slight correction to the below - GMPLS Sub-TLVs inside the TE LSAs were being advertised with nil values instead of being removed completely. One additional thing that really irked me is that their TE code is that they set all TE metrics to 0 for every interface/link and no way to use the IGP metric or set it, so if you have two links of equal distance in terms of hops, there was no way to steer a CSPF computed LSP to prefer one without using EROs to do it. They also have no concept of attribute flags or link colors. Ultimately, their TE implementation was very basic. They openly admitted their focus was on GMPLS and not MPLS-TE. For us, GMPLS has no real use case in our network. Patrick Fri, Apr 21, 2017 at 11:45:06PM +1000, Patrick Cole wrote: > Aaron, > > The code is very green; the platform originally was inherited from > Nortel and as such they invested heavily in PBB-TE first and foremost. > > To give you an idea they're currently at version 6.16 and the MPLS > code was introduced in 6.10 (from memory). > > They support just enough OSPFv2 or IS-IS to implement basic MPLS TE > functionality but it does not interop with any other vendor well > at all from my testing. > > They only support protected active/standby LSP groups withI maximum > 2 paths per group. Paths inside a group cannot be computed automatically > and /must/ have EROs specified. > > They do not support Fast Reroute PLR/MP in any way and their product > manager said they have no plans to do so in the future. They do support > "signalling" desired FRR protection on an LSP, however, in my lab testing > this is a moot point as they don't interop with our Cisco core gear. > They seem to add GMPLS TLVs in to their PATH msgs with nil values even > when you aren't using GMPLS, which Cisco doesn't like. > > I was able to get their gear to interop with our Brocade routers, but > it was world of hurt of problems in production as they don't do make > before break on LSPs or anything useful like that. > > Even when running only their gear in isolation, we had numerous extremely > large service impacting problems with their software - things that as > a software and network engineer by trade I can only put down > to extremely badly written code. For example we had an issue where when > BFD would flap on links rapidly through our network, the MPLS cross > connect table would get misprogrammed with a bad value and then from > that point onwards all transit LSPs would fail to signal through the > node. > > Even further to this, the biggest issue I had is that their software > was not written with enough easy-to-access diagnostic/debugging capability > to be able to allow the vendor to triage and get to the root cause > of issues. Most major issues never got solved because the things > the vendor required you to troubleshoot were outragously inconvenient > or massively service affecting in nature. Example; there was no > way to send debugging via the network (syslog etc). In quite a > few cases I had to break out in to the linux CLI and run their > debug streaming program on all our nodes and use netcat to transport > it back to our servers to capture it. > > They implement LDP signalled PWE and VPLS but the cli has a lot of > really annoying nuances like, you can't change the LSP on a pseudowire > without detaching it from its virtual switch (no make-before-break > functionality exists either). > > We stuck with it for a while, hoping it would get better but every > release seemed to bring different bugs, and the old ones never > seemed to get fully fixed and would resurface in the future. I > suspect they were dealing with race conditions in their code and > they just never could seem to reproduce the conditions that would > cause them in their lab. I think our microwave network tested their > code in ways they never had before when storms rolled through. > > This might all be different on their larger packet optical devices > I don't know - this all applies to the SA-OS on 39XX/51XX platform. > > We now use the ASR920 platform and comparatively it's night and > day in terms of feature set and stability. Only thing I'm missing > is lack of tunnel byte counters for use by auto-bw, but Cisco say > this is coming in Everest... > > Regards, > > Patrick > > > Wed, Apr 19, 2017 at 03:06:42PM -0500, Aaron Gould wrote: > > > Oh, ok... hmmm > > > > So what was the issue with Ciena and MPLS Patrick ? > > > > -Aaron > > > > > > -- > Patrick Cole > Senior Network Specialist > World Without Wires > PO Box 869. Palm Beach, QLD, 4221 > Ph: 0410 626 630 > -- Patrick Cole Senior Network Specialist World Without Wires PO Box 869. Palm Beach, QLD, 4221 Ph: 0410 626 630 From jhazesnooty at gmail.com Sat Apr 22 12:51:37 2017 From: jhazesnooty at gmail.com (Javier Solis) Date: Sat, 22 Apr 2017 07:51:37 -0500 Subject: weebly.com contact In-Reply-To: References: <1492543616303889713@ropeguru.com> Message-ID: We are seeing similar issues with weebly hosted sites. We're currently blocking URLs with checkpoint URL filtering, but blocking https is a challenge for us. -Javier On Apr 18, 2017 4:01 PM, "Jeff Walter" wrote: Yes. Give me a moment. On Tue, Apr 18, 2017 at 2:26 PM, rwebb wrote: > ?Anyone from weebly.com on here that can contact me off list about a > possibly phishing site being hosted with you? > Thanks,Robert Webb > From baldur.norddahl at gmail.com Sun Apr 23 10:52:08 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 23 Apr 2017 12:52:08 +0200 Subject: Amazon EU-West 1 trouble Message-ID: <40460f55-11f2-1733-d08e-5d43c4bbcc67@gmail.com> Hello, We are currently experiencing massive packet loss from Amazon EU-West 1. This page http://ec2-reachability.amazonaws.com/ will show most of eu-west-1 as down but actually it is packet loss of 90+ %. I have found that if I shutdown our link to Hurricane Electric the problem disappears. Also it is only an IPv4 problem as IPv6 is fine (also going through Hurricane Electric). A traceroute shows everything ok until the first hop inside the Amazon network. The peering is apparently at AMS-IX. Right now we are ok because I am keeping the HE.Net connection down, but I managed to find another NLNOG Ring node that has the same problem: gigabit at casablanca01:~$ ping 52.16.0.2 PING 52.16.0.2 (52.16.0.2) 56(84) bytes of data. 64 bytes from 52.16.0.2: icmp_seq=2 ttl=244 time=35.1 ms 64 bytes from 52.16.0.2: icmp_seq=34 ttl=244 time=35.2 ms 64 bytes from 52.16.0.2: icmp_seq=44 ttl=244 time=35.2 ms 64 bytes from 52.16.0.2: icmp_seq=52 ttl=244 time=35.2 ms ^C --- 52.16.0.2 ping statistics --- 72 packets transmitted, 4 received, 94% packet loss, time 71228ms rtt min/avg/max/mdev = 35.170/35.220/35.251/0.232 ms That IP is one from eu-west-1 taken from the ec2-reachability page. When I ping it with the HE.Net link down there is 0% packet loss. With it up we are seeing something like the above. However I notice that Casablanca is going out through Telia not HE. The return path could very well be via HE of course, there is no way to know that. From all the RING nodes I checked only Casablanca01 seems to experience the problem, so it appears it is not very wide spread. Anyone know how to get in contact with Amazon and have them debug this issue? Regards, Baldur From dovid at telecurve.com Sun Apr 23 10:57:56 2017 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 23 Apr 2017 06:57:56 -0400 Subject: Amazon EU-West 1 trouble In-Reply-To: <40460f55-11f2-1733-d08e-5d43c4bbcc67@gmail.com> Message-ID: <58fc88b6.8ba1370a.3ccf7.9634@mx.google.com> HE is having issues in Europe. I spoke with them an hour ago, they said they were aware of the issue but didn't have an ETA. Based on the traces we saw issues with connections coming into London. ? Original Message ? From: baldur.norddahl at gmail.com Sent: April 23, 2017 6:52 AM To: nanog at nanog.org Subject: Amazon EU-West 1 trouble Hello, We are currently experiencing massive packet loss from Amazon EU-West 1. This page http://ec2-reachability.amazonaws.com/ will show most of eu-west-1 as down but actually it is packet loss of 90+ %. I have found that if I shutdown our link to Hurricane Electric the problem disappears. Also it is only an IPv4 problem as IPv6 is fine (also going through Hurricane Electric). A traceroute shows everything ok until the first hop inside the Amazon network. The peering is apparently at AMS-IX. Right now we are ok because I am keeping the HE.Net connection down, but I managed to find another NLNOG Ring node that has the same problem: gigabit at casablanca01:~$ ping 52.16.0.2 PING 52.16.0.2 (52.16.0.2) 56(84) bytes of data. 64 bytes from 52.16.0.2: icmp_seq=2 ttl=244 time=35.1 ms 64 bytes from 52.16.0.2: icmp_seq=34 ttl=244 time=35.2 ms 64 bytes from 52.16.0.2: icmp_seq=44 ttl=244 time=35.2 ms 64 bytes from 52.16.0.2: icmp_seq=52 ttl=244 time=35.2 ms ^C --- 52.16.0.2 ping statistics --- 72 packets transmitted, 4 received, 94% packet loss, time 71228ms rtt min/avg/max/mdev = 35.170/35.220/35.251/0.232 ms That IP is one from eu-west-1 taken from the ec2-reachability page. When I ping it with the HE.Net link down there is 0% packet loss. With it up we are seeing something like the above. However I notice that Casablanca is going out through Telia not HE. The return path could very well be via HE of course, there is no way to know that. From all the RING nodes I checked only Casablanca01 seems to experience the problem, so it appears it is not very wide spread. Anyone know how to get in contact with Amazon and have them debug this issue? Regards, Baldur From job at instituut.net Sun Apr 23 11:00:05 2017 From: job at instituut.net (Job Snijders) Date: Sun, 23 Apr 2017 13:00:05 +0200 Subject: Amazon EU-West 1 trouble In-Reply-To: <40460f55-11f2-1733-d08e-5d43c4bbcc67@gmail.com> References: <40460f55-11f2-1733-d08e-5d43c4bbcc67@gmail.com> Message-ID: <20170423110005.2f7jpxorpttibzsm@Vurt.local> On Sun, Apr 23, 2017 at 12:52:08PM +0200, Baldur Norddahl wrote: > We are currently experiencing massive packet loss from Amazon EU-West 1. > This page http://ec2-reachability.amazonaws.com/ will show most of eu-west-1 > as down but actually it is packet loss of 90+ %. > > I have found that if I shutdown our link to Hurricane Electric the problem > disappears. Also it is only an IPv4 problem as IPv6 is fine (also going > through Hurricane Electric). Perhaps related to https://puck.nether.net/pipermail/outages/2017-April/010340.html Kind regards, Job From dovid at telecurve.com Sun Apr 23 12:28:36 2017 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 23 Apr 2017 08:28:36 -0400 Subject: Amazon EU-West 1 trouble In-Reply-To: <20170423110005.2f7jpxorpttibzsm@Vurt.local> References: <40460f55-11f2-1733-d08e-5d43c4bbcc67@gmail.com> <20170423110005.2f7jpxorpttibzsm@Vurt.local> Message-ID: Issue resolved as 07:32 EST. On Sun, Apr 23, 2017 at 7:00 AM, Job Snijders wrote: > On Sun, Apr 23, 2017 at 12:52:08PM +0200, Baldur Norddahl wrote: > > We are currently experiencing massive packet loss from Amazon EU-West 1. > > This page http://ec2-reachability.amazonaws.com/ will show most of > eu-west-1 > > as down but actually it is packet loss of 90+ %. > > > > I have found that if I shutdown our link to Hurricane Electric the > problem > > disappears. Also it is only an IPv4 problem as IPv6 is fine (also going > > through Hurricane Electric). > > Perhaps related to > https://puck.nether.net/pipermail/outages/2017-April/010340.html > > Kind regards, > > Job > From ssw at iu.edu Fri Apr 21 12:37:46 2017 From: ssw at iu.edu (Steven Wallace) Date: Fri, 21 Apr 2017 08:37:46 -0400 Subject: Covering prefix blackholing traffic to one of its covered prefixes.... Message-ID: <6E792661-B0FB-4601-B1F1-1B2C0E3FFF05@iu.edu> We have dual-homed sites that only accept routes from their peers, and default to their transit provider. A site may receive a covering prefix from a peer, but since they are not accepting the full table from their transit provider they don?t see the covered (i.e., more specific). In some cases the peer announcing the covering prefix blackholes traffic to the covered prefix. Is this accepted behavior, or should a peer announcing a covering prefix always delver packets to its covered routes? Does this happen often? Thanks! Steven Wallace Indiana University -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3569 bytes Desc: not available URL: From ssw at iu.edu Sun Apr 23 15:59:15 2017 From: ssw at iu.edu (Steven Wallace) Date: Sun, 23 Apr 2017 11:59:15 -0400 Subject: Covering prefix blackholing traffic to one of its covered prefixes.... Message-ID: <7C10D0BB-63D9-43E9-A3C9-5971AE6DC95A@iu.edu> We have dual-homed sites that only accept routes from their peers, and default to their transit provider. A site may receive a covering prefix from a peer, but since they are not accepting the full table from their transit provider they don?t see the covered (i.e., more specific). In some cases the peer announcing the covering prefix blackholes traffic to the covered prefix. Is this accepted behavior, or should a peer announcing a covering prefix always delver packets to its covered routes? Does this happen often? Thanks! Steven Wallace Indiana University -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3569 bytes Desc: not available URL: From rstory at isi.edu Wed Apr 19 18:30:52 2017 From: rstory at isi.edu (Robert Story) Date: Wed, 19 Apr 2017 14:30:52 -0400 Subject: B-root begins anycast in May Message-ID: <20170419143052.01ce7652@titan.int.futz.org> To improve B-Root DNS service, B-Root will be activating anycast on 2017-05-01, providing service from a new site in Miami in addition to our current site in Los Angeles. We thank Florida International University (https://www.fiu.edu) and Ampath.net (https://ampath.net) for hosting our new hardware there, and USC (https://www.usc.edu) for hardware support for this second site. As part of this deployment, we will be renumbering B-Root's IPv6 address to 2001:500:200::b, effective on 2017-06-01. We also plan renumber our IPv4 address later in 2017; we will announce that date here. Renumbering will help support anycast with more resilient routing. (We will provide service on our old IPv6 and IPv4 addresses for at least one year after renumbering.) Robert B-Root Operator team -- Robert Story USC Information Sciences Institute From ben at nectolab.io Thu Apr 20 23:30:48 2017 From: ben at nectolab.io (Benjamin Huang) Date: Thu, 20 Apr 2017 16:30:48 -0700 Subject: Intros Message-ID: Hey Guys; just joined this mailing list, trying to see if its still active -- Benjamin Huang JoinNecto.com 1(650) 488-1065 From ben at nectolab.io Fri Apr 21 01:27:21 2017 From: ben at nectolab.io (Benjamin Huang) Date: Thu, 20 Apr 2017 18:27:21 -0700 Subject: Meet up in San Francisco Message-ID: Hey Guys: Piggy backing off a small meet up in SF yesterday, I've decided to start a monthly meet-up group where people can come and share to each other about stories they faced running a ISP Here's the event https://www.meetup.com/San-Francisco-Wireless-Broadband-Meet -Up/events/239368810/ -- Benjamin Huang JoinNecto.com 1(650) 488-1065 From niels=nanog at bakker.net Mon Apr 24 15:10:23 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 24 Apr 2017 17:10:23 +0200 Subject: Covering prefix blackholing traffic to one of its covered prefixes.... In-Reply-To: <7C10D0BB-63D9-43E9-A3C9-5971AE6DC95A@iu.edu> References: <7C10D0BB-63D9-43E9-A3C9-5971AE6DC95A@iu.edu> Message-ID: <20170424151022.GH86663@excession.tpb.net> * ssw at iu.edu (Steven Wallace) [Mon 24 Apr 2017, 16:51 CEST]: >We have dual-homed sites that only accept routes from their peers, >and default to their transit provider. A site may receive a covering >prefix from a peer, but since they are not accepting the full table >from their transit provider they don?t see the covered (i.e., more >specific). In some cases the peer announcing the covering prefix >blackholes traffic to the covered prefix. > >Is this accepted behavior, or should a peer announcing a covering >prefix always delver packets to its covered routes? A prefix announcement means a statement of capability and willingness to deliver packets to covered destinations. Any deviation is a hijack. >Does this happen often? This is more common than it should be. -- Niels. From joelja at bogus.com Mon Apr 24 15:19:44 2017 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 24 Apr 2017 08:19:44 -0700 Subject: Covering prefix blackholing traffic to one of its covered prefixes.... In-Reply-To: <7C10D0BB-63D9-43E9-A3C9-5971AE6DC95A@iu.edu> References: <7C10D0BB-63D9-43E9-A3C9-5971AE6DC95A@iu.edu> Message-ID: Sent from my iPhone > On Apr 23, 2017, at 08:59, Steven Wallace wrote: > > We have dual-homed sites that only accept routes from their peers, and default to their transit provider. A site may receive a covering prefix from a peer, but since they are not accepting the full table from their transit provider they don?t see the covered (i.e., more specific). In some cases the peer announcing the covering prefix blackholes traffic to the covered prefix. If you announce a route in general you should expect to route it. Assuming this is the intended behavior of both parties announcing the covering aggregate and the more specific. The site should either drop the offending peer route forcing it to transit, or take full feed from it's transit. And let the longest match win. > Is this accepted behavior, or should a peer announcing a covering prefix always delver packets to its covered routes? Generally but there are exceptions. > > Does this happen often? > > Thanks! > > Steven Wallace > Indiana University From mel at beckman.org Mon Apr 24 16:07:17 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 24 Apr 2017 16:07:17 +0000 Subject: Intros In-Reply-To: References: Message-ID: Benjamin, No offense, but I recommend you read the archives rather than creating noise posts as a way to assess the activity level of the list. Also it's probably a good idea for you to review the Acceptable Use Policy for the list: 1. Discussion will focus on Internet operational and technical issues as described in the charter of NANOG. 2. Postings of issues inconsistent with the charter are prohibited. 3. Cross posting is prohibited. 4. Postings that include foul language, character assassination, and lack of respect for other participants are prohibited. 5. Product marketing is prohibited. 6. Postings of political, philosophical, and legal nature are prohibited. 7. Using list as source for private marketing initiatives is prohibited. 8. Autoresponders sending mail either to the list or to the poster are prohibited. https://www.nanog.org/list/archives https://www.nanog.org/list/faq/other -mel beckman On Apr 24, 2017, at 7:58 AM, Benjamin Huang > wrote: Hey Guys; just joined this mailing list, trying to see if its still active -- Benjamin Huang JoinNecto.com 1(650) 488-1065 From alberto at caida.org Mon Apr 24 17:15:43 2017 From: alberto at caida.org (Alberto Dainotti) Date: Mon, 24 Apr 2017 10:15:43 -0700 Subject: survey on BGP prefix hijacking Message-ID: Dear NANOG Community, BGP prefix hijacking remains a problem for Internet routing, despite the (partial) use of RPKI or detection services. We would like to hear your opinions on BGP prefix hijacking (concerns, existing defenses, needs, etc.) that would help us research new defense mechanisms both for its detection and mitigation. Please help us by answering this short (< 10min, 21 questions) and anonymous survey. Survey URL: http://tinyurl.com/hijack-survey *** The survey *** This survey is part of a joint research effort by CAIDA (www.caida.org) and the ICS-FORTH (www.ics.forth.gr) research institute, to study (a) operator awareness of BGP prefix hijacking attacks/incidents, (b) presently used defenses against BGP prefix hijacking, (c) the willingness to adopt new defense mechanisms, and (d) reasons that may hinder the deployment of BGP prefix hijacking defenses. We expect the findings of this survey to increase the understanding of existing BGP hijacking defenses and the needs of network operators, as well as help us design and implement new defense mechanisms that we will present to the operator and scientific communities. A summary of the aggregate results will be published as a part of an article/conference paper. Thank you in advance, and we look forward to your responses! Alberto (CAIDA) and Pavlos (ICS-FORTH) From h.wahl at ifw-dresden.de Tue Apr 25 18:45:35 2017 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Tue, 25 Apr 2017 20:45:35 +0200 Subject: DHCPv6 relay software with RFC 6939 support Message-ID: <53046b17-3d41-5884-fef5-2227e7d66b10@ifw-dresden.de> Hello world, does anybody know of an open-source DHCPv6 relay software which supports client link-layer option as in RFC 6939? Thanks and regards Henri -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: +49 (3 51) 46 59 - 797 email: h.wahl at ifw-dresden.de https://www.ifw-dresden.de Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Burkard Hillebrands, Dr. Doreen Kirmse -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x83E6CEC2.asc Type: application/pgp-keys Size: 3925 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x83E6CEC2.asc Type: application/pgp-keys Size: 3827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From marka at isc.org Wed Apr 26 02:58:15 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 26 Apr 2017 12:58:15 +1000 Subject: DHCPv6 relay software with RFC 6939 support In-Reply-To: Your message of "Tue, 25 Apr 2017 20:45:35 +0200." <53046b17-3d41-5884-fef5-2227e7d66b10@ifw-dresden.de> References: <53046b17-3d41-5884-fef5-2227e7d66b10@ifw-dresden.de> Message-ID: <20170426025816.0D2D76CFF33D@rock.dv.isc.org> Looking at git repository ISC DHCP 4.3 supports this. Mark In message <53046b17-3d41-5884-fef5-2227e7d66b10 at ifw-dresden.de>, Henri Wahl writes: > > Hello world, > > does anybody know of an open-source DHCPv6 relay software which supports > client link-layer option as in RFC 6939? > > Thanks and regards > > Henri > > -- > Henri Wahl > > IT Department > Leibniz-Institut fuer Festkoerper- u. > Werkstoffforschung Dresden > > tel: +49 (3 51) 46 59 - 797 > email: h.wahl at ifw-dresden.de > https://www.ifw-dresden.de > > Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de > > DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de > > S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem > PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc > > IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden > VR Dresden Nr. 1369 > Vorstand: Prof. Dr. Burkard Hillebrands, Dr. Doreen Kirmse -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Apr 26 02:59:57 2017 From: marka at isc.org (Mark Andrews) Date: Wed, 26 Apr 2017 12:59:57 +1000 Subject: DHCPv6 relay software with RFC 6939 support In-Reply-To: Your message of "Wed, 26 Apr 2017 12:58:15 +1000." Message-ID: <20170426025957.AEDA76CFF3C1@rock.dv.isc.org> Mark Andrews writes: > > Looking at git repository ISC DHCP 4.3 supports this. Oops missed the word relay. The server does. Not sure about the relay code. > Mark > > In message <53046b17-3d41-5884-fef5-2227e7d66b10 at ifw-dresden.de>, Henri Wahl writes: > > > > Hello world, > > > > does anybody know of an open-source DHCPv6 relay software which supports > > client link-layer option as in RFC 6939? > > > > Thanks and regards > > > > Henri > > > > -- > > Henri Wahl > > > > IT Department > > Leibniz-Institut fuer Festkoerper- u. > > Werkstoffforschung Dresden > > > > tel: +49 (3 51) 46 59 - 797 > > email: h.wahl at ifw-dresden.de > > https://www.ifw-dresden.de > > > > Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de > > > > DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de > > > > S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem > > PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc > > > > IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden > > VR Dresden Nr. 1369 > > Vorstand: Prof. Dr. Burkard Hillebrands, Dr. Doreen Kirmse > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From timlists at tristarcreations.com Wed Apr 26 02:02:18 2017 From: timlists at tristarcreations.com (Tim Embler) Date: Tue, 25 Apr 2017 20:02:18 -0600 Subject: Cogent LA issues Message-ID: <14ef89c9-a604-d599-1399-92f792810211@tristarcreations.com> Recently it seems like anything that travels through te0-7-0-30.ccr41.lax04.atlas.cogentco.com is getting packet-loss and slowness. Is anyone else experiencing this? From junosiosxr at gmail.com Thu Apr 27 13:47:05 2017 From: junosiosxr at gmail.com (root ) Date: Thu, 27 Apr 2017 21:47:05 +0800 Subject: ipv6 accepted & announcement size upto /48 or longer than /48 ? Message-ID: Hi, Am i right ? Policy for ipv4 accept and send upto /24 Policy for ipv6 accept and send upto /48 ------------------------------------------------------------- I confused when i checked the ipv6 prefix at route-view and ntt looking glass. Example : seem like AS2914 accepted the /64 prefix from AS20940 NTT looking output Query Results: Router: Ashburn, VA - US Command: show bgp ipv6 unicast 2001:418:1401:9:: BGP routing table entry for 2001:418:1401:9::/64 Versions: Process bRIB/RIB SendTblVer Speaker 64282538 64282538 Last Modified: Oct 12 13:27:02.644 for 28w1d Paths: (1 available, best #1) Advertised to update-groups (with more than one peer): 0.10 0.28 0.38 0.39 0.40 0.49 Advertised to peers (in unique update groups): 2001:418:0:5000::9bd 2001:418:0:5000::1b7 2001:418:0:5000::fc3 2001:418:0:5000::5b1 Path #1: Received by speaker 0 Advertised to update-groups (with more than one peer): 0.10 0.28 0.38 0.39 0.40 0.49 Advertised to peers (in unique update groups): 2001:418:0:5000::9bd 2001:418:0:5000::1b7 2001:418:0:5000::fc3 2001:418:0:5000::5b1 20940 20940 2001:418:0:5000::419 (metric 5010) from (129.250.0.117) Origin IGP, metric 0, localpref 120, valid, confed-internal, best, group-best Received Path ID 0, Local Path ID 1, version 64282538 Community: 2914:370 2914:1009 2914:2000 2914:3000 20940:411 route-view : 2001:418:0:1000::F016 4 2914 304889 22799 30638084 0 0 1w0d 36959 route-views>show bgp ipv6 un nei 2001:418:0:1000::F016 routes | i /56 *> 2001:218:200E:100::/56 *> 2001:218:200E:200::/56 *> 2001:218:200E:300::/56 *> 2001:218:200E:400::/56 *> 2001:218:3003:100::/56 *> 2001:218:3003:200::/56 *> 2001:418:141B:200::/56 *> 2001:418:141F:100::/56 *> 2001:418:141F:200::/56 *> 2001:418:1420:200::/56 *> 2001:418:1427:100::/56 *> 2001:418:1427:300::/56 *> 2001:418:142A:100::/56 *> 2001:418:142A:300::/56 *> 2001:418:143A:100::/56 *> 2001:418:143B:100::/56 *> 2001:418:1446:100::/56 *> 2001:418:1446:300::/56 *> 2001:418:1456:200::/56 *> 2001:418:1456:A00::/56 *> 2001:418:3801:100::/56 *> 2001:728:2003:100::/56 *> 2600:C0B:2:100::/56 *> 2600:C0B:3010::/56 *> 2600:C0B:3010:200::/56 *> 2607:F360:100:100::/56 route-views>show bgp ipv6 un nei 2001:418:0:1000::F016 routes | i /64 *> 2001:418:1401:1::/64 *> 2001:418:1401:4::/64 *> 2001:418:1401:7::/64 *> 2001:418:1401:9::/64 *> 2001:418:1401:E::/64 *> 2001:418:1401:F::/64 *> 2001:418:1401:98::/64 *> 2001:418:1C01:1::/64 *> 2001:418:3801:3::/64 *> 2001:728:1808:3::/64 *> 2001:728:1808:4::/64 *> 2001:7F8:F::/64 2001:418:0:1000::F016 *> 2001:DF0:1E:4000::/64 *> 2001:DF5:B400::/64 *> 2400:8B00:1000:2::/64 * 2400:8B00:1100:1::/64 *> 2400:ED00::/64 2001:418:0:1000::F016 *> 2401:2700:1::/64 2001:418:0:1000::F016 *> 2407:0:0:1::/64 2001:418:0:1000::F016 *> 2407:0:0:2::/64 2001:418:0:1000::F016 * 2407:0:0:4::/64 2001:418:0:1000::F016 *> 2407:0:0:A::/64 2001:418:0:1000::F016 *> 2407:0:0:12::/64 2001:418:0:1000::F016 *> 2407:0:1000:4::/64 *> 2407:0:1000:8::/64 *> 2607:3E80::/64 2001:418:0:1000::F016 *> 2607:3E80:0:1::/64 *> 2607:3E80:0:2::/64 *> 2607:3E80:0:3::/64 *> 2607:3E80:0:4::/64 *> 2607:3E80:0:5::/64 *> 2607:3E80:0:6::/64 *> 2620:116:B097::/64 *> 2801:80:E0:1800::/64 *> 2801:80:E0:1801::/64 *> 2804:14C:5FF9:3::/64 *> 2804:14C:5FF9:8::/64 *> 2804:14C:87F9:D::/64 *> 2804:14C:87F9:E::/64 *> 2804:14C:9D10:672::/64 *> 2804:14C:DEFF:1::/64 *> 2804:14C:DEFF:4::/64 *> 2804:14D:10F9:1::/64 *> 2804:14D:16F9:5::/64 *> 2804:14D:2AF9:2::/64 *> 2804:14D:3CF9:4::/64 *> 2804:14D:5CF9::/64 *> 2804:14D:5CF9:1::/64 *> 2804:14D:5CF9:4::/64 *> 2804:14D:5CF9:5::/64 *> 2804:14D:5CF9:6::/64 *> 2804:14D:5CF9:A::/64 *> 2804:14D:5CF9:B::/64 *> 2804:14D:5CF9:C::/64 *> 2804:14D:90F9:5::/64 *> 2804:14D:A210:672::/64 *> 2804:14D:A211:672::/64 *> 2804:138B:B040:A2::/64 *> 2804:138B:C040:A2::/64 *> 2A00:5400:3000::/64 *> 2A02:B60::/64 2001:418:0:1000::F016 *> 2A02:B60:0:F::/64 *> 2A02:B60:2000:3::/64 *> 2001:418:1401:9::/64 2001:418:0:1000::F016 10631 0 2914 20940 20940 i route-views>show ipv6 route 2001:418:1401:9::/64 longer-prefixes IPv6 Routing Table - default - 41191 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid a - Application B 2001:418:1401:9::/64 [20/10631] via 2001:418:0:1000::F016 best regards From sethm at rollernet.us Thu Apr 27 16:30:48 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 27 Apr 2017 09:30:48 -0700 Subject: ipv6 accepted & announcement size upto /48 or longer than /48 ? In-Reply-To: References: Message-ID: <2540460d-c325-7c7c-0663-bd20940699ec@rollernet.us> On 4/27/17 06:47, root wrote: > Hi, > > > Am i right ? > > Policy for ipv4 accept and send upto /24 > Policy for ipv6 accept and send upto /48 > > > ------------------------------------------------------------- > > I confused when i checked the ipv6 prefix at route-view and ntt looking > glass. > > Example : seem like AS2914 accepted the /64 prefix from AS20940 Internally, sure. ~Seth From theodore at ciscodude.net Thu Apr 27 16:56:09 2017 From: theodore at ciscodude.net (Theodore Baschak) Date: Thu, 27 Apr 2017 11:56:09 -0500 Subject: ipv6 accepted & announcement size upto /48 or longer than /48 ? In-Reply-To: References: Message-ID: On Thu, Apr 27, 2017 at 8:47 AM, root < junosiosxr at gmail.com> wrote: > Hi, > > > Am i right ? > > Policy for ipv4 accept and send upto /24 > Policy for ipv6 accept and send upto /48 > Sending up to a /24 is an oversimplification in today's post-IPv4 exhaustion world. ARIN now has a "Dedicated IPv4 block to facilitate IPv6 Deployment" (23.128.0.0/10) from which they are may allocate in /24 thru /28 sized blocks. RIPE has tested visibility of longer than /24's and reported on that in 2014 and 2015, both with and without IRR entries. https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes and https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-24-prefixes-changed Theodore Baschak - AS395089 - Hextet Systems https://bgp.guru/ - https://hextet.net/ http://mbix.ca/ - http://mbnog.ca/ From job at ntt.net Thu Apr 27 17:05:12 2017 From: job at ntt.net (Job Snijders) Date: Thu, 27 Apr 2017 19:05:12 +0200 Subject: ipv6 accepted & announcement size upto /48 or longer than /48 ? In-Reply-To: <2540460d-c325-7c7c-0663-bd20940699ec@rollernet.us> References: <2540460d-c325-7c7c-0663-bd20940699ec@rollernet.us> Message-ID: <20170427170512.qr7s4mgocnqgg2cx@hanna.meerval.net> On Thu, Apr 27, 2017 at 09:30:48AM -0700, Seth Mattinen wrote: > On 4/27/17 06:47, root wrote: > > > > Am i right ? > > > > Policy for ipv4 accept and send upto /24 > > Policy for ipv6 accept and send upto /48 > > > > ------------------------------------------------------------- > > > > I confused when i checked the ipv6 prefix at route-view and ntt looking > > glass. > > > > Example : seem like AS2914 accepted the /64 prefix from AS20940 > > Internally, sure. NTT accepts "longer-than-/48" (and similarly "longer-than-/24") prefixes only from customers, if an exact matching route6: or route: object exists in the IRR. NTT will announce such more-specifics to customers, but not to peers. This is useful for customers who want to use NTT's backbone to connect their satellite sites to each other, as an alternative to building out their own backbone. Personally I wouldn't expect global reachability for prefixes longer than /48 or /24, so you'll see that most people make sure a covering announcement also exists. In a controlled environments these more-specifics can be very useful. Kind regards, Job From ml-nanog at techcompute.net Thu Apr 27 18:09:45 2017 From: ml-nanog at techcompute.net (Mitchell Lewis) Date: Thu, 27 Apr 2017 14:09:45 -0400 Subject: Service Provider NMS/OSS Message-ID: <1493316585.1316.4.camel@techcompute.net> Can anyone recommend a NMS/OSS system for a small ISP(Provide Metro-E Type Services, No Residential). I would like it to have both monitoring capablites & service orchestration/provisioning/management capablities if possible. ? Regards, Mitchell T. Lewis MLewis at TechCompute.Net 203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key From nanog at ics-il.net Thu Apr 27 18:11:41 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 27 Apr 2017 13:11:41 -0500 (CDT) Subject: Service Provider NMS/OSS In-Reply-To: <1493316585.1316.4.camel@techcompute.net> References: <1493316585.1316.4.camel@techcompute.net> Message-ID: <1553077011.2923.1493316699779.JavaMail.mhammett@ThunderFuck> The first thing that comes to mind is NetXMS. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mitchell Lewis" To: nanog at nanog.org Sent: Thursday, April 27, 2017 1:09:45 PM Subject: Service Provider NMS/OSS Can anyone recommend a NMS/OSS system for a small ISP(Provide Metro-E Type Services, No Residential). I would like it to have both monitoring capablites & service orchestration/provisioning/management capablities if possible. Regards, Mitchell T. Lewis MLewis at TechCompute.Net 203-816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key From maxtul at netassist.ua Thu Apr 27 18:17:26 2017 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 27 Apr 2017 21:17:26 +0300 Subject: ipv6 accepted & announcement size upto /48 or longer than /48 ? In-Reply-To: References: Message-ID: <590235B6.8070601@netassist.ua> Yes, but that's not a policy, that's a BCP. On 27.04.17 16:47, root wrote: > Am i right ? > > Policy for ipv4 accept and send upto /24 > Policy for ipv6 accept and send upto /48 > From josh at imaginenetworksllc.com Thu Apr 27 19:27:14 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 27 Apr 2017 15:27:14 -0400 Subject: PSN (Playstation Network) security team Message-ID: I'm hoping someone here can reach out to me from the department that deals with automatically blocking IPs. As far as I can tell they're all in the same /24. The phone support is completely worthless in this situation (I'm supposed to change my ISP). Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 From tony at wicks.co.nz Thu Apr 27 20:51:42 2017 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 28 Apr 2017 08:51:42 +1200 Subject: PSN (Playstation Network) security team In-Reply-To: References: Message-ID: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> SNEI-NOC-Abuse at am.sony dot com Good luck with that! Sony is uniquely difficult to deal with when it comes to the arrogance of their "security" people at PSN. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman Sent: Friday, 28 April 2017 7:27 AM To: NANOG list Subject: PSN (Playstation Network) security team I'm hoping someone here can reach out to me from the department that deals with automatically blocking IPs. As far as I can tell they're all in the same /24. The phone support is completely worthless in this situation (I'm supposed to change my ISP). Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 From mlfreita at mtu.edu Thu Apr 27 22:56:19 2017 From: mlfreita at mtu.edu (Matt Freitag) Date: Thu, 27 Apr 2017 18:56:19 -0400 Subject: What services do you control at your org? Message-ID: All, I'm doing an informal survey: - Are you in the networking group? (presumably yes) - What org do you work for? (optional) - What industry is your org in? (ex. Higher Ed) - Does the networking group control your NAC/RADIUS server used for network authentication, DHCP, and/or DNS servers? - "Control" means the networking group does all the configuration, administration, and maintenance of said systems. My answers: - I am in the networking group - I'm at Michigan Technological University - We're in Higher Education - Currently I control the NAC/RADIUS server, but not do DHCP and do minimal stuff with DNS. Mostly adding/removing other domains from our master BIND servers. Thank you for your time!! Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.mtu.edu/it From jwalter at weebly.com Thu Apr 27 23:04:58 2017 From: jwalter at weebly.com (Jeff Walter) Date: Thu, 27 Apr 2017 18:04:58 -0500 Subject: What services do you control at your org? In-Reply-To: References: Message-ID: - I am in operations group which handles networking and systems - Weebly - Websites and commerce - We rule it all: RADIUS, LDAP, DHCP (datacenter only), and DNS -- Jeff Walter Senior Operations Engineer Weebly, Inc On Thu, Apr 27, 2017 at 5:56 PM, Matt Freitag wrote: > All, > > I'm doing an informal survey: > > - Are you in the networking group? (presumably yes) > - What org do you work for? (optional) > - What industry is your org in? (ex. Higher Ed) > - Does the networking group control your NAC/RADIUS server used for > network authentication, DHCP, and/or DNS servers? > - "Control" means the networking group does all the configuration, > administration, and maintenance of said systems. > > My answers: > > - I am in the networking group > - I'm at Michigan Technological University > - We're in Higher Education > - Currently I control the NAC/RADIUS server, but not do DHCP and do > minimal stuff with DNS. Mostly adding/removing other domains from our > master BIND servers. > > Thank you for your time!! > > Matt Freitag > Network Engineer I > Information Technology > Michigan Technological University > (906) 487-3696 <%28906%29%20487-3696> > https://www.mtu.edu/ > https://www.mtu.edu/it > From cscora at apnic.net Fri Apr 14 18:02:43 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Apr 2017 04:02:43 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170428010252.47197BF162@thyme.apnic.net> 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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at 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 15 Apr, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 643601 Prefixes after maximum aggregation (per Origin AS): 250591 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 310784 Total ASes present in the Internet Routing Table: 56864 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49206 Origin ASes announcing only one prefix: 21776 Transit ASes present in the Internet Routing Table: 7658 Transit-only ASes present in the Internet Routing Table: 225 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 76 Numnber of instances of unregistered ASNs: 77 Number of 32-bit ASNs allocated by the RIRs: 18159 Number of 32-bit ASNs visible in the Routing Table: 14096 Prefixes from 32-bit ASNs in the Routing Table: 56945 Number of bogon 32-bit ASNs visible in the Routing Table: 20 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 425 Number of addresses announced to Internet: 2841682052 Equivalent to 169 /8s, 96 /16s and 160 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.5 Total number of prefixes smaller than registry allocations: 214701 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 175737 Total APNIC prefixes after maximum aggregation: 50338 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 174905 Unique aggregates announced from the APNIC address blocks: 72377 APNIC Region origin ASes present in the Internet Routing Table: 7994 APNIC Prefixes per ASN: 21.88 APNIC Region origin ASes announcing only one prefix: 2230 APNIC Region transit ASes present in the Internet Routing Table: 1132 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2841 Number of APNIC addresses announced to Internet: 762799748 Equivalent to 45 /8s, 119 /16s and 102 /24s APNIC AS Blocks 4608-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: 196280 Total ARIN prefixes after maximum aggregation: 93864 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 198554 Unique aggregates announced from the ARIN address blocks: 91059 ARIN Region origin ASes present in the Internet Routing Table: 17876 ARIN Prefixes per ASN: 11.11 ARIN Region origin ASes announcing only one prefix: 6632 ARIN Region transit ASes present in the Internet Routing Table: 1775 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1900 Number of ARIN addresses announced to Internet: 1107869600 Equivalent to 66 /8s, 8 /16s and 191 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 174278 Total RIPE prefixes after maximum aggregation: 84780 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 169683 Unique aggregates announced from the RIPE address blocks: 101754 RIPE Region origin ASes present in the Internet Routing Table: 23917 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11040 RIPE Region transit ASes present in the Internet Routing Table: 3401 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5745 Number of RIPE addresses announced to Internet: 711115904 Equivalent to 42 /8s, 98 /16s and 196 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 80642 Total LACNIC prefixes after maximum aggregation: 17819 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 81837 Unique aggregates announced from the LACNIC address blocks: 38261 LACNIC Region origin ASes present in the Internet Routing Table: 5796 LACNIC Prefixes per ASN: 14.12 LACNIC Region origin ASes announcing only one prefix: 1556 LACNIC Region transit ASes present in the Internet Routing Table: 1057 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3308 Number of LACNIC addresses announced to Internet: 170365664 Equivalent to 10 /8s, 39 /16s and 146 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16577 Total AfriNIC prefixes after maximum aggregation: 3728 AfriNIC Deaggregation factor: 4.45 Prefixes being announced from the AfriNIC address blocks: 18197 Unique aggregates announced from the AfriNIC address blocks: 6963 AfriNIC Region origin ASes present in the Internet Routing Table: 1028 AfriNIC Prefixes per ASN: 17.70 AfriNIC Region origin ASes announcing only one prefix: 318 AfriNIC Region transit ASes present in the Internet Routing Table: 199 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 302 Number of AfriNIC addresses announced to Internet: 89038080 Equivalent to 5 /8s, 78 /16s and 157 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5565 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3737 391 263 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2993 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2802 11150 755 KIXS-AS-KR Korea Telecom, KR 9829 2732 1499 540 BSNL-NIB National Internet Backbone, IN 9808 2198 8698 33 CMNET-GD Guangdong Mobile Communication 45899 2075 1373 114 VNPT-AS-VN VNPT Corp, VN 4755 2070 421 218 TATACOMM-AS TATA Communications formerl 9583 1574 121 542 SIFY-AS-IN Sify Limited, IN 4808 1567 1790 447 CHINA169-BJ China Unicom Beijing Provin Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3693 2969 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3386 1333 83 SHAW - Shaw Communications Inc., CA 18566 2185 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2068 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1986 2107 404 CHARTER-NET-HKY-NC - Charter Communicat 209 1789 5067 636 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1771 3387 566 AMAZON-02 - Amazon.com, Inc., US 30036 1735 321 364 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1685 854 231 ITCDELTA - Earthlink, Inc., US 701 1567 10579 641 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS, SA 8551 3237 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3014 1087 2135 AKAMAI-ASN1, US 9121 2699 1691 17 TTNET, TR 34984 2008 328 384 TELLCOM-AS, TR 13188 1631 99 51 TRIOLAN, UA 12479 1546 1044 52 UNI2-AS, ES 12389 1423 1307 580 ROSTELECOM-AS, RU 9198 1321 352 23 KAZTELECOM-AS, KZ 6849 1252 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3544 546 144 Telmex Colombia S.A., CO 8151 2495 3389 555 Uninet S.A. de C.V., MX 11830 1820 369 57 Instituto Costarricense de Electricidad 7303 1557 1004 247 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1260 377 27 Telefonica del Peru S.A.A., PE 28573 1084 2294 180 CLARO S.A., BR 3816 1021 492 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 1002 280 36 Techtel LMDS Comunicaciones Interactiva 17072 940 118 405 TOTAL PLAY TELECOMUNICACIONES SA DE CV, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1267 399 42 LINKdotNET-AS, EG 36903 716 360 125 MT-MPLS, MA 37611 702 67 6 Afrihost, ZA 36992 624 1375 26 ETISALAT-MISR, EG 24835 497 722 14 RAYA-AS, EG 8452 423 1730 17 TE-AS TE-AS, EG 29571 367 36 10 CITelecom-AS, CI 15399 341 35 7 WANANCHI-, KE 37492 337 307 80 ORANGE-, TN 2018 287 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5565 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3737 391 263 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3693 2969 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3544 546 144 Telmex Colombia S.A., CO 6327 3386 1333 83 SHAW - Shaw Communications Inc., CA 39891 3334 171 18 ALJAWWALSTC-AS, SA 8551 3237 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3014 1087 2135 AKAMAI-ASN1, US 17974 2993 903 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2802 11150 755 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3693 3540 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3737 3474 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3544 3400 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS, SA 6327 3386 3303 SHAW - Shaw Communications Inc., CA 8551 3237 3196 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2993 2921 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2699 2682 TTNET, TR 9829 2732 2192 BSNL-NIB National Internet Backbone, IN 9808 2198 2165 CMNET-GD Guangdong Mobile Communication Co.Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 17.20.16.0/21 8034 WORLDNET5-10 - AT&T WorldNet, 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.172.176.0/21 51269 HEXATOM, FR 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:103 /12:281 /13:544 /14:1047 /15:1836 /16:13428 /17:7574 /18:13395 /19:24681 /20:38368 /21:41318 /22:76060 /23:63224 /24:360268 /25:559 /26:410 /27:323 /28:41 /29:24 /30:25 /31:1 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3177 3386 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS, SA 22773 2858 3693 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2698 3237 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2078 2185 MEGAPATH5-US - MegaPath Corporation, US 9121 1916 2699 TTNET, TR 30036 1540 1735 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1462 3544 Telmex Colombia S.A., CO 6389 1375 2068 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1362 1631 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1601 2:822 4:26 5:2420 6:34 8:1068 12:1831 13:106 14:1795 15:20 16:2 17:116 18:154 19:1 20:56 23:2214 24:1872 25:2 27:2384 31:1893 32:89 33:5 35:20 36:389 37:2540 38:1345 39:45 40:98 41:2911 42:465 43:1913 44:68 45:2539 46:2759 47:117 49:1176 50:974 51:18 52:807 54:360 55:6 56:4 57:41 58:1655 59:1025 60:385 61:1947 62:1532 63:1917 64:4577 65:2208 66:4541 67:2274 68:1196 69:3331 70:1304 71:568 72:2154 74:2643 75:404 76:429 77:1493 78:1681 79:2062 80:1370 81:1409 82:972 83:735 84:876 85:1799 86:484 87:1152 88:805 89:2056 90:168 91:6132 92:1026 93:2391 94:2322 95:2847 96:595 97:359 98:951 99:89 100:156 101:1258 103:14323 104:2815 105:164 106:498 107:1578 108:809 109:3407 110:1334 111:1733 112:1168 113:1293 114:1029 115:1811 116:1776 117:1692 118:2131 119:1585 120:987 121:1097 122:2214 123:1811 124:1536 125:1855 128:747 129:501 130:449 131:1405 132:519 133:190 134:619 135:218 136:518 137:431 138:1894 139:445 140:380 141:538 142:739 143:933 144:770 145:170 146:1032 147:662 148:1372 149:561 150:717 151:949 152:756 153:301 154:799 155:735 156:567 157:612 158:445 159:1447 160:568 161:749 162:2478 163:524 164:787 165:1174 166:394 167:1230 168:2619 169:773 170:3105 171:293 172:999 173:1838 174:813 175:733 176:1829 177:4049 178:2480 179:1113 180:2190 181:1845 182:2300 183:982 184:862 185:9339 186:3222 187:2201 188:2598 189:1794 190:8140 191:1289 192:9384 193:5801 194:4647 195:3843 196:2027 197:1251 198:5562 199:5880 200:7374 201:4099 202:10293 203:9803 204:4481 205:2761 206:3004 207:3125 208:4018 209:3957 210:3975 211:2105 212:2829 213:2489 214:870 215:66 216:5862 217:2075 218:828 219:603 220:1659 221:905 222:763 223:1168 End of report From cscora at apnic.net Fri Apr 21 18:02:35 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Apr 2017 04:02:35 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170428010253.7589FC451E@thyme.apnic.net> 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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at 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 22 Apr, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 644184 Prefixes after maximum aggregation (per Origin AS): 250819 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 311163 Total ASes present in the Internet Routing Table: 56904 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 49231 Origin ASes announcing only one prefix: 21820 Transit ASes present in the Internet Routing Table: 7673 Transit-only ASes present in the Internet Routing Table: 223 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 70 Numnber of instances of unregistered ASNs: 74 Number of 32-bit ASNs allocated by the RIRs: 18233 Number of 32-bit ASNs visible in the Routing Table: 14162 Prefixes from 32-bit ASNs in the Routing Table: 57245 Number of bogon 32-bit ASNs visible in the Routing Table: 43 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 428 Number of addresses announced to Internet: 2842646404 Equivalent to 169 /8s, 111 /16s and 87 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.5 Total number of prefixes smaller than registry allocations: 214966 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 175666 Total APNIC prefixes after maximum aggregation: 50405 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 174863 Unique aggregates announced from the APNIC address blocks: 72537 APNIC Region origin ASes present in the Internet Routing Table: 8009 APNIC Prefixes per ASN: 21.83 APNIC Region origin ASes announcing only one prefix: 2246 APNIC Region transit ASes present in the Internet Routing Table: 1130 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2853 Number of APNIC addresses announced to Internet: 763064964 Equivalent to 45 /8s, 123 /16s and 114 /24s APNIC AS Blocks 4608-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: 196425 Total ARIN prefixes after maximum aggregation: 93953 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 198589 Unique aggregates announced from the ARIN address blocks: 91184 ARIN Region origin ASes present in the Internet Routing Table: 17871 ARIN Prefixes per ASN: 11.11 ARIN Region origin ASes announcing only one prefix: 6632 ARIN Region transit ASes present in the Internet Routing Table: 1780 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1916 Number of ARIN addresses announced to Internet: 1108155040 Equivalent to 66 /8s, 13 /16s and 26 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 174487 Total RIPE prefixes after maximum aggregation: 84856 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 169999 Unique aggregates announced from the RIPE address blocks: 101819 RIPE Region origin ASes present in the Internet Routing Table: 23927 RIPE Prefixes per ASN: 7.10 RIPE Region origin ASes announcing only one prefix: 11042 RIPE Region transit ASes present in the Internet Routing Table: 3397 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5758 Number of RIPE addresses announced to Internet: 711328384 Equivalent to 42 /8s, 102 /16s and 2 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 80518 Total LACNIC prefixes after maximum aggregation: 17806 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 81698 Unique aggregates announced from the LACNIC address blocks: 38300 LACNIC Region origin ASes present in the Internet Routing Table: 5812 LACNIC Prefixes per ASN: 14.06 LACNIC Region origin ASes announcing only one prefix: 1579 LACNIC Region transit ASes present in the Internet Routing Table: 1063 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3326 Number of LACNIC addresses announced to Internet: 170427104 Equivalent to 10 /8s, 40 /16s and 130 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16985 Total AfriNIC prefixes after maximum aggregation: 3743 AfriNIC Deaggregation factor: 4.54 Prefixes being announced from the AfriNIC address blocks: 18607 Unique aggregates announced from the AfriNIC address blocks: 6949 AfriNIC Region origin ASes present in the Internet Routing Table: 1038 AfriNIC Prefixes per ASN: 17.93 AfriNIC Region origin ASes announcing only one prefix: 321 AfriNIC Region transit ASes present in the Internet Routing Table: 209 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 20 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 309 Number of AfriNIC addresses announced to Internet: 89181696 Equivalent to 5 /8s, 80 /16s and 206 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5560 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3774 391 268 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2931 901 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2809 11150 757 KIXS-AS-KR Korea Telecom, KR 9829 2731 1499 539 BSNL-NIB National Internet Backbone, IN 9808 2213 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2077 421 221 TATACOMM-AS TATA Communications formerl 45899 2064 1380 110 VNPT-AS-VN VNPT Corp, VN 9583 1574 121 542 SIFY-AS-IN Sify Limited, IN 7552 1569 1101 55 VIETEL-AS-AP Viettel Corporation, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3702 2969 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3346 1333 80 SHAW - Shaw Communications Inc., CA 18566 2185 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2069 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1989 2108 404 CHARTER-NET-HKY-NC - Charter Communicat 209 1793 5067 635 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1760 3386 564 AMAZON-02 - Amazon.com, Inc., US 30036 1744 322 351 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1692 854 231 ITCDELTA - Earthlink, Inc., US 701 1568 10579 642 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS, SA 8551 3241 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2935 1041 2082 AKAMAI-ASN1, US 9121 2708 1691 18 TTNET, TR 34984 2009 328 386 TELLCOM-AS, TR 13188 1631 99 56 TRIOLAN, UA 12479 1547 1044 52 UNI2-AS, ES 12389 1443 1316 589 ROSTELECOM-AS, RU 9198 1320 352 23 KAZTELECOM-AS, KZ 6849 1254 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3546 547 139 Telmex Colombia S.A., CO 8151 2518 3396 556 Uninet S.A. de C.V., MX 11830 1820 369 57 Instituto Costarricense de Electricidad 7303 1558 1004 248 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1123 377 27 Telefonica del Peru S.A.A., PE 28573 1082 2294 180 CLARO S.A., BR 3816 1022 496 179 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 960 232 91 Techtel LMDS Comunicaciones Interactiva 11172 929 126 80 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1267 399 42 LINKdotNET-AS, EG 36903 715 359 128 MT-MPLS, MA 37611 703 67 6 Afrihost, ZA 36992 624 1375 26 ETISALAT-MISR, EG 24835 497 722 14 RAYA-AS, EG 8452 411 1730 17 TE-AS TE-AS, EG 37492 407 318 73 ORANGE-, TN 29571 367 36 10 CITelecom-AS, CI 15399 342 35 7 WANANCHI-, KE 2018 288 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5560 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3774 391 268 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3702 2969 153 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3546 547 139 Telmex Colombia S.A., CO 6327 3346 1333 80 SHAW - Shaw Communications Inc., CA 39891 3334 171 18 ALJAWWALSTC-AS, SA 8551 3241 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2935 1041 2082 AKAMAI-ASN1, US 17974 2931 901 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2809 11150 757 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3702 3549 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3774 3506 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3546 3407 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS, SA 6327 3346 3266 SHAW - Shaw Communications Inc., CA 8551 3241 3200 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2931 2853 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2708 2690 TTNET, TR 9829 2731 2192 BSNL-NIB National Internet Backbone, IN 9808 2213 2180 CMNET-GD Guangdong Mobile Communication Co.Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.160.128.0/24 64267 -Reserved AS-, ZZ, US 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:103 /12:280 /13:544 /14:1046 /15:1835 /16:13441 /17:7587 /18:13429 /19:24714 /20:38393 /21:41359 /22:76175 /23:63205 /24:360596 /25:558 /26:413 /27:325 /28:41 /29:24 /30:24 /31:1 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3141 3346 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS, SA 22773 2866 3702 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2702 3241 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2078 2185 MEGAPATH5-US - MegaPath Corporation, US 9121 1925 2708 TTNET, TR 30036 1547 1744 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1462 3546 Telmex Colombia S.A., CO 6389 1375 2069 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1362 1631 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1609 2:817 4:26 5:2423 6:34 8:1066 12:1828 13:109 14:1794 15:23 16:2 17:116 18:126 19:1 20:56 23:2217 24:1878 25:2 27:2386 31:1896 32:89 33:5 35:20 36:391 37:2574 38:1347 39:45 40:99 41:3029 42:474 43:1914 44:71 45:2544 46:2751 47:119 49:1187 50:971 51:18 52:804 54:358 55:5 56:4 57:41 58:1611 59:1024 60:385 61:1893 62:1543 63:1919 64:4589 65:2214 66:4552 67:2246 68:1199 69:3335 70:1305 71:568 72:2156 74:2640 75:392 76:428 77:1486 78:1656 79:2068 80:1371 81:1410 82:989 83:731 84:875 85:1812 86:484 87:1154 88:838 89:2059 90:169 91:6145 92:1023 93:2392 94:2322 95:2856 96:597 97:359 98:953 99:89 100:156 101:1261 103:14371 104:2842 105:197 106:499 107:1581 108:811 109:3401 110:1338 111:1735 112:1172 113:1292 114:1041 115:1812 116:1782 117:1701 118:2147 119:1582 120:978 121:1097 122:2226 123:1811 124:1539 125:1840 128:749 129:624 130:449 131:1400 132:516 133:191 134:621 135:219 136:519 137:436 138:1900 139:448 140:380 141:538 142:737 143:950 144:774 145:170 146:1037 147:661 148:1404 149:564 150:712 151:948 152:756 153:301 154:801 155:741 156:576 157:616 158:447 159:1460 160:573 161:748 162:2471 163:523 164:791 165:1176 166:388 167:1235 168:2609 169:783 170:3075 171:297 172:998 173:1844 174:812 175:732 176:1834 177:4005 178:2484 179:1116 180:2170 181:1809 182:2311 183:981 184:859 185:9412 186:3159 187:2206 188:2612 189:1794 190:8070 191:1285 192:9368 193:5790 194:4642 195:3848 196:2055 197:1243 198:5517 199:5868 200:7361 201:4128 202:10266 203:9856 204:4481 205:2747 206:2999 207:3125 208:4006 209:3956 210:3981 211:2128 212:2818 213:2486 214:862 215:66 216:5874 217:2067 218:829 219:604 220:1657 221:906 222:762 223:1175 End of report From colton.conor at gmail.com Fri Apr 28 01:25:57 2017 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 27 Apr 2017 20:25:57 -0500 Subject: SD-WAN for enlightened In-Reply-To: <001401d2b78f$a5b69b60$f123d220$@sdnessentials.com> References: <001401d2b78f$a5b69b60$f123d220$@sdnessentials.com> Message-ID: So who are the big SD-WAN players out there? On Mon, Apr 17, 2017 at 10:31 AM, Doug Marschke wrote: > Hello Kasper, > > I will do my best to answer your SD-WAN question, but as you mentioned it > is a buzzword that has a bit of confusion in its definitions. I would say > that a SD-WAN solution should have the following elements: > > 1.) Ability to manage multiple WAN connection and choose the path based on > user and machine criteria (The Hybrid WAN) > 2.) A controller to manage the polices and operations of the SD-WAN devices > 3.) Analytics on the network and application level > 4.) A software overlay that abstracts and secures the underlying networks > > Currently there are a lot of solutions out there by many vendors. Some do > all of these and some a subset, so it make the landscape a bit confusing. > Lots of times vendors use SD-WAN when they are really just talking about > Hybrid WAN (multiple connections) or WAN optimization. > > > > > > Doug Marschke > CTO > www.sdnessentials.com > JNCIE-SP #41, JNCIE-ENT #3 > 415-902-5702 (cell) > 415-340-3112 (office) > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kasper Adel > Sent: Sunday, April 16, 2017 1:14 PM > To: NANOG list > Subject: SD-WAN for enlightened > > Hi, > > I'm not sure if the buzzword SD-WAN is used to compensate for another > buzzword that got over-utilized (SDN) or it is a true 'new and improved' > way of doing things that has some innovation into it. > > I heard different explanation from different vendors: > > 1) appliances (+ controller) placed in-line to put traffic in tunnels > based on policy, with some DPI and traffic tagging...(to do > performance/policy based routing) over an expensive link (MPLS) and a cheap > one (broadband) with some 'firewall-like' filtering capabilities. > 2) same as above, with a flavor of 'machine learning' to find a pattern > for traffic to optimize utilization. > 3) a controller that instantiates and tears down tunnels from 'classic > routers' based on external policies and Network based features to do > performance based routing over an expensive link (MPLS) and a cheap one > (broadband) with encryption. > > Is the above a decent high-level summary? > > Has anyone tried any of these solutions, any general feedback ? > > Cheers, > Kim > > From john at hypergeek.net Fri Apr 28 04:39:48 2017 From: john at hypergeek.net (John A. Kilpatrick ) Date: Thu, 27 Apr 2017 21:39:48 -0700 Subject: PSN (Playstation Network) security team In-Reply-To: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> References: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> Message-ID: Which is kinda funny when you think about it. -- John A. Kilpatrick john at hypergeek.net Email| http://www.hypergeek.net/ john-page at hypergeek.net Text pages| ICQ: 19147504 remember: no obstacles/only challenges > On Apr 27, 2017, at 1:51 PM, Tony Wicks wrote: > > SNEI-NOC-Abuse at am.sony dot com > > Good luck with that! Sony is uniquely difficult to deal with when it comes to the arrogance of their "security" people at PSN. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman > Sent: Friday, 28 April 2017 7:27 AM > To: NANOG list > Subject: PSN (Playstation Network) security team > > I'm hoping someone here can reach out to me from the department that deals with automatically blocking IPs. As far as I can tell they're all in the same /24. The phone support is completely worthless in this situation (I'm supposed to change my ISP). > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > From trelane at trelane.net Fri Apr 28 04:47:23 2017 From: trelane at trelane.net (Andrew Kirch) Date: Fri, 28 Apr 2017 00:47:23 -0400 Subject: PSN (Playstation Network) security team In-Reply-To: References: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> Message-ID: Arrogance almost always proceeds humiliation. Andrew On Fri, Apr 28, 2017 at 12:39 AM, John A. Kilpatrick wrote: > Which is kinda funny when you think about it. > > -- > John A. Kilpatrick > john at hypergeek.net Email| http://www.hypergeek.net/ > john-page at hypergeek.net Text pages| ICQ: 19147504 > remember: no obstacles/only challenges > > > On Apr 27, 2017, at 1:51 PM, Tony Wicks wrote: > > > > SNEI-NOC-Abuse at am.sony dot com > > > > Good luck with that! Sony is uniquely difficult to deal with when it > comes to the arrogance of their "security" people at PSN. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh Luthman > > Sent: Friday, 28 April 2017 7:27 AM > > To: NANOG list > > Subject: PSN (Playstation Network) security team > > > > I'm hoping someone here can reach out to me from the department that > deals with automatically blocking IPs. As far as I can tell they're all in > the same /24. The phone support is completely worthless in this situation > (I'm supposed to change my ISP). > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > From valdis.kletnieks at vt.edu Fri Apr 28 05:09:46 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 28 Apr 2017 01:09:46 -0400 Subject: PSN (Playstation Network) security team In-Reply-To: References: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> Message-ID: <34795.1493356186@turing-police.cc.vt.edu> On Fri, 28 Apr 2017 00:47:23 -0400, Andrew Kirch said: > Arrogance almost always proceeds humiliation. PSN being the counter-example? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From yuyarin at yuyarin.net Fri Apr 28 01:33:47 2017 From: yuyarin at yuyarin.net (Yuya KAWAKAMI) Date: Fri, 28 Apr 2017 10:33:47 +0900 Subject: ipv6 accepted & announcement size upto /48 or longer than /48 ? In-Reply-To: <590235B6.8070601@netassist.ua> References: <590235B6.8070601@netassist.ua> Message-ID: > As an example, the RIPE community has > documented that, at the time of writing of this document, IPv4 > prefixes longer than /24 and IPv6 prefixes longer than /48 are > generally neither announced nor accepted in the Internet [20] [21]. https://tools.ietf.org/html/bcp194 On 4/28/17 3:17 AM, Max Tulyev wrote: > Yes, but that's not a policy, that's a BCP. > > On 27.04.17 16:47, root wrote: >> Am i right ? >> >> Policy for ipv4 accept and send upto /24 >> Policy for ipv6 accept and send upto /48 >> > From aaron1 at gvtc.com Fri Apr 28 15:44:28 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 28 Apr 2017 10:44:28 -0500 Subject: PSN (Playstation Network) security team In-Reply-To: References: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> Message-ID: <002101d2c036$52868400$f7938c00$@gvtc.com> That's a good word Andrew -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andrew Kirch Sent: Thursday, April 27, 2017 11:47 PM To: John A. Kilpatrick Cc: NANOG list Subject: Re: PSN (Playstation Network) security team Arrogance almost always proceeds humiliation. Andrew On Fri, Apr 28, 2017 at 12:39 AM, John A. Kilpatrick wrote: > Which is kinda funny when you think about it. > > -- > John A. Kilpatrick > john at hypergeek.net Email| http://www.hypergeek.net/ > john-page at hypergeek.net Text pages| ICQ: 19147504 > remember: no obstacles/only challenges > > > On Apr 27, 2017, at 1:51 PM, Tony Wicks wrote: > > > > SNEI-NOC-Abuse at am.sony dot com > > > > Good luck with that! Sony is uniquely difficult to deal with when it > comes to the arrogance of their "security" people at PSN. > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh > > Luthman > > Sent: Friday, 28 April 2017 7:27 AM > > To: NANOG list > > Subject: PSN (Playstation Network) security team > > > > I'm hoping someone here can reach out to me from the department that > deals with automatically blocking IPs. As far as I can tell they're > all in the same /24. The phone support is completely worthless in > this situation (I'm supposed to change my ISP). > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > From justin at cloudflare.com Fri Apr 28 17:27:35 2017 From: justin at cloudflare.com (Justin Paine) Date: Fri, 28 Apr 2017 10:27:35 -0700 Subject: PSN (Playstation Network) security team In-Reply-To: <002101d2c036$52868400$f7938c00$@gvtc.com> References: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> <002101d2c036$52868400$f7938c00$@gvtc.com> Message-ID: Sounds like you already received a reply. ____________ Justin Paine Head of Trust & Safety Cloudflare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Fri, Apr 28, 2017 at 8:44 AM, Aaron Gould wrote: > That's a good word Andrew > > -Aaron > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andrew Kirch > Sent: Thursday, April 27, 2017 11:47 PM > To: John A. Kilpatrick > Cc: NANOG list > Subject: Re: PSN (Playstation Network) security team > > Arrogance almost always proceeds humiliation. > > Andrew > > On Fri, Apr 28, 2017 at 12:39 AM, John A. Kilpatrick > wrote: > >> Which is kinda funny when you think about it. >> >> -- >> John A. Kilpatrick >> john at hypergeek.net Email| http://www.hypergeek.net/ >> john-page at hypergeek.net Text pages| ICQ: 19147504 >> remember: no obstacles/only challenges >> >> > On Apr 27, 2017, at 1:51 PM, Tony Wicks wrote: >> > >> > SNEI-NOC-Abuse at am.sony dot com >> > >> > Good luck with that! Sony is uniquely difficult to deal with when it >> comes to the arrogance of their "security" people at PSN. >> > >> > >> > >> > -----Original Message----- >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh >> > Luthman >> > Sent: Friday, 28 April 2017 7:27 AM >> > To: NANOG list >> > Subject: PSN (Playstation Network) security team >> > >> > I'm hoping someone here can reach out to me from the department that >> deals with automatically blocking IPs. As far as I can tell they're >> all in the same /24. The phone support is completely worthless in >> this situation (I'm supposed to change my ISP). >> > >> > Josh Luthman >> > Office: 937-552-2340 >> > Direct: 937-552-2343 >> > 1100 Wayne St >> > Suite 1337 >> > Troy, OH 45373 >> > >> > From josh at imaginenetworksllc.com Fri Apr 28 17:32:57 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 28 Apr 2017 13:32:57 -0400 Subject: PSN (Playstation Network) security team In-Reply-To: References: <002b01d2bf98$14e9da50$3ebd8ef0$@wicks.co.nz> <002101d2c036$52868400$f7938c00$@gvtc.com> Message-ID: If you're referring to me, yes. I received a message from a person in the last few minutes and before that what I understand now is an automated message. I was told they use the ARIN Abuse contact for automated notification. The job runs daily (I got mine around 9PM Eastern yesterday) and will batch IP addresses. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Apr 28, 2017 at 1:27 PM, Justin Paine via NANOG wrote: > Sounds like you already received a reply. > > ____________ > Justin Paine > Head of Trust & Safety > Cloudflare Inc. > PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D > > > On Fri, Apr 28, 2017 at 8:44 AM, Aaron Gould wrote: > > That's a good word Andrew > > > > -Aaron > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andrew Kirch > > Sent: Thursday, April 27, 2017 11:47 PM > > To: John A. Kilpatrick > > Cc: NANOG list > > Subject: Re: PSN (Playstation Network) security team > > > > Arrogance almost always proceeds humiliation. > > > > Andrew > > > > On Fri, Apr 28, 2017 at 12:39 AM, John A. Kilpatrick > > > wrote: > > > >> Which is kinda funny when you think about it. > >> > >> -- > >> John A. Kilpatrick > >> john at hypergeek.net Email| http://www.hypergeek.net/ > >> john-page at hypergeek.net Text pages| ICQ: 19147504 > >> remember: no obstacles/only challenges > >> > >> > On Apr 27, 2017, at 1:51 PM, Tony Wicks wrote: > >> > > >> > SNEI-NOC-Abuse at am.sony dot com > >> > > >> > Good luck with that! Sony is uniquely difficult to deal with when it > >> comes to the arrogance of their "security" people at PSN. > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Josh > >> > Luthman > >> > Sent: Friday, 28 April 2017 7:27 AM > >> > To: NANOG list > >> > Subject: PSN (Playstation Network) security team > >> > > >> > I'm hoping someone here can reach out to me from the department that > >> deals with automatically blocking IPs. As far as I can tell they're > >> all in the same /24. The phone support is completely worthless in > >> this situation (I'm supposed to change my ISP). > >> > > >> > Josh Luthman > >> > Office: 937-552-2340 > >> > Direct: 937-552-2343 > >> > 1100 Wayne St > >> > Suite 1337 > >> > Troy, OH 45373 > >> > > >> > > > From cscora at apnic.net Fri Apr 28 18:02:44 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Apr 2017 04:02:44 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170428180244.F2F0BC44D5@thyme.apnic.net> 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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at 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 29 Apr, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 646390 Prefixes after maximum aggregation (per Origin AS): 251692 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 311592 Total ASes present in the Internet Routing Table: 57001 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 49321 Origin ASes announcing only one prefix: 21825 Transit ASes present in the Internet Routing Table: 7680 Transit-only ASes present in the Internet Routing Table: 222 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 74 Numnber of instances of unregistered ASNs: 78 Number of 32-bit ASNs allocated by the RIRs: 18344 Number of 32-bit ASNs visible in the Routing Table: 14244 Prefixes from 32-bit ASNs in the Routing Table: 57829 Number of bogon 32-bit ASNs visible in the Routing Table: 45 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 407 Number of addresses announced to Internet: 2843747684 Equivalent to 169 /8s, 128 /16s and 37 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.6 Total number of prefixes smaller than registry allocations: 216443 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 176775 Total APNIC prefixes after maximum aggregation: 50902 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 175973 Unique aggregates announced from the APNIC address blocks: 72665 APNIC Region origin ASes present in the Internet Routing Table: 8043 APNIC Prefixes per ASN: 21.88 APNIC Region origin ASes announcing only one prefix: 2234 APNIC Region transit ASes present in the Internet Routing Table: 1131 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2872 Number of APNIC addresses announced to Internet: 763129956 Equivalent to 45 /8s, 124 /16s and 112 /24s APNIC AS Blocks 4608-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: 197199 Total ARIN prefixes after maximum aggregation: 94115 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 199330 Unique aggregates announced from the ARIN address blocks: 91347 ARIN Region origin ASes present in the Internet Routing Table: 17884 ARIN Prefixes per ASN: 11.15 ARIN Region origin ASes announcing only one prefix: 6629 ARIN Region transit ASes present in the Internet Routing Table: 1777 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1934 Number of ARIN addresses announced to Internet: 1108813216 Equivalent to 66 /8s, 23 /16s and 37 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 174650 Total RIPE prefixes after maximum aggregation: 84962 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 170192 Unique aggregates announced from the RIPE address blocks: 101899 RIPE Region origin ASes present in the Internet Routing Table: 23955 RIPE Prefixes per ASN: 7.10 RIPE Region origin ASes announcing only one prefix: 11054 RIPE Region transit ASes present in the Internet Routing Table: 3394 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5776 Number of RIPE addresses announced to Internet: 711734144 Equivalent to 42 /8s, 108 /16s and 51 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 80565 Total LACNIC prefixes after maximum aggregation: 17881 LACNIC Deaggregation factor: 4.51 Prefixes being announced from the LACNIC address blocks: 81773 Unique aggregates announced from the LACNIC address blocks: 38374 LACNIC Region origin ASes present in the Internet Routing Table: 5834 LACNIC Prefixes per ASN: 14.02 LACNIC Region origin ASes announcing only one prefix: 1589 LACNIC Region transit ASes present in the Internet Routing Table: 1080 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3350 Number of LACNIC addresses announced to Internet: 170401248 Equivalent to 10 /8s, 40 /16s and 29 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 17093 Total AfriNIC prefixes after maximum aggregation: 3769 AfriNIC Deaggregation factor: 4.54 Prefixes being announced from the AfriNIC address blocks: 18715 Unique aggregates announced from the AfriNIC address blocks: 6955 AfriNIC Region origin ASes present in the Internet Routing Table: 1035 AfriNIC Prefixes per ASN: 18.08 AfriNIC Region origin ASes announcing only one prefix: 319 AfriNIC Region transit ASes present in the Internet Routing Table: 207 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 312 Number of AfriNIC addresses announced to Internet: 89192448 Equivalent to 5 /8s, 80 /16s and 248 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5569 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3781 392 270 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2931 901 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2762 11150 758 KIXS-AS-KR Korea Telecom, KR 9829 2731 1498 548 BSNL-NIB National Internet Backbone, IN 9808 2210 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2075 421 221 TATACOMM-AS TATA Communications formerl 45899 1985 1388 110 VNPT-AS-VN VNPT Corp, VN 7552 1576 1101 55 VIETEL-AS-AP Viettel Corporation, VN 9583 1573 121 541 SIFY-AS-IN Sify Limited, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 4008 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3364 1333 80 SHAW - Shaw Communications Inc., CA 18566 2184 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2069 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1998 2139 409 CHARTER-NET-HKY-NC - Charter Communicat 209 1794 5067 635 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1771 3420 571 AMAZON-02 - Amazon.com, Inc., US 30036 1747 322 341 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1691 854 230 ITCDELTA - Earthlink, Inc., US 701 1568 10579 640 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3240 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2892 1014 2071 AKAMAI-ASN1, US 9121 2660 1691 17 TTNET, TR 34984 2011 328 386 TELLCOM-AS, TR 13188 1602 99 56 TRIOLAN, UA 12479 1562 1044 52 UNI2-AS, ES 12389 1479 1357 612 ROSTELECOM-AS, RU 9198 1323 352 25 KAZTELECOM-AS, KZ 6849 1226 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3535 544 172 Telmex Colombia S.A., CO 8151 2520 3396 564 Uninet S.A. de C.V., MX 11830 1819 369 57 Instituto Costarricense de Electricidad 7303 1557 1005 247 Telecom Argentina S.A., AR 6503 1540 437 53 Axtel, S.A.B. de C.V., MX 6147 1266 377 27 Telefonica del Peru S.A.A., PE 28573 1081 2286 179 CLARO S.A., BR 3816 1017 494 187 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 956 232 91 Techtel LMDS Comunicaciones Interactiva 11172 929 126 80 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1271 398 44 LINKdotNET-AS, EG 36903 715 359 128 MT-MPLS, MA 37611 704 67 7 Afrihost, ZA 36992 625 1375 26 ETISALAT-MISR, EG 24835 498 722 14 RAYA-AS, EG 8452 412 1730 17 TE-AS TE-AS, EG 37492 408 319 74 ORANGE-, TN 29571 367 36 10 CITelecom-AS, CI 15399 346 35 7 WANANCHI-, KE 2018 287 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5569 4190 74 ERX-CERNET-BKB China Education and Rese 22773 4008 2969 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3781 392 270 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3535 544 172 Telmex Colombia S.A., CO 6327 3364 1333 80 SHAW - Shaw Communications Inc., CA 39891 3338 187 22 ALJAWWALSTC-AS, SA 8551 3240 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 17974 2931 901 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2892 1014 2071 AKAMAI-ASN1, US 4766 2762 11150 758 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 4008 3856 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3781 3511 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3535 3363 Telmex Colombia S.A., CO 39891 3338 3316 ALJAWWALSTC-AS, SA 6327 3364 3284 SHAW - Shaw Communications Inc., CA 8551 3240 3199 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 17974 2931 2853 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2660 2643 TTNET, TR 9829 2731 2183 BSNL-NIB National Internet Backbone, IN 9808 2210 2177 CMNET-GD Guangdong Mobile Communication Co.Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 205948 UNALLOCATED 5.1.77.0/24 34549 MEER-AS meerfarbig GmbH & Co. 65500 PRIVATE 5.140.202.0/24 31094 TTKNET Tyumen, Russia, RU 65500 PRIVATE 5.140.203.0/24 31094 TTKNET Tyumen, Russia, RU 65500 PRIVATE 5.141.238.0/24 31094 TTKNET Tyumen, Russia, RU 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.161.128.0/17 393899 -Reserved AS-, ZZ 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 203496 AB-TELECOM, RU 41.77.248.0/21 203496 AB-TELECOM, RU 41.78.12.0/23 203496 AB-TELECOM, RU 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.242.132.0/23 203496 AB-TELECOM, RU 43.224.140.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.141.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - 43.224.142.0/24 38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited - Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:15 /9:13 /10:36 /11:103 /12:280 /13:545 /14:1042 /15:1838 /16:13455 /17:7600 /18:13417 /19:24699 /20:38377 /21:41346 /22:76410 /23:63518 /24:361488 /25:841 /26:618 /27:631 /28:41 /29:24 /30:25 /31:1 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 3163 4008 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 6327 3158 3364 SHAW - Shaw Communications Inc., CA 39891 2898 3338 ALJAWWALSTC-AS, SA 8551 2702 3240 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2077 2184 MEGAPATH5-US - MegaPath Corporation, US 9121 1907 2660 TTNET, TR 30036 1550 1747 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1463 3535 Telmex Colombia S.A., CO 6389 1375 2069 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1344 1602 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1606 2:820 4:26 5:2430 6:34 8:1071 12:1833 13:114 14:1786 15:26 16:2 17:120 18:120 19:1 20:56 23:2229 24:1874 25:2 27:2394 31:1899 32:89 33:6 35:20 36:395 37:2577 38:1354 39:44 40:98 41:3064 42:464 43:1916 44:71 45:2553 46:2753 47:119 49:1183 50:975 51:18 52:805 54:359 55:6 56:4 57:41 58:1586 59:1036 60:386 61:1907 62:1541 63:1922 64:4592 65:2213 66:4567 67:2258 68:1232 69:3334 70:1318 71:568 72:2194 74:2654 75:392 76:428 77:1444 78:1662 79:2070 80:1378 81:1415 82:995 83:758 84:875 85:1804 86:484 87:1156 88:836 89:2075 90:169 91:6158 92:1008 93:2357 94:2325 95:2862 96:594 97:359 98:1001 99:89 100:156 101:1261 103:14502 104:2845 105:180 106:498 107:1616 108:811 109:3413 110:1332 111:1741 112:1172 113:1219 114:1036 115:1784 116:1782 117:1710 118:2152 119:1584 120:1000 121:1101 122:2235 123:1803 124:1538 125:1879 128:737 129:625 130:437 131:1377 132:515 133:190 134:620 135:220 136:515 137:431 138:1924 139:455 140:372 141:562 142:737 143:955 144:778 145:169 146:1039 147:660 148:1383 149:565 150:715 151:957 152:759 153:297 154:795 155:745 156:580 157:622 158:449 159:1462 160:578 161:751 162:2484 163:524 164:790 165:1215 166:385 167:1237 168:2620 169:775 170:3130 171:299 172:979 173:1852 174:825 175:734 176:1833 177:4028 178:2456 179:1136 180:2169 181:1844 182:2319 183:983 184:847 185:9506 186:3191 187:2203 188:2640 189:1785 190:8117 191:1307 192:9388 193:5788 194:4650 195:3851 196:2064 197:1264 198:5513 199:5873 200:7272 201:4066 202:10349 203:9862 204:4475 205:2810 206:3008 207:3127 208:4020 209:3983 210:3968 211:2130 212:2794 213:2494 214:873 215:65 216:5895 217:2075 218:833 219:605 220:1652 221:909 222:760 223:1174 End of report From florin at andrei.myip.org Fri Apr 28 19:11:27 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 28 Apr 2017 12:11:27 -0700 Subject: AWS us-west-2 routed through Europe from NY? Message-ID: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> I've seen a few strange instances where IP addresses in the AWS us-west-2 region (Oregon) are routed through Europe if you start the traceroute from some providers in the northern East Coast (Quebec, New York). Any idea what's going on? I assume it's temporary. -- Florin Andrei http://florin.myip.org/ From niels=nanog at bakker.net Fri Apr 28 20:28:20 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 28 Apr 2017 22:28:20 +0200 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> Message-ID: <20170428202820.GI86663@excession.tpb.net> * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 CEST]: >I've seen a few strange instances where IP addresses in the AWS >us-west-2 region (Oregon) are routed through Europe if you start the >traceroute from some providers in the northern East Coast (Quebec, >New York). Any idea what's going on? I assume it's temporary. Can you be a little bit more vague in your problem description? While ommitting the source networks from where you tried, you still included the destination. The list expects better. -- Niels. From florin at andrei.myip.org Fri Apr 28 20:33:38 2017 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 28 Apr 2017 13:33:38 -0700 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: <20170428202820.GI86663@excession.tpb.net> References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> <20170428202820.GI86663@excession.tpb.net> Message-ID: <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> On 2017-04-28 13:28, Niels Bakker wrote: > * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 CEST]: >> I've seen a few strange instances where IP addresses in the AWS >> us-west-2 region (Oregon) are routed through Europe if you start the >> traceroute from some providers in the northern East Coast (Quebec, New >> York). Any idea what's going on? I assume it's temporary. > > Can you be a little bit more vague in your problem description? While > ommitting the source networks from where you tried, you still included > the destination. The list expects better. Sorry. Here's one source: 104.163.180.188 -- Florin Andrei http://florin.myip.org/ From amitchell at isipp.com Sat Apr 29 17:02:15 2017 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Sat, 29 Apr 2017 11:02:15 -0600 Subject: New Trusted Reporters list In-Reply-To: <100.2894020055beeb58.002@comkal.com.au> References: <1A3EE8CC-0C75-4389-836B-540F95EA3CFD@mailchimp.com> <3CF33F49-B1E8-43EA-B7B8-4FB60E9B3CC1@isipp.com> <100.2894020055beeb58.002@comkal.com.au> Message-ID: <5ED4920B-FEAB-49B1-AA65-D25B1C2E2EE4@isipp.com> All, Over on another email admin list, a discussion when a participant posted a spam sample, and was told "this isn't the place to post spam samples", led to our forming a private, confidential group where people *can* share spam samples, and discuss related matters. So, we have created that list, which we are calling the Trusted Reporters list. TR is *not* a list for reporting spam *to abuse desks*. It is *not* intended as a list where one could say "so and so is spamming me from $ISP" and someone from $ISP would look into it (although of course if they are on the list, I suppose that they could). TR is *not* a public list where one can publicly post spam. It is, again, a private, confidential list of trusted reporters, for the purpose of discussing spam seen in the wild, ways of dealing with it, and related issues. For example, I have routinely been receiving spam from, among others, Ezoic and planetdatabase.com. I *do* report them, but given that the are sending through places like Google and Amazon AWS it's been useful in this endeavor that at least one colleague has also taken an interest in it. TR *is* a list for those who are interested in learning about the sources of spam when they trust the person who is reporting that information. They can do with that information what they will. TR is a confidential, private list for email *receivers* and *hosts*, and others in the anti-abuse industries. So ISPs, ESPs, spam filters, blacklists, etc.. TR is *not* a list for primary senders. So, if you want to be part of this private, confidential list to report and discuss spam, and related matters, send a note to: trustedreporters-request at isipp.com with 'subscribe' in the subject line. Please include in your subscribe request your name, a bit about yourself and your role in email anti-abuse (this is a list for email receivers and others on the email receiver side of the industry (as compared to primarily email senders)), and that you are from NANOG. Anne Anne P. Mitchell, Attorney at Law Legislative Consultant CEO/President, Institute for Social Internet Public Policy Member, California Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Member, Board of Directors, Greenwood Wildlife Rehabilitation Center Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From phil at phil-mcguire.com Sat Apr 29 00:05:23 2017 From: phil at phil-mcguire.com (Phillip McGuire) Date: Fri, 28 Apr 2017 17:05:23 -0700 Subject: AWS us-west-2 routed through Europe from NY? In-Reply-To: <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> References: <5790aefa181b0a4a85f2d0a525ecc322@andrei.myip.org> <20170428202820.GI86663@excession.tpb.net> <49ce5fcdbaaf94e981ce61fd72b63445@andrei.myip.org> Message-ID: Hey Florin, Do you have a traceroute showing the issue? FYI, you can test against any of the IPs listed here under US-West-2, they all respond to ICMP requests. http://ec2-reachability.amazonaws.com/ -Phil On Fri, Apr 28, 2017 at 1:33 PM, Florin Andrei wrote: > On 2017-04-28 13:28, Niels Bakker wrote: > >> * florin at andrei.myip.org (Florin Andrei) [Fri 28 Apr 2017, 21:12 CEST]: >> >>> I've seen a few strange instances where IP addresses in the AWS >>> us-west-2 region (Oregon) are routed through Europe if you start the >>> traceroute from some providers in the northern East Coast (Quebec, New >>> York). Any idea what's going on? I assume it's temporary. >>> >> >> Can you be a little bit more vague in your problem description? While >> ommitting the source networks from where you tried, you still included >> the destination. The list expects better. >> > > Sorry. Here's one source: 104.163.180.188 > > > -- > Florin Andrei > http://florin.myip.org/ > From large.hadron.collider at gmx.com Sun Apr 30 06:53:23 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Sat, 29 Apr 2017 23:53:23 -0700 Subject: What services do you control at your org? In-Reply-To: References: Message-ID: <4CFFDDB6-C2B1-4329-9F37-6968EDE9C7FA@gmx.com> I'm a teenager. For my personal systems, the answers are: I am the networking group, but my work is nonexistent. Myself. NEETery. I'm mostly concerned with maintaining the white noise generators. And since I am talking about my personal systems, yes. On April 27, 2017 3:56:19 PM PDT, Matt Freitag wrote: >All, > >I'm doing an informal survey: > > - Are you in the networking group? (presumably yes) > - What org do you work for? (optional) > - What industry is your org in? (ex. Higher Ed) > - Does the networking group control your NAC/RADIUS server used for > network authentication, DHCP, and/or DNS servers? > - "Control" means the networking group does all the configuration, > administration, and maintenance of said systems. > >My answers: > > - I am in the networking group > - I'm at Michigan Technological University > - We're in Higher Education > - Currently I control the NAC/RADIUS server, but not do DHCP and do > minimal stuff with DNS. Mostly adding/removing other domains from our > master BIND servers. > >Thank you for your time!! > >Matt Freitag >Network Engineer I >Information Technology >Michigan Technological University >(906) 487-3696 <%28906%29%20487-3696> >https://www.mtu.edu/ >https://www.mtu.edu/it -- Sent from my Android device with K-9 Mail. Please excuse my brevity.