From emile.aben at ripe.net Wed Apr 1 07:22:04 2015 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 01 Apr 2015 09:22:04 +0200 Subject: Usage data from Turkey In-Reply-To: <20150331172422.GA12990@puck.nether.net> References: <20150331172422.GA12990@puck.nether.net> Message-ID: <551B9C9C.7070208@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/03/15 19:24, Jared Mauch wrote: > On Tue, Mar 31, 2015 at 08:19:11PM +0300, Mehmet Akcin wrote: >> Hello >> >> Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a >> major power outage impacting nearly 70M people. I am writing a >> blog post about power outage vs impact to network usage. I am >> looking for as much as useful network usage information possible >> related to Turkey. >> > > You may want to look at the RIPE Atlas project, they jsut did a > similar thing on the power outage in The Netherlands. Density of RIPE Atlas probes in Turkey is quite low, probably too low to do something useful with: http://sg-pub.ripe.net/emile/turkey-atlas.pdf 7 probes disconnect at the same time around 7:30-ish UTC and number of probes returns to baselevel around 15:00 UTC. cheers, Emile > > - Jared > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVG5ycAAoJEKxthF6wloMO5lsP/AwWxIar7LEMq6vlBdza/oJh v3hXVf6EmWG2GKv7eHEWVgBmq3+EXQpCq4XxqfZVnyL7jjpj8RIHhKYoXrkDR+bP ktVQxZL3i0XnGHbtcpdlo97LEmTzL1k5H25LxalkJKUAb96Cughrzano9JEuss39 5EHfOms6fG6sLx2im2fUtqve5e3OQLkognf/Vur1Sq/htTF9wpwViE2YUBlxHhcK Wlzq5Fjv55eycIVJAvnQqLRhjwhhJJqSZYwwSOTT6p7rmpoVmv4N5SvFylcqgcIh zME1fs1YPvny4mD51NYXNZfjCuXfbSkbe0eHIKWJkZN1Lk8au0MV+kPLf7x3hRt9 smn7IkJrnb0tVO3IamVq2o/8ENRQWfXRlAp0A7Rwr7aaLZ4KGqSFZZ2LVGNDP+9i AS6JNdpwYoFRLEguAnhzVfppQ6LHf7ZHuDmEWn5xSArafcpeasYaOyI79R+kER9E A+IdXL3cUEKm4/uhr22jDybCMXPQ94mLoTqiG7zbRQ5YGmkTQNkoZxh51LmcZ+0J AY4UeNtX0bscIEp3/lZpV75+spVtqz2BzKqxT4TdeBn4EZArmM2yJHHAh2bB9Jdm aaYmNoMoaaQhq3jy4cPtoUhM4J5zuq58pDIJK7T/QmNNBLhCLtnv8h4E4EjFttOk 70xd1Lu2YwNsG9qW5Wwp =BRjq -----END PGP SIGNATURE----- From martijnschmidt at i3d.net Wed Apr 1 08:50:30 2015 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Wed, 01 Apr 2015 10:50:30 +0200 Subject: Experience Brocade ICX7750 and other vendor SFP Message-ID: <551BB156.5040509@i3d.net> Hello, Brandon Martin , 31/3/2015 10:07 PM: I'm not sure where the VDX line ends up in this. It's apparently somewhat the result of actually merging the two technology lines, and it runs somewhat different software as a result. The VDX was AFAIK already in development before Brocade bought Foundry, which is further backed up by the fact that in e.g. FlexOptix's transceiver re-programming tool you have to select a "Brocade Storage" firmware for those transceivers rather than the "Brocade IP" firmware used for Foundry-like gear. It is however true that Brocade has since ported over a lot of Foundry features to the VDX platform. As for optics: it will work well (read: interface comes up and passes traffic) with most other-vendor transceivers even if you don't re-program, but like the Foundry-lineage kit you lose light level monitoring when the firmware doesn't match. Best regards, Martijn Schmidt http://www.i3D.net i3D.net is a private company registered in The Netherlands at Meent 93b, Rotterdam. Registration #: 14074337 - VAT # NL 8202.63.886.B01. i3D.net is CDSA certified on Content Protection and Security and provides hosting from 16 global ISO-certified datacenters. We are ranked in the Deloitte Technology Fast 500 EMEA as one of the fastest growing technology companies. From piotr.1234 at interia.pl Wed Apr 1 08:56:12 2015 From: piotr.1234 at interia.pl (Piotr) Date: Wed, 01 Apr 2015 10:56:12 +0200 Subject: From Europe to Australia via right way In-Reply-To: References: Message-ID: <551BB2AC.2070103@interia.pl> Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. thanks for some info, contact. Piotr From piotr.1234 at interia.pl Wed Apr 1 10:14:18 2015 From: piotr.1234 at interia.pl (Piotr) Date: Wed, 01 Apr 2015 12:14:18 +0200 Subject: From Europe to Australia via right way Message-ID: <551BC4FA.2050207@interia.pl> Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. thanks for some info, contact. Piotr From maxtul at netassist.ua Wed Apr 1 10:34:15 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 01 Apr 2015 13:34:15 +0300 Subject: Usage data from Turkey In-Reply-To: References: Message-ID: <551BC9A7.2090802@netassist.ua> Hello, may be a bit off-topic, but which major Internet Exchange points are in Tukrey? I can't google it. On 03/31/15 20:19, Mehmet Akcin wrote: > Hello > > Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power outage impacting nearly 70M people. I am writing a blog post about power outage vs impact to network usage. I am looking for as much as useful network usage information possible related to Turkey. > > If you can share network usage information, i will be making sure to buy you some drinks at next nanog ;) > > Cheers > > Mehmet > From shawnl at up.net Wed Apr 1 15:05:16 2015 From: shawnl at up.net (Shawn L) Date: Wed, 1 Apr 2015 11:05:16 -0400 Subject: Charter NOC contact? Message-ID: Can someone from Charter's NOC contact me off list? We have a mutual customer who's having issues and not getting anywhere going through normal channels. thanks From mkamal at noor.net Wed Apr 1 16:51:54 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Wed, 01 Apr 2015 19:51:54 +0300 Subject: PoC for shortlisted DDoS Vendors Message-ID: <551C222A.6080004@noor.net> In our effort to pick up a reasonably priced DDoS appliance with a competitive features, we're in a process of doing a PoC for the following shortlisted vendors: 1- RioRey 2- NSFocus 3- Arbor 4- A10 The setup will be inline. So it would be great if anyone have done this before and can help provide the appropriate tools, advices, or the testing documents for efficient PoC. Thanks. -- Mohamed Kamal Core Network Sr. Engineer From lists at sadiqs.com Wed Apr 1 21:18:42 2015 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 01 Apr 2015 17:18:42 -0400 Subject: RFC 7511 - Scenic Routing for IPv6 Message-ID: <551C60B2.2040906@sadiqs.com> Informational of course. :) https://tools.ietf.org/html/rfc7511 -- Sadiq Saif https://staticsafe.ca From joelja at bogus.com Wed Apr 1 21:51:32 2015 From: joelja at bogus.com (joel jaeggli) Date: Wed, 1 Apr 2015 14:51:32 -0700 Subject: From Europe to Australia via right way In-Reply-To: <551BC4FA.2050207@interia.pl> References: <551BC4FA.2050207@interia.pl> Message-ID: <551C6864.5030604@bogus.com> On 4/1/15 3:14 AM, Piotr wrote: > Hello, > > There is some telecom, isp which have route from EU to AU via east or > south east (via Russia, Red sea or other ways) ? Now i have path via US > and looking something in opposite direction. telstra ntt reliance retn all have eastbound paths from europe. > thanks for some info, contact. > Piotr > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From kenneth.mcrae at me.com Wed Apr 1 21:56:40 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Wed, 01 Apr 2015 21:56:40 +0000 (GMT) Subject: PoC for shortlisted DDoS Vendors Message-ID: <936bdd37-02ef-4448-a23d-af46ca6d90cb@me.com> Why aren't you also looking at Hauwei? On Apr 01, 2015, at 09:53 AM, Mohamed Kamal wrote: In our effort to pick up a reasonably priced DDoS appliance with a competitive features, we're in a process of doing a PoC for the following shortlisted vendors: 1- RioRey 2- NSFocus 3- Arbor 4- A10 The setup will be inline. So it would be great if anyone have done this before and can help provide the appropriate tools, advices, or the testing documents for efficient PoC. Thanks. -- Mohamed Kamal Core Network Sr. Engineer From Valdis.Kletnieks at vt.edu Wed Apr 1 22:28:47 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 01 Apr 2015 18:28:47 -0400 Subject: RFC 7511 - Scenic Routing for IPv6 In-Reply-To: Your message of "Wed, 01 Apr 2015 17:18:42 -0400." <551C60B2.2040906@sadiqs.com> References: <551C60B2.2040906@sadiqs.com> Message-ID: <32094.1427927327@turing-police.cc.vt.edu> On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: > Informational of course. :) > https://tools.ietf.org/html/rfc7511 It already has an errata filed. Follow the link. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jwalter at weebly.com Wed Apr 1 23:00:10 2015 From: jwalter at weebly.com (Jeff Walter) Date: Wed, 1 Apr 2015 16:00:10 -0700 Subject: RFC 7511 - Scenic Routing for IPv6 In-Reply-To: <32094.1427927327@turing-police.cc.vt.edu> References: <551C60B2.2040906@sadiqs.com> <32094.1427927327@turing-police.cc.vt.edu> Message-ID: I only buy free-ranged packets and you should too. On Wed, Apr 1, 2015 at 3:28 PM, wrote: > On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: > > Informational of course. :) > > https://tools.ietf.org/html/rfc7511 > > It already has an errata filed. Follow the link. :) > From tom at cloudflare.com Wed Apr 1 23:10:18 2015 From: tom at cloudflare.com (Tom Paseka) Date: Wed, 1 Apr 2015 16:10:18 -0700 Subject: From Europe to Australia via right way In-Reply-To: <551C6864.5030604@bogus.com> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> Message-ID: you won't find internet packets going that way though (most of the time). You can buy a L2vpn, p2p, etc, that will though. On Wed, Apr 1, 2015 at 2:51 PM, joel jaeggli wrote: > On 4/1/15 3:14 AM, Piotr wrote: > > Hello, > > > > There is some telecom, isp which have route from EU to AU via east or > > south east (via Russia, Red sea or other ways) ? Now i have path via US > > and looking something in opposite direction. > > telstra ntt reliance retn all have eastbound paths from europe. > > > thanks for some info, contact. > > Piotr > > > > > From tmaufer at gmail.com Wed Apr 1 23:15:02 2015 From: tmaufer at gmail.com (Thomas Maufer) Date: Wed, 01 Apr 2015 23:15:02 +0000 Subject: RFC 7511 - Scenic Routing for IPv6 In-Reply-To: References: <551C60B2.2040906@sadiqs.com> <32094.1427927327@turing-police.cc.vt.edu> Message-ID: All my packets use recycled electrons. And recycled photons. Conservation of Energy isn't just a green idea...it's the LAW. On Wed, Apr 1, 2015 at 4:02 PM Jeff Walter wrote: > I only buy free-ranged packets and you should too. > > On Wed, Apr 1, 2015 at 3:28 PM, wrote: > > > On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: > > > Informational of course. :) > > > https://tools.ietf.org/html/rfc7511 > > > > It already has an errata filed. Follow the link. :) > > > From gwardell at gwsystems.co.il Wed Apr 1 23:35:37 2015 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Wed, 1 Apr 2015 19:35:37 -0400 Subject: RFC 7511 - Scenic Routing for IPv6 In-Reply-To: References: <551C60B2.2040906@sadiqs.com> <32094.1427927327@turing-police.cc.vt.edu> Message-ID: <012e01d06cd4$8eb29840$ac17c8c0$@gwsystems.co.il> My packets prefer owls. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Thomas > Maufer > Sent: Wednesday, April 01, 2015 7:15 PM > To: Jeff Walter; Valdis.Kletnieks at vt.edu > Cc: NANOG > Subject: Re: RFC 7511 - Scenic Routing for IPv6 > > All my packets use recycled electrons. And recycled photons. Conservation of > Energy isn't just a green idea...it's the LAW. > > On Wed, Apr 1, 2015 at 4:02 PM Jeff Walter wrote: > > > I only buy free-ranged packets and you should too. > > > > On Wed, Apr 1, 2015 at 3:28 PM, wrote: > > > > > On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: > > > > Informational of course. :) > > > > https://tools.ietf.org/html/rfc7511 > > > > > > It already has an errata filed. Follow the link. :) > > > > > From list at satchell.net Wed Apr 1 23:39:54 2015 From: list at satchell.net (Stephen Satchell) Date: Wed, 01 Apr 2015 16:39:54 -0700 Subject: RFC 7511 - Scenic Routing for IPv6 In-Reply-To: <012e01d06cd4$8eb29840$ac17c8c0$@gwsystems.co.il> References: <551C60B2.2040906@sadiqs.com> <32094.1427927327@turing-police.cc.vt.edu> <012e01d06cd4$8eb29840$ac17c8c0$@gwsystems.co.il> Message-ID: <551C81CA.3050909@satchell.net> I'm sorry, packets are for the birds. https://tools.ietf.org/html/rfc2549 On 04/01/2015 04:35 PM, Gary Wardell wrote: > My packets prefer owls. > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Thomas >> Maufer >> Sent: Wednesday, April 01, 2015 7:15 PM >> To: Jeff Walter; Valdis.Kletnieks at vt.edu >> Cc: NANOG >> Subject: Re: RFC 7511 - Scenic Routing for IPv6 >> >> All my packets use recycled electrons. And recycled photons. Conservation > of >> Energy isn't just a green idea...it's the LAW. >> >> On Wed, Apr 1, 2015 at 4:02 PM Jeff Walter wrote: >> >>> I only buy free-ranged packets and you should too. >>> >>> On Wed, Apr 1, 2015 at 3:28 PM, wrote: >>> >>>> On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: >>>>> Informational of course. :) >>>>> https://tools.ietf.org/html/rfc7511 >>>> >>>> It already has an errata filed. Follow the link. :) >>>> >>> > From josh at imaginenetworksllc.com Wed Apr 1 23:42:08 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 1 Apr 2015 19:42:08 -0400 Subject: RFC 7511 - Scenic Routing for IPv6 In-Reply-To: <551C81CA.3050909@satchell.net> References: <551C60B2.2040906@sadiqs.com> <32094.1427927327@turing-police.cc.vt.edu> <012e01d06cd4$8eb29840$ac17c8c0$@gwsystems.co.il> <551C81CA.3050909@satchell.net> Message-ID: The pigeon one is still my favorite, too. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Apr 1, 2015 at 7:39 PM, Stephen Satchell wrote: > I'm sorry, packets are for the birds. > > https://tools.ietf.org/html/rfc2549 > > On 04/01/2015 04:35 PM, Gary Wardell wrote: > > My packets prefer owls. > > > >> -----Original Message----- > >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Thomas > >> Maufer > >> Sent: Wednesday, April 01, 2015 7:15 PM > >> To: Jeff Walter; Valdis.Kletnieks at vt.edu > >> Cc: NANOG > >> Subject: Re: RFC 7511 - Scenic Routing for IPv6 > >> > >> All my packets use recycled electrons. And recycled photons. > Conservation > > of > >> Energy isn't just a green idea...it's the LAW. > >> > >> On Wed, Apr 1, 2015 at 4:02 PM Jeff Walter wrote: > >> > >>> I only buy free-ranged packets and you should too. > >>> > >>> On Wed, Apr 1, 2015 at 3:28 PM, wrote: > >>> > >>>> On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: > >>>>> Informational of course. :) > >>>>> https://tools.ietf.org/html/rfc7511 > >>>> > >>>> It already has an errata filed. Follow the link. :) > >>>> > >>> > > > > From matt at spectrum.com.au Wed Apr 1 23:45:40 2015 From: matt at spectrum.com.au (Matt Perkins) Date: Thu, 02 Apr 2015 10:45:40 +1100 Subject: From Europe to Australia via right way In-Reply-To: References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> Message-ID: <551C8324.4030309@spectrum.com.au> Some times you can get luck and go through SE-ME-WE3 (we it's not cut) but most path's are via the US. What is your destination network in Australia. Matt On 2/04/2015 10:10 am, Tom Paseka wrote: > you won't find internet packets going that way though (most of the time). > You can buy a L2vpn, p2p, etc, that will though. > > On Wed, Apr 1, 2015 at 2:51 PM, joel jaeggli wrote: > >> On 4/1/15 3:14 AM, Piotr wrote: >>> Hello, >>> >>> There is some telecom, isp which have route from EU to AU via east or >>> south east (via Russia, Red sea or other ways) ? Now i have path via US >>> and looking something in opposite direction. >> telstra ntt reliance retn all have eastbound paths from europe. >> >>> thanks for some info, contact. >>> Piotr >>> >> >> -- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt at spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */ From rps at maine.edu Thu Apr 2 00:06:42 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 1 Apr 2015 20:06:42 -0400 Subject: How are you doing DHCPv6 ? In-Reply-To: References: <31c6fa01-0ec1-4d1e-bf07-5c137906833e@zimbra.network1.net> Message-ID: [ 3 year old thread ] So back in 2012 there was some discussion on DHCPv6 and the challenge of using a DUID in a dual-stack environment where MAC-based assignments are already happening though an IPAM. Update on this since then: *RFC 6939 - Client Link-Layer Address Option in DHCPv6* Pretty much exactly what I described in 2012 in terms of leveraging RFC 6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-) I'd like to think my email back in 2012 influenced this, but I'm sure it didn't. ;-) *Support in ISC DHCP 4.3.1+* https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-DHCP-4.3.html Example to add logging for this in dhcpd.conf: log (info, concat ("Lease for ", binary-to-ascii(16,16, ":", substring(suffix(option dhcp6.ia-na, 24),0,16)), " client-linklayer-addr ",v6relay(1, (binary-to-ascii(16, 8, ":", option dhcp6.client-linklayer-addr))))); To create static bindings based on it: host hostname-1 { host-identifier v6relopt 1 dhcp6.client-linklayer-addr 0:1:32:8b:36:ba:ed:ab; fixed-address6 2001:db8:100::123; }; [ These examples taken from Enno Rey, link follows ] http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/ *Cisco Support?* Apparently Cisco has started to support this in IOS-XE by default. I haven't had a chance to verify this yet, but I did check IOS XR and IOS and still don't see support for it. Does anyone have details on what platforms and releases from Cisco support RFC 6939 "Option 79" so far? The only thing I can find online is reference to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me. On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy wrote: > The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree. > > Currently, a DUID can be generated in 1 of 3 ways, 2 of which include > _any_ MAC address of the system at the time of generation. After > that, the DUID is stored in software. > > The idea is that the DUID identifies the system and the IAID > identifies the interface, and that over time, the system will keep its > DUID even if the network adapter changes. > > This is obviously different from how we use DHCP for legacy IP. > > There are a few problems as a result: > > 1. Systems that are built using disk images can all have the same DUID > unless the admin takes care to remove any generated DUID on the image > (already see this on Windows 7 and even Linux). > > 2. Networks where the MAC addresses for systems are already known > can't simply build a DHCPv6 configuration based on those MACs. > > If someone were to modify DHCPv6 to address these concerns, I think > the easiest way to do so would be to extend DHCPv6 relay messages to > include the MAC address of the system making the request (DHCPv6 > servers on local sub-networks would be able to determine the MAC from > the packet). This would allow transitional DHCPv6 configurations to > be built on MAC addresses rather than DUID without client modification > (which is key). > > Perhaps this is already possible through the use of RFC 6422 (which > shouldn't break anything). > > I think more important, though, is a good DHCPv6 server implementation > with verbose logging capabilities, and the ability to specify a DUID, > DUID+IAID, or MAC for static assignments. > > I know there are people from ISC on-list. It would be great to hear > someone who works on DHCPd chime in. > > How about we start with modifying ISC DHCPd for IPv6 to have proper > logging and support for configuring IAID, then work on the MAC > awareness piece. ISC DHCPd makes use of RAW sockets, so it should > always have the MAC for a non-relayed request. Then we just need to > work with router vendors on adding MACs as a relay option. > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From Rod.Beck at hibernianetworks.com Wed Apr 1 12:46:41 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Wed, 1 Apr 2015 12:46:41 +0000 Subject: Usage data from Turkey In-Reply-To: <551BC9A7.2090802@netassist.ua> References: , <551BC9A7.2090802@netassist.ua> Message-ID: <1427892404347.33332@hibernianetworks.com> I left the industry for a few years so I may be off, but I doubt they have any. It wasn't a deregulated market when I left telecom in 2011. Regards, Roderick. Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.beck at hibernianetworks.com _ This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From Rod.Beck at hibernianetworks.com Wed Apr 1 14:27:11 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Wed, 1 Apr 2015 14:27:11 +0000 Subject: From Europe to Australia via right way In-Reply-To: <551BC4FA.2050207@interia.pl> References: <551BC4FA.2050207@interia.pl> Message-ID: <1427898434357.50228@hibernianetworks.com> Yes, I believe PCCW had the route at one time. Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.beck at hibernianetworks.com ________________________________________ From: NANOG on behalf of Piotr Sent: Wednesday, April 1, 2015 12:14 PM To: nanog at nanog.org Subject: From Europe to Australia via right way Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. thanks for some info, contact. Piotr This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From frederik at kriewitz.eu Wed Apr 1 17:01:57 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Wed, 1 Apr 2015 19:01:57 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) Message-ID: Hello, We've a lot of customers with Cisco 6500 routers (mostly with SUP720 supervisors) in operation. They are very popular with smaller ISPs in Africa/middle east due to their cheap price on the used marked and their fully sufficient routing performance for the given tasks. In practice the biggest problem with them is their poor BGP scalability due to the CPU/memory limitations. We're looking into options for a cheap fix for this problem. The idea is to offload BGP IPv4/IPv6 RIB calculation from the router to a standard server. All BGP sessions will be handled by the server. The server takes care of the RIB calculation and aggregates the result as much as possible (the aggregation potential of the global tables should be very high if it can completely ignore the AS path and only care about the next hop). The final optimized RIB is then pushed to the Router via an iBGP session (the only BGP session configured on the router). If there's room in the transfer net for the server and the router, the setup is simple (eBGP session is established with the server and next-hop is set to the router). In other peering situations the setup might be more challenging. E.g. with typical IXP constrains (only a single MAC address/IP address allowed) the session would have to be a multihop session and an additional static route (host route for the server) on the peer router should be installed. Another way to make the server appear completely transparent for other peers (no special configuration on the peer side) might be NAT for the BGP port to the server or proxy ARP. But we would like to avoid doing NAT with a SUP720 and proxy ARP would make us the default gateway for any incorrectly configured IXP participant router and a configuration error on our side might cause severe harm to the IXP. And of course both ideas won't work for IPv6 (SUP720 doesn't support NAT for IPv6 or proxy NDP). The only solution to make it fully transparent for IPv4 and IPv6 we came up with it is to configure the IXP router interface as unnumbered + static route for the IXP nets + host routes for the assigned IXP IPs to the server. In that case the server would have to monitor the IXP vlan and take care of responding to ARP and Neighbor Solicitation requests for the IXP IPs (using the MAC of the router). Additionally it might be necessary to inject the ARP/IPv6 neighbors into the cisco using static entries (to avoid sending ARP/NS requests with a non IXP IP). We're wondering if anyone has experience with such a setup? Best Regards, Freddy From mawatari at jpix.ad.jp Thu Apr 2 03:28:18 2015 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Thu, 02 Apr 2015 12:28:18 +0900 Subject: Usage data from Turkey In-Reply-To: <551BC9A7.2090802@netassist.ua> References: <551BC9A7.2090802@netassist.ua> Message-ID: <20150402122818.4916.8FE1F57E@jpix.ad.jp> I'm not an expert on Turkey, but NetIX has a PoP in Istanbul. http://netix.net/map * On Wed, 01 Apr 2015 13:34:15 +0300 * Max Tulyev wrote: > Hello, > > may be a bit off-topic, but which major Internet Exchange points are in > Tukrey? I can't google it. > > On 03/31/15 20:19, Mehmet Akcin wrote: > > Hello > > > > Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power outage impacting nearly 70M people. I am writing a blog post about power outage vs impact to network usage. I am looking for as much as useful network usage information possible related to Turkey. > > > > If you can share network usage information, i will be making sure to buy you some drinks at next nanog ;) > > > > Cheers > > > > Mehmet From cb.list6 at gmail.com Thu Apr 2 03:28:54 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 1 Apr 2015 20:28:54 -0700 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: Message-ID: On Wednesday, April 1, 2015, Frederik Kriewitz wrote: > Hello, > > We've a lot of customers with Cisco 6500 routers (mostly with SUP720 > supervisors) in operation. They are very popular with smaller ISPs in > Africa/middle east due to their cheap price on the used marked and > their fully sufficient routing performance for the given tasks. In > practice the biggest problem with them is their poor BGP scalability > due to the CPU/memory limitations. > > We're looking into options for a cheap fix for this problem. > > The idea is to offload BGP IPv4/IPv6 RIB calculation from the router > to a standard server. All BGP sessions will be handled by the server. > The server takes care of the RIB calculation and aggregates the result > as much as possible (the aggregation potential of the global tables > should be very high if it can completely ignore the AS path and only > care about the next hop). The final optimized RIB is then pushed to > the Router via an iBGP session (the only BGP session configured on the > router). > > If there's room in the transfer net for the server and the router, the > setup is simple (eBGP session is established with the server and > next-hop is set to the router). > > In other peering situations the setup might be more challenging. E.g. > with typical IXP constrains (only a single MAC address/IP address > allowed) the session would have to be a multihop session and an > additional static route (host route for the server) on the peer router > should be installed. > > Another way to make the server appear completely transparent for other > peers (no special configuration on the peer side) might be NAT for the > BGP port to the server or proxy ARP. But we would like to avoid doing > NAT with a SUP720 and proxy ARP would make us the default gateway for > any incorrectly configured IXP participant router and a configuration > error on our side might cause severe harm to the IXP. And of course > both ideas won't work for IPv6 (SUP720 doesn't support NAT for IPv6 or > proxy NDP). > > The only solution to make it fully transparent for IPv4 and IPv6 we > came up with it is to configure the IXP router interface as unnumbered > + static route for the IXP nets + host routes for the assigned IXP IPs > to the server. In that case the server would have to monitor the IXP > vlan and take care of responding to ARP and Neighbor Solicitation > requests for the IXP IPs (using the MAC of the router). Additionally > it might be necessary to inject the ARP/IPv6 neighbors into the cisco > using static entries (to avoid sending ARP/NS requests with a non IXP > IP). > > We're wondering if anyone has experience with such a setup? > > > Best Regards, > > Freddy > Do these use cases really require a full table? Could you get-by with a simple filter Less than or equal to /22 ? Especially applying such a filter to non-local / inter-continental routes? I have done similar for a long time on 7600s, works fine for me (with a default from my upstream) CB From dorian at blackrose.org Thu Apr 2 03:59:52 2015 From: dorian at blackrose.org (Dorian Kim) Date: Wed, 1 Apr 2015 23:59:52 -0400 Subject: From Europe to Australia via right way In-Reply-To: <551C6864.5030604@bogus.com> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> Message-ID: <9D4A24A0-BAF3-4157-BE51-D55D71C3E083@blackrose.org> I don’t believe anyone has significant IP network capacity going EU -> Australia in that direction, esp. since once you get to Singapore, the options to get to Australia are limited. Even for networks that do have EU to Asia connectivity via Indian Ocean or land route to north Asia, the preferred path would be via US and transpac. -dorian > On Apr 1, 2015, at 5:51 PM, joel jaeggli wrote: > > On 4/1/15 3:14 AM, Piotr wrote: >> Hello, >> >> There is some telecom, isp which have route from EU to AU via east or >> south east (via Russia, Red sea or other ways) ? Now i have path via US >> and looking something in opposite direction. > > telstra ntt reliance retn all have eastbound paths from europe. > >> thanks for some info, contact. >> Piotr >> > > From rcarpen at network1.net Thu Apr 2 06:28:49 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 2 Apr 2015 02:28:49 -0400 (EDT) Subject: How are you doing DHCPv6 ? In-Reply-To: References: <31c6fa01-0ec1-4d1e-bf07-5c137906833e@zimbra.network1.net> Message-ID: <1057368385.785728.1427956129600.JavaMail.zimbra@network1.net> I've been trying to get an answer from Juniper on this for months. Most of the responses have been something to the effect of "I have no idea what you are talking about." I recently got an answer of "Juniper has no plans to support that." I am responsible for several small ISPs' networks, and if this was properly supported, all of their customers would have native IPv6 long ago. It boggles my mind that it took until 2013 for people to finally figure out that you need to be able to identify a device that is requesting DHCP. It is even crazier that hardware manufacturers don't seem to care. thanks, -Randy ----- On Apr 1, 2015, at 8:06 PM, Ray Soucy rps at maine.edu wrote: > [ 3 year old thread ] > > So back in 2012 there was some discussion on DHCPv6 and the challenge of > using a DUID in a dual-stack environment where MAC-based assignments are > already happening though an IPAM. > > Update on this since then: > > > > > *RFC 6939 - Client Link-Layer Address Option in DHCPv6* > > Pretty much exactly what I described in 2012 in terms of leveraging RFC > 6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-) > > I'd like to think my email back in 2012 influenced this, but I'm sure it > didn't. ;-) > > > > *Support in ISC DHCP 4.3.1+* > > https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-DHCP-4.3.html > > > Example to add logging for this in dhcpd.conf: > > log (info, concat ("Lease for ", binary-to-ascii(16,16, ":", > substring(suffix(option dhcp6.ia-na, 24),0,16)), " client-linklayer-addr > ",v6relay(1, (binary-to-ascii(16, 8, ":", option > dhcp6.client-linklayer-addr))))); > > > To create static bindings based on it: > > host hostname-1 { > host-identifier v6relopt 1 dhcp6.client-linklayer-addr > 0:1:32:8b:36:ba:ed:ab; > fixed-address6 2001:db8:100::123; > }; > > > [ These examples taken from Enno Rey, link follows ] > > http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/ > > > > > *Cisco Support?* > > Apparently Cisco has started to support this in IOS-XE by default. I > haven't had a chance to verify this yet, but I did check IOS XR and IOS and > still don't see support for it. > > Does anyone have details on what platforms and releases from Cisco support > RFC 6939 "Option 79" so far? The only thing I can find online is reference > to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me. > > > > > > On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy wrote: > >> The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree. >> >> Currently, a DUID can be generated in 1 of 3 ways, 2 of which include >> _any_ MAC address of the system at the time of generation. After >> that, the DUID is stored in software. >> >> The idea is that the DUID identifies the system and the IAID >> identifies the interface, and that over time, the system will keep its >> DUID even if the network adapter changes. >> >> This is obviously different from how we use DHCP for legacy IP. >> >> There are a few problems as a result: >> >> 1. Systems that are built using disk images can all have the same DUID >> unless the admin takes care to remove any generated DUID on the image >> (already see this on Windows 7 and even Linux). >> >> 2. Networks where the MAC addresses for systems are already known >> can't simply build a DHCPv6 configuration based on those MACs. >> >> If someone were to modify DHCPv6 to address these concerns, I think >> the easiest way to do so would be to extend DHCPv6 relay messages to >> include the MAC address of the system making the request (DHCPv6 >> servers on local sub-networks would be able to determine the MAC from >> the packet). This would allow transitional DHCPv6 configurations to >> be built on MAC addresses rather than DUID without client modification >> (which is key). >> >> Perhaps this is already possible through the use of RFC 6422 (which >> shouldn't break anything). >> >> I think more important, though, is a good DHCPv6 server implementation >> with verbose logging capabilities, and the ability to specify a DUID, >> DUID+IAID, or MAC for static assignments. >> >> I know there are people from ISC on-list. It would be great to hear >> someone who works on DHCPd chime in. >> >> How about we start with modifying ISC DHCPd for IPv6 to have proper >> logging and support for configuring IAID, then work on the MAC >> awareness piece. ISC DHCPd makes use of RAW sockets, so it should >> always have the MAC for a non-relayed request. Then we just need to >> work with router vendors on adding MACs as a relay option. >> >> -- >> Ray Soucy >> >> Epic Communications Specialist >> >> Phone: +1 (207) 561-3526 >> >> Networkmaine, a Unit of the University of Maine System >> http://www.networkmaine.net/ >> > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net From mark.tinka at seacom.mu Thu Apr 2 06:59:10 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 08:59:10 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: Message-ID: <551CE8BE.1010304@seacom.mu> On 1/Apr/15 19:01, Frederik Kriewitz wrote: > > We're wondering if anyone has experience with such a setup? Cisco have a feature called BGP-SD (BGP Selective Download). With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box. BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15. This would be my recommendation. Mark. From h.wahl at ifw-dresden.de Thu Apr 2 07:33:34 2015 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Thu, 02 Apr 2015 09:33:34 +0200 Subject: How are you doing DHCPv6 ? In-Reply-To: References: <31c6fa01-0ec1-4d1e-bf07-5c137906833e@zimbra.network1.net> Message-ID: <551CF0CE.6090208@ifw-dresden.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So back in 2012 there was some discussion on DHCPv6 and the > challenge of using a DUID in a dual-stack environment where > MAC-based assignments are already happening though an IPAM. > Have a look at https://dhcpy6d.ifw-dresden.de, our MAC address aware DHCPv6 server. Uses neighbor cache to get the MACs. Might only work in smaller environments but does its job. 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. Manfred Hennecke, Kaufmännische Direktorin i. V. Dipl.-Kffr. Friederike Jaeger -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUc8M4ACgkQnmb3Nh+6CUKSWwCaAqEcs4aywaaS8z4F5Ah6A0V/ aSIAn3WoD2dKEtlWrhdKdAS9UU9tMoPG =5OJu -----END PGP SIGNATURE----- From colinj at gt86car.org.uk Thu Apr 2 07:35:48 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 08:35:48 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CE8BE.1010304@seacom.mu> References: <551CE8BE.1010304@seacom.mu> Message-ID: or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not Colin > On 2 Apr 2015, at 07:59, Mark Tinka wrote: > > > > On 1/Apr/15 19:01, Frederik Kriewitz wrote: >> >> We're wondering if anyone has experience with such a setup? > > Cisco have a feature called BGP-SD (BGP Selective Download). > > With BGP-SD, you can hold millions of entries in RAM, but decide what > gets downloaded into the FIB. By doing this, you can still export a full > BGP table to customers directly connected to your 6500, and only have a > 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding > to a bigger box. > > BGP-SD started shipping in IOS XE, but I now understand that the feature > is on anything running IOS 15. > > This would be my recommendation. > > Mark. From contact at winterei.se Thu Apr 2 07:40:49 2015 From: contact at winterei.se (Paul S.) Date: Thu, 02 Apr 2015 16:40:49 +0900 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> Message-ID: <551CF281.30700@winterei.se> Do you have data on '100% of the traffic' being bad? I happen to have a large Chinese clientbase, and this is not the case on my network. On 4/2/2015 午後 04:35, Colin Johnston wrote: > or ignore/block russia and north korea and china network blocks > takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. > Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not > > Colin > > >> On 2 Apr 2015, at 07:59, Mark Tinka wrote: >> >> >> >> On 1/Apr/15 19:01, Frederik Kriewitz wrote: >>> We're wondering if anyone has experience with such a setup? >> Cisco have a feature called BGP-SD (BGP Selective Download). >> >> With BGP-SD, you can hold millions of entries in RAM, but decide what >> gets downloaded into the FIB. By doing this, you can still export a full >> BGP table to customers directly connected to your 6500, and only have a >> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding >> to a bigger box. >> >> BGP-SD started shipping in IOS XE, but I now understand that the feature >> is on anything running IOS 15. >> >> This would be my recommendation. >> >> Mark. From mark.tinka at seacom.mu Thu Apr 2 07:42:21 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 09:42:21 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> Message-ID: <551CF2DD.6080805@seacom.mu> On 2/Apr/15 09:35, Colin Johnston wrote: > or ignore/block russia and north korea and china network blocks > takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. > Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not I think that's a little extreme, especially since customers are paying me to deliver packets to the whole Internet. But that's just me... Mark. From nanog at stefan-neufeind.de Thu Apr 2 07:52:14 2015 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Thu, 02 Apr 2015 09:52:14 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF281.30700@winterei.se> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> Message-ID: <551CF52E.4010405@stefan-neufeind.de> Of course it's not something you should generalise about all people or all traffic from certain countries. But it's obvious that there are some countries which seem to care almost not at all about abuse or maybe even are sources for planned hack-attempts. And at least some large ISPs there seem to do nothing for their reputation or the reputation of their country. Kind regards, Stefan On 04/02/2015 09:40 AM, Paul S. wrote: > Do you have data on '100% of the traffic' being bad? > > I happen to have a large Chinese clientbase, and this is not the case on > my network. > > On 4/2/2015 午後 04:35, Colin Johnston wrote: >> or ignore/block russia and north korea and china network blocks >> takes away 5% of network ranges for memory headroom, especially the >> large number of smaller china blocks. >> Some may say this is harsh but is the network contacts refuse to >> co-operate with abuse and 100% of the traffic is bad then why not >> >> Colin >> >> >>> On 2 Apr 2015, at 07:59, Mark Tinka wrote: >>> >>> >>> >>> On 1/Apr/15 19:01, Frederik Kriewitz wrote: >>>> We're wondering if anyone has experience with such a setup? >>> Cisco have a feature called BGP-SD (BGP Selective Download). >>> >>> With BGP-SD, you can hold millions of entries in RAM, but decide what >>> gets downloaded into the FIB. By doing this, you can still export a full >>> BGP table to customers directly connected to your 6500, and only have a >>> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding >>> to a bigger box. >>> >>> BGP-SD started shipping in IOS XE, but I now understand that the feature >>> is on anything running IOS 15. >>> >>> This would be my recommendation. >>> >>> Mark. From mark.tinka at seacom.mu Thu Apr 2 07:57:26 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 09:57:26 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF52E.4010405@stefan-neufeind.de> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> Message-ID: <551CF666.7090100@seacom.mu> On 2/Apr/15 09:52, Stefan Neufeind wrote: > Of course it's not something you should generalise about all people or > all traffic from certain countries. But it's obvious that there are some > countries which seem to care almost not at all about abuse or maybe even > are sources for planned hack-attempts. And at least some large ISPs > there seem to do nothing for their reputation or the reputation of their > country. So when your customer calls you to complain about not being able to reach a random destination in "certain countries", you would tell them that you made a conscious decision to block access to "certain countries" because of reasons the customer probably will never understand or appreciate? You know what Randy says... that... Mark. From colinj at gt86car.org.uk Thu Apr 2 08:00:24 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 09:00:24 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF2DD.6080805@seacom.mu> References: <551CE8BE.1010304@seacom.mu> <551CF2DD.6080805@seacom.mu> Message-ID: <1735632C-2722-4F7C-8EB8-D5DDA2F6D71C@gt86car.org.uk> customers are paying for good traffic to generate eye balls and revenue, not bad traffic which clouds the good work done. I know we are getting into filtering traffic wars here but if the source admins refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then why not put up walls. I would like country trade talks to get down to the technical point that there are some fundamental problems being seen with bad traffic usage and it is significant percentage of waste bandwidth. Colin > On 2 Apr 2015, at 08:42, Mark Tinka wrote: > > > > On 2/Apr/15 09:35, Colin Johnston wrote: >> or ignore/block russia and north korea and china network blocks >> takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. >> Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not > > I think that's a little extreme, especially since customers are paying > me to deliver packets to the whole Internet. > > But that's just me... > > Mark. From colinj at gt86car.org.uk Thu Apr 2 08:04:31 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 09:04:31 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF281.30700@winterei.se> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> Message-ID: <8F4C8DFE-F021-4C71-91DF-6F7CB89DE92E@gt86car.org.uk> > On 2 Apr 2015, at 08:40, Paul S. wrote: > > Do you have data on '100% of the traffic' being bad? > as a example anything in 163data.com.cn is bad Colin > I happen to have a large Chinese clientbase, and this is not the case on my network. > > On 4/2/2015 午後 04:35, Colin Johnston wrote: >> or ignore/block russia and north korea and china network blocks >> takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. >> Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not >> >> Colin >> >> >>> On 2 Apr 2015, at 07:59, Mark Tinka wrote: >>> >>> >>> >>> On 1/Apr/15 19:01, Frederik Kriewitz wrote: >>>> We're wondering if anyone has experience with such a setup? >>> Cisco have a feature called BGP-SD (BGP Selective Download). >>> >>> With BGP-SD, you can hold millions of entries in RAM, but decide what >>> gets downloaded into the FIB. By doing this, you can still export a full >>> BGP table to customers directly connected to your 6500, and only have a >>> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding >>> to a bigger box. >>> >>> BGP-SD started shipping in IOS XE, but I now understand that the feature >>> is on anything running IOS 15. >>> >>> This would be my recommendation. >>> >>> Mark. > From contact at winterei.se Thu Apr 2 08:06:47 2015 From: contact at winterei.se (Paul S.) Date: Thu, 02 Apr 2015 17:06:47 +0900 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <8F4C8DFE-F021-4C71-91DF-6F7CB89DE92E@gt86car.org.uk> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <8F4C8DFE-F021-4C71-91DF-6F7CB89DE92E@gt86car.org.uk> Message-ID: <551CF897.5060703@winterei.se> 163data is announced as Chinanet, a China Telecom brand. Dropping 4134 (http://bgp.he.net/AS4134) globally will get my customers up at my doors with pitchforks fairly fast, I dunno about yours.... Simply too big to do anything that drastic against. On 4/2/2015 午後 05:04, Colin Johnston wrote: >> On 2 Apr 2015, at 08:40, Paul S. wrote: >> >> Do you have data on '100% of the traffic' being bad? >> > as a example anything in 163data.com.cn is bad > > Colin > >> I happen to have a large Chinese clientbase, and this is not the case on my network. >> >> On 4/2/2015 午後 04:35, Colin Johnston wrote: >>> or ignore/block russia and north korea and china network blocks >>> takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. >>> Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not >>> >>> Colin >>> >>> >>>> On 2 Apr 2015, at 07:59, Mark Tinka wrote: >>>> >>>> >>>> >>>> On 1/Apr/15 19:01, Frederik Kriewitz wrote: >>>>> We're wondering if anyone has experience with such a setup? >>>> Cisco have a feature called BGP-SD (BGP Selective Download). >>>> >>>> With BGP-SD, you can hold millions of entries in RAM, but decide what >>>> gets downloaded into the FIB. By doing this, you can still export a full >>>> BGP table to customers directly connected to your 6500, and only have a >>>> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding >>>> to a bigger box. >>>> >>>> BGP-SD started shipping in IOS XE, but I now understand that the feature >>>> is on anything running IOS 15. >>>> >>>> This would be my recommendation. >>>> >>>> Mark. From colinj at gt86car.org.uk Thu Apr 2 08:07:23 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 09:07:23 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF666.7090100@seacom.mu> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> Message-ID: <63A64726-6278-491E-9731-0594D55374E3@gt86car.org.uk> > On 2 Apr 2015, at 08:57, Mark Tinka wrote: > > > > On 2/Apr/15 09:52, Stefan Neufeind wrote: >> Of course it's not something you should generalise about all people or >> all traffic from certain countries. But it's obvious that there are some >> countries which seem to care almost not at all about abuse or maybe even >> are sources for planned hack-attempts. And at least some large ISPs >> there seem to do nothing for their reputation or the reputation of their >> country. > > So when your customer calls you to complain about not being able to > reach a random destination in "certain countries", you would tell them > that you made a conscious decision to block access to "certain > countries" because of reasons the customer probably will never > understand or appreciate? > Open ranges as necessary and mention will will reblock if bad traffic seen. It is called protect what you know is good and allow bad if documented and check if does not cause problems Colin From mark.tinka at seacom.mu Thu Apr 2 08:10:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 10:10:23 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <1735632C-2722-4F7C-8EB8-D5DDA2F6D71C@gt86car.org.uk> References: <551CE8BE.1010304@seacom.mu> <551CF2DD.6080805@seacom.mu> <1735632C-2722-4F7C-8EB8-D5DDA2F6D71C@gt86car.org.uk> Message-ID: <551CF96F.8050307@seacom.mu> On 2/Apr/15 10:00, Colin Johnston wrote: > customers are paying for good traffic to generate eye balls and revenue, not bad traffic which clouds the good work done. > I know we are getting into filtering traffic wars here but if the source admins refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then why not put up walls. > > I would like country trade talks to get down to the technical point that there are some fundamental problems being seen with bad traffic usage and it is significant percentage of waste bandwidth. The traffic may very well be bad, but my point is that is a point of view - one which may differ between you and your customer; never mind between you and your peers. Mark. From colinj at gt86car.org.uk Thu Apr 2 08:12:52 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 09:12:52 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF897.5060703@winterei.se> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <8F4C8DFE-F021-4C71-91DF-6F7CB89DE92E@gt86car.org.uk> <551CF897.5060703@winterei.se> Message-ID: <9E7CB0DC-059C-4308-B386-25DB106BE99A@gt86car.org.uk> You would be surprised at the good effect and bandwidth incoming/outgoing gained. allow blocks on exception and document and check. drastic action done due to unresponsive contacts and 100% bad traffic Colin > On 2 Apr 2015, at 09:06, Paul S. wrote: > > 163data is announced as Chinanet, a China Telecom brand. > > Dropping 4134 (http://bgp.he.net/AS4134) globally will get my customers up at my doors with pitchforks fairly fast, I dunno about yours.... > > Simply too big to do anything that drastic against. > > On 4/2/2015 午後 05:04, Colin Johnston wrote: >>> On 2 Apr 2015, at 08:40, Paul S. wrote: >>> >>> Do you have data on '100% of the traffic' being bad? >>> >> as a example anything in 163data.com.cn is bad >> >> Colin >> >>> I happen to have a large Chinese clientbase, and this is not the case on my network. >>> >>> On 4/2/2015 午後 04:35, Colin Johnston wrote: >>>> or ignore/block russia and north korea and china network blocks >>>> takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. >>>> Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not >>>> >>>> Colin >>>> >>>> >>>>> On 2 Apr 2015, at 07:59, Mark Tinka wrote: >>>>> >>>>> >>>>> >>>>> On 1/Apr/15 19:01, Frederik Kriewitz wrote: >>>>>> We're wondering if anyone has experience with such a setup? >>>>> Cisco have a feature called BGP-SD (BGP Selective Download). >>>>> >>>>> With BGP-SD, you can hold millions of entries in RAM, but decide what >>>>> gets downloaded into the FIB. By doing this, you can still export a full >>>>> BGP table to customers directly connected to your 6500, and only have a >>>>> 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding >>>>> to a bigger box. >>>>> >>>>> BGP-SD started shipping in IOS XE, but I now understand that the feature >>>>> is on anything running IOS 15. >>>>> >>>>> This would be my recommendation. >>>>> >>>>> Mark. > From mark.tinka at seacom.mu Thu Apr 2 08:14:52 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 10:14:52 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <63A64726-6278-491E-9731-0594D55374E3@gt86car.org.uk> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <63A64726-6278-491E-9731-0594D55374E3@gt86car.org.uk> Message-ID: <551CFA7C.9090806@seacom.mu> On 2/Apr/15 10:07, Colin Johnston wrote: > Open ranges as necessary and mention will will reblock if bad traffic seen. Might be a bit too much work for a customer to figure out when access will be granted or taken away. Would be for me, if I was your customer. > > It is called protect what you know is good and allow bad if documented and check if does not cause problems Fine in you're talking about your internal users on a corporate LAN. But paying customers? Oh well... Don't get me wrong, I appreciate the issue, and when one is thinking about how to save precious FIB resources, blocking "certain countries" comes to mind. I'm just saying, from my point of view, that might not be the best beak to cull. Mark. From piotr.1234 at interia.pl Thu Apr 2 08:34:00 2015 From: piotr.1234 at interia.pl (Piotr) Date: Thu, 02 Apr 2015 10:34:00 +0200 Subject: From Europe to Australia via right way In-Reply-To: <551C8324.4030309@spectrum.com.au> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> Message-ID: <551CFEF8.7050405@interia.pl> It's close to Sydney, 203.18.241.0/24 What's the reason, there are some telecoms,isp that have paths eastbound, southbound but in routing table they prefer longer path via US ? regards, Piotr W dniu 2015-04-02 o 01:45, Matt Perkins pisze: > Some times you can get luck and go through SE-ME-WE3 (we it's not cut) > but most path's are via the US. > What is your destination network in Australia. > > Matt > From elmi at 4ever.de Thu Apr 2 08:43:25 2015 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 2 Apr 2015 10:43:25 +0200 Subject: From Europe to Australia via right way In-Reply-To: <551CFEF8.7050405@interia.pl> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> Message-ID: <20150402084325.GE77104@nbmacvieebi.local> piotr.1234 at interia.pl (Piotr) wrote: > What's the reason, there are some telecoms,isp that have paths eastbound, > southbound but in routing table they prefer longer path via US ? Come on - you do know that it's called "policy" routing for a reason? Costs, reserved bw/s for high-rollers, capacity... (Sometimes sheer stupidity, too) Elmar. From nanog at stefan-neufeind.de Thu Apr 2 10:34:25 2015 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Thu, 02 Apr 2015 12:34:25 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF666.7090100@seacom.mu> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> Message-ID: <551D1B31.1020009@stefan-neufeind.de> On 04/02/2015 09:57 AM, Mark Tinka wrote: > > > On 2/Apr/15 09:52, Stefan Neufeind wrote: >> Of course it's not something you should generalise about all people or >> all traffic from certain countries. But it's obvious that there are some >> countries which seem to care almost not at all about abuse or maybe even >> are sources for planned hack-attempts. And at least some large ISPs >> there seem to do nothing for their reputation or the reputation of their >> country. > > So when your customer calls you to complain about not being able to > reach a random destination in "certain countries", you would tell them > that you made a conscious decision to block access to "certain > countries" because of reasons the customer probably will never > understand or appreciate? Not fully block / null-route of course. You might however consider to not allow ssh-logins from certain countries (if you know what you're doing) to avoid noise in the logs, might monitor incoming emails with smtp-auth for suspicious activity based on country (of course there can always be someone on holiday in those countries) etc. All I'm saying is that attacks or spam sometimes seem to originate mainly from "certain" countries. Judge for yourself what you maybe want to use that additional piece of information (geo-location) for - and use it wisely. Kind regards, Stefan From baldur.norddahl at gmail.com Thu Apr 2 10:47:26 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 2 Apr 2015 12:47:26 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CFA7C.9090806@seacom.mu> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <63A64726-6278-491E-9731-0594D55374E3@gt86car.org.uk> <551CFA7C.9090806@seacom.mu> Message-ID: Filtering countries is a bad idea, but it is probably possible to create filters so 99% of your actual traffic is handled by a relatively small subset of global routes and the remaining 1% routed via a default route or via a Linux box. Anyone know of tools and methods to do this? How effective is it ( how many routes is necessary to capture 99% of the traffic)? Regards Baldur From mark.tinka at seacom.mu Thu Apr 2 10:49:11 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 12:49:11 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551D1B31.1020009@stefan-neufeind.de> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> Message-ID: <551D1EA7.8060605@seacom.mu> On 2/Apr/15 12:34, Stefan Neufeind wrote: > Not fully block / null-route of course. You might however consider to > not allow ssh-logins from certain countries (if you know what you're > doing) to avoid noise in the logs, might monitor incoming emails with > smtp-auth for suspicious activity based on country (of course there can > always be someone on holiday in those countries) etc. > > All I'm saying is that attacks or spam sometimes seem to originate > mainly from "certain" countries. Judge for yourself what you maybe want > to use that additional piece of information (geo-location) for - and use > it wisely. Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off. I'd have to consider all other options really exhausted about fixing this for myself before I have to go and fix it in the network in a way that impacts other customers who may be getting spam from non-North American sources, or who enjoy the North American spam... Mark. From baldur.norddahl at gmail.com Thu Apr 2 10:57:41 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 2 Apr 2015 12:57:41 +0200 Subject: How are you doing DHCPv6 ? In-Reply-To: References: <31c6fa01-0ec1-4d1e-bf07-5c137906833e@zimbra.network1.net> Message-ID: This reminds me that we have switches that will tag DHCPv6 packets with the equallent to option 82 however ISC-DHCP has no support for it. The switch will create a DHCP packet with two options, one being the user info and the other is encapsulating the original packet. ISC-DHCP will pick the encapsulated original packet and then ignore the user info from the outer packet, so it is useless. But if the most popular server is useless, how are people doing this? Regards Baldur From colinj at gt86car.org.uk Thu Apr 2 11:06:07 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 12:06:07 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551D1EA7.8060605@seacom.mu> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> Message-ID: > > Most of the spam I get comes from North America. Go figure. I'm not > about to cut access to that continent off. > > I'd have to consider all other options really exhausted about fixing > this for myself before I have to go and fix it in the network in a way > that impacts other customers who may be getting spam from non-North > American sources, or who enjoy the North American spam… > It is not spam we are talking about, it is bad invalid network packets, bad web traffic probing exploits, bad port traffic looking for open network ports. All of this originates in countries not using best practice abuse process, no communication with route config errors, no communication when ddos seen. In effect it is a war on bad traffic and country blocks will be in the only way to make people take notice of this problem. Colin From mark.tinka at seacom.mu Thu Apr 2 11:10:11 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 13:10:11 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> Message-ID: <551D2393.9070906@seacom.mu> On 2/Apr/15 13:06, Colin Johnston wrote: > It is not spam we are talking about,... I'm aware - but someone mentioned it, so it deserved it's on post. But having said that... > it is bad invalid network packets, bad web traffic probing exploits, bad port traffic looking for open network ports. > All of this originates in countries not using best practice abuse process, no communication with route config errors, no communication when ddos seen. > In effect it is a war on bad traffic and country blocks will be in the only way to make people take notice of this problem. ... one man's spam is another man's SSH attacks. So it's really not about the type of traffic, it's about whether blocking it wholesale on a commercial network without thought to what customers think. But as they always say, Your Network, Your Rules. I say, "What Randy says..." Mark. From contact at winterei.se Thu Apr 2 11:18:02 2015 From: contact at winterei.se (Paul S.) Date: Thu, 02 Apr 2015 20:18:02 +0900 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <63A64726-6278-491E-9731-0594D55374E3@gt86car.org.uk> <551CFA7C.9090806@seacom.mu> Message-ID: <551D256A.9080109@winterei.se> David Barroso's (Spotify) SDN Internet Router [0] comes to mind. 0 - https://github.com/dbarrosop/sir On 4/2/2015 午後 07:47, Baldur Norddahl wrote: > Filtering countries is a bad idea, but it is probably possible to create > filters so 99% of your actual traffic is handled by a relatively small > subset of global routes and the remaining 1% routed via a default route or > via a Linux box. > > Anyone know of tools and methods to do this? How effective is it ( how many > routes is necessary to capture 99% of the traffic)? > > Regards > > Baldur From nogs at border6.com Thu Apr 2 11:43:15 2015 From: nogs at border6.com (Pawel Rybczyk) Date: Thu, 02 Apr 2015 13:43:15 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <6754-b6.nogs.nanog-02042015112001-7B@news.border6.com> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <63A64726-6278-491E-9731-0594D55374E3@gt86car.org.uk> <551CFA7C.9090806@seacom.mu> <6754-b6.nogs.nanog-02042015112001-7B@news.border6.com> Message-ID: <551D2B53.9040306@border6.com> Hi Freddy, As Paul has mentioned, you could check the David's project - SIR, look at his presentation: https://www.youtube.com/watch?v=o1njanXhQqM We've also developed a platform for the BGP monitoring and routing optimization which could solve your problem. It would inject to the border routers only TOP X prefixes with which you exchange most of the traffic. The added value would be that route orders point to best performing transit (low latency, 0 packet loss) per distant prefix. If you are interested to know more about our software please contact me off-list. -- Regards, Pawel Rybczyk Regional Manager BORDER 6 sp. z o.o. pawel.rybczyk at border6.com office: +48 22 242 89 51 (ext.103) mobile: +48 664 300 375 > David Barroso's (Spotify) SDN Internet Router [0] comes to mind. > > 0 - https://github.com/dbarrosop/sir > > On 4/2/2015 午後 07:47, Baldur Norddahl wrote: >> Filtering countries is a bad idea, but it is probably possible to create >> filters so 99% of your actual traffic is handled by a relatively small >> subset of global routes and the remaining 1% routed via a default >> route or >> via a Linux box. >> >> Anyone know of tools and methods to do this? How effective is it ( how >> many >> routes is necessary to capture 99% of the traffic)? >> >> Regards >> >> Baldur > From ramy.ihashish at gmail.com Thu Apr 2 04:54:28 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Thu, 2 Apr 2015 06:54:28 +0200 Subject: Tier 1 robust DDoS protection solution! No, not yet! Message-ID: Due to the enterprise market demand on DDoS protection solutions - which was initiated by a DDoS vendor, all operators in my country are trying to deploy their solution as fast as they can. As a result to the recent vendor's competition in DDoS protection, the detection/mitigation time can be seconds rather than minutes. However, for some reason tier 1 providers cannot keep pace with these fast mitigation responses, not to mention the tier one providers who are only providing the BGP-based blackholing for DDoS, this inconsistency will finally lead to inefficient DDoS mitigation solution. I have my own concerns about today's DDoS mitigation solutions, however I need to know what are tier one provider's plans for DDoS mitigation? Regards, Ramy From colinj at gt86car.org.uk Thu Apr 2 08:50:34 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 09:50:34 +0100 Subject: Fwd: Holborn fire is still burning under the pavement - BBC News References: <7F9E2ADE-9615-49B4-9836-39CED7438012@gt86car.org.uk> Message-ID: <0BB3EC1A-3D7D-4F9E-B38A-B616D9C951FF@gt86car.org.uk> Will take a lot of water to clear this up if gone into main tunnels :( Colin > >> http://www.bbc.co.uk/news/uk-england-london-32157618 >> >> Holborn fire is still burning under the pavement >> >> >> Local road closures are in place but Holborn Tube station is open >> A road in central London remains closed as an electrical fire continues to burn under the pavement. >> >> Some 5,000 people were evacuated from nearby buildings after smoke was seen coming out of an inspection cover on Kingsway, in Holborn, on Wednesday. >> >> London Fire Brigade (LFB) said the fire has been contained but has been "technically difficult" to tackle. >> >> More than 20 firefighters and officers are still at the scene and local road closures are in place. >> >> LFB Assistant Commissioner Peter Cowup said: "This has been a technically difficult incident to tackle. >> >> "The reason that the fire is still burning is because the service tunnel is hard to reach. >> >> "Although firefighters have been applying water through access points throughout the night, the complexity of the tunnel layout means that it will be some time until the fire is fully extinguished." >> >> He added LFB, the Met Police and utility companies were making steady progress to try and resolve the situation. >> >> 'Not an overnight job' >> >> Speaking to BBC London 94.9 , Insp Neil Johnson, from the Met Police, said: "The fire is still live in the subway. The problem at the moment is there is a gas pipe underneath and we are all in agreement that it is ok and if we can keep it contained it will be fine. >> >> "All we need to do is keep people out of the area and let the fire brigade and utilities do their job." >> >> >> The view from the London Eye on Thursday night highlighted the area affected by the power cut >> >> Firefighters were called to the fire at about 12:30 BST on Wednesday >> "I imagine this road will be closed a long time after this is finished because of damage the heat does to the road," Mr Johnson said. >> >> "It will have to remain closed until a structural engineer examines it properly and either he or she says what work has to be done and that work is completed - this is not an overnight job." >> >> On Thursday onlookers reported struggling to breathe and "chaos" in and around Holborn. The cause of the fire is still unknown. >> >> UK Power Networks said the number of customers currently affected by the power cuts stood at about 1,000 and they had restored power to 2,000. >> >> Apologising to customers Matt Rudling, from UK Power Networks, said: "The gas is still burning under there and until we can gain access to that particular area we won't understand what's caused it and what we can do." >> >> >> Smoke was seen coming out of an inspection cover on Kingsway on Wednesday >> >> "We want to try and restore [power to] all those remaining customers by the end of day today." >> >> He apologised for the disruption and added that emergency generators were being used to supply power to the area. >> >> UK Power Networks' engineers are also trying and connect some of the damaged cables to unaffected ones. >> >> Kingsway is closed between Holborn and Aldwych, the Strand Underpass, Waterloo Bridge northbound and Southampton Row southbound between Vernon Place and High Holborn, which is causing delays. >> >> Holborn station is open, however nine bus routes are being diverted . >> From dennis at justipit.com Thu Apr 2 13:31:48 2015 From: dennis at justipit.com (=?utf-8?B?ZGVubmlzQGp1c3RpcGl0LmNvbQ==?=) Date: Thu, 02 Apr 2015 06:31:48 -0700 Subject: =?utf-8?B?UmU6IFBvQyBmb3Igc2hvcnRsaXN0ZWQgRERvUyBWZW5kb3Jz?= Message-ID: You should include Radware on that list . ----- Reply message ----- From: "Mohamed Kamal" To: "NANOG" Subject: PoC for shortlisted DDoS Vendors Date: Wed, Apr 1, 2015 9:51 AM In our effort to pick up a reasonably priced DDoS appliance with a competitive features, we're in a process of doing a PoC for the following shortlisted vendors: 1- RioRey 2- NSFocus 3- Arbor 4- A10 The setup will be inline. So it would be great if anyone have done this before and can help provide the appropriate tools, advices, or the testing documents for efficient PoC. Thanks. -- Mohamed Kamal Core Network Sr. Engineer From jared at puck.Nether.net Thu Apr 2 14:03:17 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 2 Apr 2015 10:03:17 -0400 Subject: From Europe to Australia via right way In-Reply-To: <20150402084325.GE77104@nbmacvieebi.local> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> <20150402084325.GE77104@nbmacvieebi.local> Message-ID: <20150402140317.GA8997@puck.nether.net> On Thu, Apr 02, 2015 at 10:43:25AM +0200, Elmar K. Bins wrote: > piotr.1234 at interia.pl (Piotr) wrote: > > > What's the reason, there are some telecoms,isp that have paths eastbound, > > southbound but in routing table they prefer longer path via US ? > > Come on - you do know that it's called "policy" routing for a reason? > Costs, reserved bw/s for high-rollers, capacity... Sure, you can use static routes as well[1]. For those that are interested you can take a look at http://www.submarinecablemap.com/ to get an idea of what path might be feasible. I will say that telecom costs tend to be related to political stability, so when computing shortest path cost often comes into play. Also, What I'm often reminding people is low-latency isn't always the right solution, because loss is more important. I am less concerned about another 25-100ms if there is little jitter and zero loss. - Jared [1] - https://twitter.com/jaredmauch/status/583227901555961856 -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From pavel.odintsov at gmail.com Thu Apr 2 14:03:27 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 2 Apr 2015 17:03:27 +0300 Subject: PoC for shortlisted DDoS Vendors In-Reply-To: <20150402065225.61BB32C04A8@mail.nanog.org> References: <20150402065225.61BB32C04A8@mail.nanog.org> Message-ID: Hello! What about open source alternatives? Main part of commercial ddos filters are simple high performace firewalls with detection logic (which much times more stupid than well trained network engineer). But attacks for ISP is not arrived so iften and detection part coukd be executed manually (or with oss tools like netflow analyzers or my own FastNetMon toolkit). For wire speed filtration on 10ge (and even more if you have modern cpu; up to 40ge) you could use netmap-ipfw with linux or freebsd with simple patches (for enabling multy process mode). On Thursday, April 2, 2015, dennis at justipit.com wrote: > You should include Radware on that list . > > ----- Reply message ----- > From: "Mohamed Kamal" > > To: "NANOG" > > Subject: PoC for shortlisted DDoS Vendors > Date: Wed, Apr 1, 2015 9:51 AM > > In our effort to pick up a reasonably priced DDoS appliance with a > competitive features, we're in a process of doing a PoC for the > following shortlisted vendors: > > 1- RioRey > 2- NSFocus > 3- Arbor > 4- A10 > > The setup will be inline. So it would be great if anyone have done this > before and can help provide the appropriate tools, advices, or the > testing documents for efficient PoC. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer -- Sincerely yours, Pavel Odintsov From me at anuragbhatia.com Thu Apr 2 14:12:54 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 2 Apr 2015 19:42:54 +0530 Subject: Fwd: Question about EX - SRX redundancy In-Reply-To: References: Message-ID: Hello everyone! I have got two Juniper EX series switches (on virtual chassis) and two SRX devices on native clustering. I am trying to have a highly available redundancy between them with atleast 2Gbps capacity all the time but kind of failing. I followed Juniper's official page here as well as this detailed forum link here . I wish to have a case where devices are connected criss cross and following the documentation I get two ae bundles in EX side and one single reth bundle on SRX side. Both ae bundles on EX side have identical configuration and VLAN has both ae interfaces called up. If I do not go for criss cross connectivity like this: EX0 (ae1) >> Two Patches to SRX0 (reth1) EX1 (ae2) >> Two Patches to SRX1 (reth1) Then it works all well and redundancy works fine. In this case as long as 1 out of 4 patch is connected connectivity stays live but this has trade off that if one EX goes down then I cannot make use of other corresponding SRX. If I do criss connectivity, something like: EX0 (ae1) >> Two Patches to SRX0 (reth1) EX0 (ae1) >> One patch to SRX1 (reth1) EX1 (ae2) >> Two Patches to SRX1 (reth1) EX1 (ae2) >> One patch to SRX0 (reth1) In this config system behaves very oddly with one ae pair (and it's corresponding physical ports) working well while failover to other ae bundle fails completely. I was wondering if someone can point me out here. Appreciate your time and help! -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From maxsec at gmail.com Thu Apr 2 14:15:25 2015 From: maxsec at gmail.com (Martin Hepworth) Date: Thu, 2 Apr 2015 15:15:25 +0100 Subject: From Europe to Australia via right way In-Reply-To: <20150402140317.GA8997@puck.nether.net> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> <20150402084325.GE77104@nbmacvieebi.local> <20150402140317.GA8997@puck.nether.net> Message-ID: There's a new AAE-1 cable currently being laid (sunk!) that comes online early 2016 that will help. But right now alot of traffic cuts across the US as it's still the 'best' route for reasons other that latency as others have already mentioned. The new AAE-1 will have 40Tbps connections from Europe to Hong Kong so hopefully the routes will start to migrate in 2016 and give us an Easterly route to APAC that has enough capacity to be stable in that direction -- Martin Hepworth, CISSP Oxford, UK On 2 April 2015 at 15:03, Jared Mauch wrote: > On Thu, Apr 02, 2015 at 10:43:25AM +0200, Elmar K. Bins wrote: > > piotr.1234 at interia.pl (Piotr) wrote: > > > > > What's the reason, there are some telecoms,isp that have paths > eastbound, > > > southbound but in routing table they prefer longer path via US ? > > > > Come on - you do know that it's called "policy" routing for a reason? > > Costs, reserved bw/s for high-rollers, capacity... > > Sure, you can use static routes as well[1]. > > For those that are interested you can take a look > at http://www.submarinecablemap.com/ to get an idea of what path > might be feasible. I will say that telecom costs tend to be > related to political stability, so when computing shortest > path cost often comes into play. > > Also, What I'm often reminding people is low-latency isn't > always the right solution, because loss is more important. I am > less concerned about another 25-100ms if there is little jitter > and zero loss. > > - Jared > > [1] - https://twitter.com/jaredmauch/status/583227901555961856 > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > From jared at puck.nether.net Thu Apr 2 14:23:31 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 2 Apr 2015 10:23:31 -0400 Subject: From Europe to Australia via right way In-Reply-To: References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> <20150402084325.GE77104@nbmacvieebi.local> <20150402140317.GA8997@puck.nether.net> Message-ID: > On Apr 2, 2015, at 10:15 AM, Martin Hepworth wrote: > > The new AAE-1 will have 40Tbps connections from Europe to Hong Kong so > hopefully the routes will start to migrate in 2016 and give us an Easterly > route to APAC that has enough capacity to be stable in that direction I think this stability is key, I’ve been watching a testing team go round and round with a telco that seems to think that 1 second hits is acceptable through this area and they are unwilling to resolve it and seem to be begging “please just accept the circuit”. - Jared From mark.tinka at seacom.mu Thu Apr 2 14:27:04 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 16:27:04 +0200 Subject: From Europe to Australia via right way In-Reply-To: References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> <20150402084325.GE77104@nbmacvieebi.local> <20150402140317.GA8997@puck.nether.net> Message-ID: <551D51B8.8010206@seacom.mu> On 2/Apr/15 16:23, Jared Mauch wrote: > I think this stability is key, I’ve been watching a testing team go round and > round with a telco that seems to think that 1 second hits is acceptable through > this area and they are unwilling to resolve it and seem to be begging “please > just accept the circuit”. What kind of failover hit times are they looking for? 50ms? Mark. From bblackford at gmail.com Thu Apr 2 14:29:30 2015 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 2 Apr 2015 07:29:30 -0700 Subject: Question about EX - SRX redundancy In-Reply-To: References: Message-ID: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> It's my understanding that a cross chassis LAG is not supported. If there is a way, I'm not aware of it. I'm running the same set up as your working example in my locations and for now, this suits my requirements. Sent from my iPhone > On Apr 2, 2015, at 07:12, Anurag Bhatia wrote: > > Hello everyone! > > > > > I have got two Juniper EX series switches (on virtual chassis) and two SRX > devices on native clustering. > > > I am trying to have a highly available redundancy between them with atleast > 2Gbps capacity all the time but kind of failing. I followed Juniper's > official page here > as well as > this detailed forum link here > > . > > > I wish to have a case where devices are connected criss cross and following > the documentation I get two ae bundles in EX side and one single reth > bundle on SRX side. Both ae bundles on EX side have identical configuration > and VLAN has both ae interfaces called up. > > > If I do not go for criss cross connectivity like this: > > > > EX0 (ae1) >> Two Patches to SRX0 (reth1) > EX1 (ae2) >> Two Patches to SRX1 (reth1) > > > Then it works all well and redundancy works fine. In this case as long as 1 > out of 4 patch is connected connectivity stays live but this has trade off > that if one EX goes down then I cannot make use of other corresponding SRX. > > If I do criss connectivity, something like: > > > EX0 (ae1) >> Two Patches to SRX0 (reth1) > EX0 (ae1) >> One patch to SRX1 (reth1) > > EX1 (ae2) >> Two Patches to SRX1 (reth1) > EX1 (ae2) >> One patch to SRX0 (reth1) > > > In this config system behaves very oddly with one ae pair (and it's > corresponding physical ports) working well while failover to other ae > bundle fails completely. > > > > I was wondering if someone can point me out here. > > > > > Appreciate your time and help! > > > > > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | Twitter > > Skype: anuragbhatia.com > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From jared at puck.nether.net Thu Apr 2 14:32:57 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 2 Apr 2015 10:32:57 -0400 Subject: From Europe to Australia via right way In-Reply-To: <551D51B8.8010206@seacom.mu> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> <20150402084325.GE77104@nbmacvieebi.local> <20150402140317.GA8997@puck.nether.net> <551D51B8.8010206@seacom.mu> Message-ID: > On Apr 2, 2015, at 10:27 AM, Mark Tinka wrote: > > > > On 2/Apr/15 16:23, Jared Mauch wrote: >> I think this stability is key, I’ve been watching a testing team go round and >> round with a telco that seems to think that 1 second hits is acceptable through >> this area and they are unwilling to resolve it and seem to be begging “please >> just accept the circuit”. > > What kind of failover hit times are they looking for? 50ms? Seeing multiple hit times within a 24h period isn’t really acceptable and keeps these paths from being viable. They are claiming they are within 50ms. - Jared From mark.tinka at seacom.mu Thu Apr 2 14:36:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 2 Apr 2015 16:36:13 +0200 Subject: From Europe to Australia via right way In-Reply-To: References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> <20150402084325.GE77104@nbmacvieebi.local> <20150402140317.GA8997@puck.nether.net> <551D51B8.8010206@seacom.mu> Message-ID: <551D53DD.5040308@seacom.mu> On 2/Apr/15 16:32, Jared Mauch wrote: > Seeing multiple hit times within a 24h period isn’t really acceptable and keeps > these paths from being viable. Agreed. > > They are claiming they are within 50ms. Which makes sense if the end-to-end path is less than 50ms re: seeing hitless failovers on the IP routers. If the end-to-end path is crossing continents, a local failure which is repaired within 50ms will still cause a longer/noticeable outage for the IP routers connected at either end of said circuit. Mark. From tb at tburke.us Thu Apr 2 14:36:41 2015 From: tb at tburke.us (Tim Burke) Date: Thu, 2 Apr 2015 09:36:41 -0500 Subject: Denver In-Reply-To: <24883573.5831.1427488857941.JavaMail.mhammett@ThunderFuck> References: <24883573.5831.1427488857941.JavaMail.mhammett@ThunderFuck> Message-ID: <271B3508-EE71-450D-AB49-3A7FE6F10216@tburke.us> Handy Networks in Denver have a pretty decent footprint, good people too. http://www.handynetworks.com/ On Mar 27, 2015, at 3:40 PM, Mike Hammett wrote: > So in Denver Comfluent\CoreSite seems to be the place to be... except as someone that predominately serves eyeball networks, I'm interested in NetFlix. NetFlix is in EdgeConneX... where no other significant peering is happening. > > Also, my partner who has been looking into the Denver market said that CoreSite costs more than Chicago Equinix. > > Any recommendations for where to go? Seems like both main options suck, but there aren't any better. > > > This would be for eyeball networks getting peering with the big content guys and cheaper transit than the tier 4\5\6\7\8 (how small of markets get numbers?) where they're located. > > > Any significant web hosting operations in the Denver market? Someone that's bigger than "Bob's DS3 Web Hosting", but not SoftLayer size where they can't get creative with their services. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > From jtk at cymru.com Thu Apr 2 15:10:13 2015 From: jtk at cymru.com (John Kristoff) Date: Thu, 2 Apr 2015 10:10:13 -0500 Subject: PoC for shortlisted DDoS Vendors In-Reply-To: <551C222A.6080004@noor.net> References: <551C222A.6080004@noor.net> Message-ID: <20150402101013.12103885@localhost> On Wed, 01 Apr 2015 19:51:54 +0300 Mohamed Kamal wrote: > The setup will be inline. So it would be great if anyone have done > this before and can help provide the appropriate tools, advices, or > the testing documents for efficient PoC. Hi Mohamed, We recently introduced a community RTBH service called UTRS that might be a useful tool in your toolbox. Automated route relay went into effect not long ago and it seems to be working well. It isn't equivalent to any of the vendors you listed, but complimentary (and completely free :-) so I hope you don't mind me mentioning it. You can find more about it here: As for other tools... NfSen may be an open source option you want to consider. It can be extended with plugins you or others provide: Team Cymru has leveraged that with a set of plug-ins based on our insight for your network. If you want to talk to us about it, see: You might also check out: Cisco has, or had the Cisco Guard family of products, formerly based on the Riverhead acquisition, but that platform was end-of-sale some time ago and is effectively dead. They (and some other hardware vendors) have since begun to license Arbor into their gear. John From mkamal at noor.net Thu Apr 2 15:13:07 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Thu, 02 Apr 2015 18:13:07 +0300 Subject: PoC for shortlisted DDoS Vendors In-Reply-To: References: <20150402065225.61BB32C04A8@mail.nanog.org> Message-ID: <551D5C83.1050005@noor.net> Hello Pavel, I'm certainly biased to the open-source tools if they do the job required, and I appreciate your effort exerted on this project. However, based upon what I saw under the "features" list of your tool, I assume that it can detect only volumetric DDoS attacks based upon anomalies such as excessive number of packets/bits/connections/flows per second based upon some previously learnt or set threshold values. But what about the protocol types of attack, which, in my humble opinion is becoming more aggressive day after day? Mohamed Kamal Core Network Sr. Engineer On 4/2/2015 5:03 PM, Pavel Odintsov wrote: > Hello! > > What about open source alternatives? Main part of commercial ddos > filters are simple high performace firewalls with detection logic > (which much times more stupid than well trained network engineer). > > But attacks for ISP is not arrived so iften and detection part coukd > be executed manually (or with oss tools like netflow analyzers or my > own FastNetMon toolkit). > > For wire speed filtration on 10ge (and even more if you have modern > cpu; up to 40ge) you could use netmap-ipfw with linux or freebsd with > simple patches (for enabling multy process mode). > > On Thursday, April 2, 2015, dennis at justipit.com > > wrote: > > You should include Radware on that list . > > ----- Reply message ----- > From: "Mohamed Kamal" > > To: "NANOG" > > Subject: PoC for shortlisted DDoS Vendors > Date: Wed, Apr 1, 2015 9:51 AM > > In our effort to pick up a reasonably priced DDoS appliance with a > competitive features, we're in a process of doing a PoC for the > following shortlisted vendors: > > 1- RioRey > 2- NSFocus > 3- Arbor > 4- A10 > > The setup will be inline. So it would be great if anyone have done > this > before and can help provide the appropriate tools, advices, or the > testing documents for efficient PoC. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer > > > > -- > Sincerely yours, Pavel Odintsov From me at anuragbhatia.com Thu Apr 2 15:17:03 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 2 Apr 2015 20:47:03 +0530 Subject: Question about EX - SRX redundancy In-Reply-To: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> Message-ID: Hi I thought cross chassis lag is supposed by the use of reth bundled at SRX end. I read this is basically the major difference in reth Vs ae bundle in SRX. Interesting factor here is that ae bundles can spread across multiple EX chassis in a virtual chassis environment but this cannot be the case with ae bundles in SRX. Thanks. On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford wrote: > It's my understanding that a cross chassis LAG is not supported. If there > is a way, I'm not aware of it. I'm running the same set up as your working > example in my locations and for now, this suits my requirements. > > Sent from my iPhone > > > On Apr 2, 2015, at 07:12, Anurag Bhatia wrote: > > > > Hello everyone! > > > > > > > > > > I have got two Juniper EX series switches (on virtual chassis) and two > SRX > > devices on native clustering. > > > > > > I am trying to have a highly available redundancy between them with > atleast > > 2Gbps capacity all the time but kind of failing. I followed Juniper's > > official page here > > as > well as > > this detailed forum link here > > < > http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way-of-redundancy-between-SRX-and-EX/td-p/181365 > > > > . > > > > > > I wish to have a case where devices are connected criss cross and > following > > the documentation I get two ae bundles in EX side and one single reth > > bundle on SRX side. Both ae bundles on EX side have identical > configuration > > and VLAN has both ae interfaces called up. > > > > > > If I do not go for criss cross connectivity like this: > > > > > > > > EX0 (ae1) >> Two Patches to SRX0 (reth1) > > EX1 (ae2) >> Two Patches to SRX1 (reth1) > > > > > > Then it works all well and redundancy works fine. In this case as long > as 1 > > out of 4 patch is connected connectivity stays live but this has trade > off > > that if one EX goes down then I cannot make use of other corresponding > SRX. > > > > If I do criss connectivity, something like: > > > > > > EX0 (ae1) >> Two Patches to SRX0 (reth1) > > EX0 (ae1) >> One patch to SRX1 (reth1) > > > > EX1 (ae2) >> Two Patches to SRX1 (reth1) > > EX1 (ae2) >> One patch to SRX0 (reth1) > > > > > > In this config system behaves very oddly with one ae pair (and it's > > corresponding physical ports) working well while failover to other ae > > bundle fails completely. > > > > > > > > I was wondering if someone can point me out here. > > > > > > > > > > Appreciate your time and help! > > > > > > > > > > > > -- > > > > > > Anurag Bhatia > > anuragbhatia.com > > > > Linkedin | Twitter > > > > Skype: anuragbhatia.com > > > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From hugo at slabnet.com Thu Apr 2 15:51:05 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 2 Apr 2015 08:51:05 -0700 Subject: Question about EX - SRX redundancy In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> Message-ID: <20150402155105.GF9851@bamboo.slabnet.com> In: >> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >> > EX1 (ae2) >> Two Patches to SRX1 (reth1) with: >> > that if one EX goes down then I cannot make use of other corresponding >> SRX. Do you mean that e.g. if SRX0 is the chassis cluster primary and EX0 goes down, then you can't use SRX0, but you would like to be able to survive EX0 going down *without* failing over the SRX chassis cluster to SRX1? -- Hugo On Thu 2015-Apr-02 20:47:03 +0530, Anurag Bhatia wrote: >Hi > > >I thought cross chassis lag is supposed by the use of reth bundled at SRX >end. I read this is basically the major difference in reth Vs ae bundle in >SRX. > > >Interesting factor here is that ae bundles can spread across multiple EX >chassis in a virtual chassis environment but this cannot be the case with >ae bundles in SRX. > > > > >Thanks. > >On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford wrote: > >> It's my understanding that a cross chassis LAG is not supported. If there >> is a way, I'm not aware of it. I'm running the same set up as your working >> example in my locations and for now, this suits my requirements. >> >> Sent from my iPhone >> >> > On Apr 2, 2015, at 07:12, Anurag Bhatia wrote: >> > >> > Hello everyone! >> > >> > >> > >> > >> > I have got two Juniper EX series switches (on virtual chassis) and two >> SRX >> > devices on native clustering. >> > >> > >> > I am trying to have a highly available redundancy between them with >> atleast >> > 2Gbps capacity all the time but kind of failing. I followed Juniper's >> > official page here >> > as >> well as >> > this detailed forum link here >> > < >> http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way-of-redundancy-between-SRX-and-EX/td-p/181365 >> > >> > . >> > >> > >> > I wish to have a case where devices are connected criss cross and >> following >> > the documentation I get two ae bundles in EX side and one single reth >> > bundle on SRX side. Both ae bundles on EX side have identical >> configuration >> > and VLAN has both ae interfaces called up. >> > >> > >> > If I do not go for criss cross connectivity like this: >> > >> > >> > >> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >> > >> > >> > Then it works all well and redundancy works fine. In this case as long >> as 1 >> > out of 4 patch is connected connectivity stays live but this has trade >> off >> > that if one EX goes down then I cannot make use of other corresponding >> SRX. >> > >> > If I do criss connectivity, something like: >> > >> > >> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >> > EX0 (ae1) >> One patch to SRX1 (reth1) >> > >> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >> > EX1 (ae2) >> One patch to SRX0 (reth1) >> > >> > >> > In this config system behaves very oddly with one ae pair (and it's >> > corresponding physical ports) working well while failover to other ae >> > bundle fails completely. >> > >> > >> > >> > I was wondering if someone can point me out here. >> > >> > >> > >> > >> > Appreciate your time and help! >> > >> > >> > >> > >> > >> > -- >> > >> > >> > Anurag Bhatia >> > anuragbhatia.com >> > >> > Linkedin | Twitter >> > >> > Skype: anuragbhatia.com >> > >> > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >> > > > >-- > > >Anurag Bhatia >anuragbhatia.com > >Linkedin | Twitter > >Skype: anuragbhatia.com > >PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mcdonald.richards at gmail.com Thu Apr 2 17:08:48 2015 From: mcdonald.richards at gmail.com (McDonald Richards) Date: Thu, 2 Apr 2015 10:08:48 -0700 Subject: From Europe to Australia via right way In-Reply-To: <9D4A24A0-BAF3-4157-BE51-D55D71C3E083@blackrose.org> References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <9D4A24A0-BAF3-4157-BE51-D55D71C3E083@blackrose.org> Message-ID: If you want a direct path then SMW3 remains the only cable for the final leg from Singapore to Perth and it's capacity is only a few hundred gigabits. There are at least 2 proposed new systems racing to get into the water between Singapore and Perth to try and address this gap in supply and demand. On Wed, Apr 1, 2015 at 8:59 PM, Dorian Kim wrote: > I don’t believe anyone has significant IP network capacity going EU -> > Australia in that direction, esp. since once you get to Singapore, the > options to get to Australia are limited. > > Even for networks that do have EU to Asia connectivity via Indian Ocean or > land route to north Asia, the preferred path would be via US and transpac. > > -dorian > > > > On Apr 1, 2015, at 5:51 PM, joel jaeggli wrote: > > > > On 4/1/15 3:14 AM, Piotr wrote: > >> Hello, > >> > >> There is some telecom, isp which have route from EU to AU via east or > >> south east (via Russia, Red sea or other ways) ? Now i have path via US > >> and looking something in opposite direction. > > > > telstra ntt reliance retn all have eastbound paths from europe. > > > >> thanks for some info, contact. > >> Piotr > >> > > > > > > From maxtul at netassist.ua Thu Apr 2 17:25:03 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 02 Apr 2015 20:25:03 +0300 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: Message-ID: <551D7B6F.20407@netassist.ua> Hello! Very good idea is to sell that and change it to softrouter based on PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than $1k. On 04/01/15 20:01, Frederik Kriewitz wrote: > We're wondering if anyone has experience with such a setup? From contact at nullivex.com Thu Apr 2 18:01:30 2015 From: contact at nullivex.com (Bryan Tong) Date: Thu, 2 Apr 2015 12:01:30 -0600 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551D7B6F.20407@netassist.ua> References: <551D7B6F.20407@netassist.ua> Message-ID: As a network consumer and network provider. The traffic seen by the customer should not be censored. It should be up to the consumer to protect their services. I accept the risk and want uncensored internet access and provide such to our customers. On Apr 2, 2015 11:26 AM, "Max Tulyev" wrote: > Hello! > > Very good idea is to sell that and change it to softrouter based on > PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than > $1k. > > On 04/01/15 20:01, Frederik Kriewitz wrote: > > We're wondering if anyone has experience with such a setup? > > From goemon at anime.net Thu Apr 2 18:05:07 2015 From: goemon at anime.net (goemon at anime.net) Date: Thu, 2 Apr 2015 11:05:07 -0700 (PDT) Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551D1EA7.8060605@seacom.mu> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> Message-ID: On Thu, 2 Apr 2015, Mark Tinka wrote: > Most of the spam I get comes from North America. Go figure. I'm not > about to cut access to that continent off. Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen. china is neither. -Dan From colinj at gt86car.org.uk Thu Apr 2 18:18:33 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 19:18:33 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> Message-ID: <29DB6CD8-960F-4787-A0E3-2CB63BF77DF2@gt86car.org.uk> yes, china ignores everything said beit by phone,email,chat at least if you call a us provider you can at least communicate its not a english language issue either chinatelcom,chinanet contact info might as well not be documented colin Sent from my iPhone > On 2 Apr 2015, at 19:05, goemon at anime.net wrote: > >> On Thu, 2 Apr 2015, Mark Tinka wrote: >> Most of the spam I get comes from North America. Go figure. I'm not >> about to cut access to that continent off. > > Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen. > > china is neither. > > -Dan From faisal at snappytelecom.net Thu Apr 2 18:20:34 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 2 Apr 2015 18:20:34 +0000 (GMT) Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551D7B6F.20407@netassist.ua> Message-ID: <2096713293.1661272.1427998834684.JavaMail.zimbra@snappytelecom.net> How do you see this as a 'censoring' activity ? If the Op has a default route on their side, along with the reduced route table, at best you have less than optimal routing... Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Bryan Tong" > To: "Max Tulyev" > Cc: nanog at nanog.org > Sent: Thursday, April 2, 2015 2:01:30 PM > Subject: Re: BGP offloading (fixing legacy router BGP scalability issues) > > As a network consumer and network provider. The traffic seen by the > customer should not be censored. It should be up to the consumer to protect > their services. > > I accept the risk and want uncensored internet access and provide such to > our customers. > On Apr 2, 2015 11:26 AM, "Max Tulyev" wrote: > > > Hello! > > > > Very good idea is to sell that and change it to softrouter based on > > PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than > > $1k. > > > > On 04/01/15 20:01, Frederik Kriewitz wrote: > > > We're wondering if anyone has experience with such a setup? > > > > > From me at anuragbhatia.com Thu Apr 2 18:20:46 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 2 Apr 2015 23:50:46 +0530 Subject: Question about EX - SRX redundancy In-Reply-To: <20150402155105.GF9851@bamboo.slabnet.com> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> Message-ID: Hi Yes, Since SRX0 connected to EX0 and SRX1 connected to EX1 (only). Thus either pair - 0 will work or pair - 1 will work. I wish if criss crossing worked then failure of one EX would have still made both SRX available. In current worst case scenario - failure of EX0 and SRX1 can cause full outage. Thanks. On Thu, Apr 2, 2015 at 9:21 PM, Hugo Slabbert wrote: > In: > > > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>> >> > with: > > > that if one EX goes down then I cannot make use of other corresponding >>> SRX. >>> >> > Do you mean that e.g. if SRX0 is the chassis cluster primary and EX0 goes > down, then you can't use SRX0, but you would like to be able to survive EX0 > going down *without* failing over the SRX chassis cluster to SRX1? > > -- > Hugo > > > On Thu 2015-Apr-02 20:47:03 +0530, Anurag Bhatia > wrote: > > Hi >> >> >> I thought cross chassis lag is supposed by the use of reth bundled at SRX >> end. I read this is basically the major difference in reth Vs ae bundle in >> SRX. >> >> >> Interesting factor here is that ae bundles can spread across multiple EX >> chassis in a virtual chassis environment but this cannot be the case with >> ae bundles in SRX. >> >> >> >> >> Thanks. >> >> On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford >> wrote: >> >> It's my understanding that a cross chassis LAG is not supported. If there >>> is a way, I'm not aware of it. I'm running the same set up as your >>> working >>> example in my locations and for now, this suits my requirements. >>> >>> Sent from my iPhone >>> >>> > On Apr 2, 2015, at 07:12, Anurag Bhatia wrote: >>> > >>> > Hello everyone! >>> > >>> > >>> > >>> > >>> > I have got two Juniper EX series switches (on virtual chassis) and two >>> SRX >>> > devices on native clustering. >>> > >>> > >>> > I am trying to have a highly available redundancy between them with >>> atleast >>> > 2Gbps capacity all the time but kind of failing. I followed Juniper's >>> > official page here >>> > as >>> well as >>> > this detailed forum link here >>> > < >>> http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way- >>> of-redundancy-between-SRX-and-EX/td-p/181365 >>> > >>> > . >>> > >>> > >>> > I wish to have a case where devices are connected criss cross and >>> following >>> > the documentation I get two ae bundles in EX side and one single reth >>> > bundle on SRX side. Both ae bundles on EX side have identical >>> configuration >>> > and VLAN has both ae interfaces called up. >>> > >>> > >>> > If I do not go for criss cross connectivity like this: >>> > >>> > >>> > >>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>> > >>> > >>> > Then it works all well and redundancy works fine. In this case as long >>> as 1 >>> > out of 4 patch is connected connectivity stays live but this has trade >>> off >>> > that if one EX goes down then I cannot make use of other corresponding >>> SRX. >>> > >>> > If I do criss connectivity, something like: >>> > >>> > >>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>> > EX0 (ae1) >> One patch to SRX1 (reth1) >>> > >>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>> > EX1 (ae2) >> One patch to SRX0 (reth1) >>> > >>> > >>> > In this config system behaves very oddly with one ae pair (and it's >>> > corresponding physical ports) working well while failover to other ae >>> > bundle fails completely. >>> > >>> > >>> > >>> > I was wondering if someone can point me out here. >>> > >>> > >>> > >>> > >>> > Appreciate your time and help! >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > >>> > >>> > Anurag Bhatia >>> > anuragbhatia.com >>> > >>> > Linkedin | Twitter >>> > >>> > Skype: anuragbhatia.com >>> > >>> > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>> >>> >> >> >> -- >> >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | Twitter >> >> Skype: anuragbhatia.com >> >> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >> > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From colinj at gt86car.org.uk Thu Apr 2 18:22:41 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 19:22:41 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551D7B6F.20407@netassist.ua> Message-ID: <65E070A0-8BE2-433C-8B38-FC64515DAD25@gt86car.org.uk> it is not censorship to check traffic follows correct standards and does not deliberately constantly try to exploit. it could easily be solved if china abuse departments co-operate and acknowledge reports and fix if not then country bans are in place and will remain in place until culture change is done colin Sent from my iPhone > On 2 Apr 2015, at 19:01, Bryan Tong wrote: > > As a network consumer and network provider. The traffic seen by the > customer should not be censored. It should be up to the consumer to protect > their services. > > I accept the risk and want uncensored internet access and provide such to > our customers. >> On Apr 2, 2015 11:26 AM, "Max Tulyev" wrote: >> >> Hello! >> >> Very good idea is to sell that and change it to softrouter based on >> PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than >> $1k. >> >>> On 04/01/15 20:01, Frederik Kriewitz wrote: >>> We're wondering if anyone has experience with such a setup? >> >> From Rod.Beck at hibernianetworks.com Thu Apr 2 18:45:17 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Thu, 2 Apr 2015 18:45:17 +0000 Subject: From Europe to Australia via right way In-Reply-To: References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <551C8324.4030309@spectrum.com.au> <551CFEF8.7050405@interia.pl> <20150402084325.GE77104@nbmacvieebi.local> <20150402140317.GA8997@puck.nether.net> , Message-ID: <1428000320720.5313@hibernianetworks.com> Low latency routes like this would be very attractive to financial firms trading in both Europe and Asia. My hunch is that most of these circuits are linear - unprotected. And if you get damage in Siberia or Northern China repairs could be mighty slow. Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com ________________________________________ From: NANOG on behalf of Jared Mauch Sent: Thursday, April 2, 2015 4:23 PM To: Martin Hepworth Cc: nanog at nanog.org Subject: Re: From Europe to Australia via right way > On Apr 2, 2015, at 10:15 AM, Martin Hepworth wrote: > > The new AAE-1 will have 40Tbps connections from Europe to Hong Kong so > hopefully the routes will start to migrate in 2016 and give us an Easterly > route to APAC that has enough capacity to be stable in that direction I think this stability is key, I’ve been watching a testing team go round and round with a telco that seems to think that 1 second hits is acceptable through this area and they are unwilling to resolve it and seem to be begging “please just accept the circuit”. - Jared This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From hugo at slabnet.com Thu Apr 2 18:55:07 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 2 Apr 2015 11:55:07 -0700 Subject: Question about EX - SRX redundancy In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> Message-ID: <20150402185507.GG9851@bamboo.slabnet.com> Putting the EXs in a VC and splitting your AEs across the 2x VC members takes care of that. EXVC (ae1) >> Two Patches to SRX0 (reth1) EXVC (ae2) >> Two Patches to SRX1 (reth1) ...where EXVC is a VC composed of EX0 and EX1, and ae1 and ae2 both have one member interface from each VC member. In a failure of EX0 or EX1, your throughput on ae1 and ae2 halves as they each lose a LAG member, but both SRX0 and SRX1 are still reachable. -- Hugo On Thu 2015-Apr-02 23:50:46 +0530, Anurag Bhatia wrote: >Hi > > > >Yes, > > >Since SRX0 connected to EX0 and SRX1 connected to EX1 (only). Thus either >pair - 0 will work or pair - 1 will work. I wish if criss crossing worked >then failure of one EX would have still made both SRX available. > > >In current worst case scenario - failure of EX0 and SRX1 can cause full >outage. > > > >Thanks. > >On Thu, Apr 2, 2015 at 9:21 PM, Hugo Slabbert wrote: > >> In: >> >> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>> >>> >> with: >> >> > that if one EX goes down then I cannot make use of other corresponding >>>> SRX. >>>> >>> >> Do you mean that e.g. if SRX0 is the chassis cluster primary and EX0 goes >> down, then you can't use SRX0, but you would like to be able to survive EX0 >> going down *without* failing over the SRX chassis cluster to SRX1? >> >> -- >> Hugo >> >> >> On Thu 2015-Apr-02 20:47:03 +0530, Anurag Bhatia >> wrote: >> >> Hi >>> >>> >>> I thought cross chassis lag is supposed by the use of reth bundled at SRX >>> end. I read this is basically the major difference in reth Vs ae bundle in >>> SRX. >>> >>> >>> Interesting factor here is that ae bundles can spread across multiple EX >>> chassis in a virtual chassis environment but this cannot be the case with >>> ae bundles in SRX. >>> >>> >>> >>> >>> Thanks. >>> >>> On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford >>> wrote: >>> >>> It's my understanding that a cross chassis LAG is not supported. If there >>>> is a way, I'm not aware of it. I'm running the same set up as your >>>> working >>>> example in my locations and for now, this suits my requirements. >>>> >>>> Sent from my iPhone >>>> >>>> > On Apr 2, 2015, at 07:12, Anurag Bhatia wrote: >>>> > >>>> > Hello everyone! >>>> > >>>> > >>>> > >>>> > >>>> > I have got two Juniper EX series switches (on virtual chassis) and two >>>> SRX >>>> > devices on native clustering. >>>> > >>>> > >>>> > I am trying to have a highly available redundancy between them with >>>> atleast >>>> > 2Gbps capacity all the time but kind of failing. I followed Juniper's >>>> > official page here >>>> > as >>>> well as >>>> > this detailed forum link here >>>> > < >>>> http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way- >>>> of-redundancy-between-SRX-and-EX/td-p/181365 >>>> > >>>> > . >>>> > >>>> > >>>> > I wish to have a case where devices are connected criss cross and >>>> following >>>> > the documentation I get two ae bundles in EX side and one single reth >>>> > bundle on SRX side. Both ae bundles on EX side have identical >>>> configuration >>>> > and VLAN has both ae interfaces called up. >>>> > >>>> > >>>> > If I do not go for criss cross connectivity like this: >>>> > >>>> > >>>> > >>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>> > >>>> > >>>> > Then it works all well and redundancy works fine. In this case as long >>>> as 1 >>>> > out of 4 patch is connected connectivity stays live but this has trade >>>> off >>>> > that if one EX goes down then I cannot make use of other corresponding >>>> SRX. >>>> > >>>> > If I do criss connectivity, something like: >>>> > >>>> > >>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>> > EX0 (ae1) >> One patch to SRX1 (reth1) >>>> > >>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>> > EX1 (ae2) >> One patch to SRX0 (reth1) >>>> > >>>> > >>>> > In this config system behaves very oddly with one ae pair (and it's >>>> > corresponding physical ports) working well while failover to other ae >>>> > bundle fails completely. >>>> > >>>> > >>>> > >>>> > I was wondering if someone can point me out here. >>>> > >>>> > >>>> > >>>> > >>>> > Appreciate your time and help! >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > >>>> > >>>> > Anurag Bhatia >>>> > anuragbhatia.com >>>> > >>>> > Linkedin | Twitter >>>> > >>>> > Skype: anuragbhatia.com >>>> > >>>> > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>>> >>>> >>> >>> >>> -- >>> >>> >>> Anurag Bhatia >>> anuragbhatia.com >>> >>> Linkedin | Twitter >>> >>> Skype: anuragbhatia.com >>> >>> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>> >> > > >-- > > >Anurag Bhatia >anuragbhatia.com > >Linkedin | Twitter > >Skype: anuragbhatia.com > >PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From joelja at bogus.com Thu Apr 2 19:08:53 2015 From: joelja at bogus.com (joel jaeggli) Date: Thu, 2 Apr 2015 12:08:53 -0700 Subject: From Europe to Australia via right way In-Reply-To: References: <551BC4FA.2050207@interia.pl> <551C6864.5030604@bogus.com> <9D4A24A0-BAF3-4157-BE51-D55D71C3E083@blackrose.org> Message-ID: <551D93C5.8040107@bogus.com> On 4/2/15 10:08 AM, McDonald Richards wrote: > If you want a direct path then SMW3 remains the only cable for the final > leg from Singapore to Perth and it's capacity is only a few hundred > gigabits. There are at least 2 proposed new systems racing to get into > the water between Singapore and Perth to try and address this gap in > supply and demand. it's also another 2000 miles from perth to syd... > On Wed, Apr 1, 2015 at 8:59 PM, Dorian Kim > wrote: > > I don’t believe anyone has significant IP network capacity going EU > -> Australia in that direction, esp. since once you get to > Singapore, the options to get to Australia are limited. > > Even for networks that do have EU to Asia connectivity via Indian > Ocean or land route to north Asia, the preferred path would be via > US and transpac. > > -dorian > > > > On Apr 1, 2015, at 5:51 PM, joel jaeggli > wrote: > > > > On 4/1/15 3:14 AM, Piotr wrote: > >> Hello, > >> > >> There is some telecom, isp which have route from EU to AU via east or > >> south east (via Russia, Red sea or other ways) ? Now i have path > via US > >> and looking something in opposite direction. > > > > telstra ntt reliance retn all have eastbound paths from europe. > > > >> thanks for some info, contact. > >> Piotr > >> > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From Fred.Hunt at wisconsin.gov Thu Apr 2 15:50:10 2015 From: Fred.Hunt at wisconsin.gov (Hunt, Fred - DCF) Date: Thu, 2 Apr 2015 15:50:10 +0000 Subject: Meeting IRS requirements for encrypted transmission of FTI Message-ID: <8c2fac49d96c434b89d3d180621355c4@MEWMAD0P1964.accounts.wistate.us> Does anyone have previous experience meeting IRS requirements for the encrypted transmission of FTI across a LAN and WAN, specifically the requirements called for in IRS Publication 1075? The IRS tests for the following: All FTI data in transit is encrypted when moving across a Wide Area Network (WAN) and within the agency's Local Area Network (LAN). If FTI is transmitted over a LAN or WAN it is encrypted with FIPS 140-2 validated encryption, using at least a 128-bit encryption key. MACsec is what we are looking at right now. I'm wondering if anyone who has been through such an implementation could share lessons learned, gotchas, etc. Any input is appreciated? Fred From bzs at world.std.com Thu Apr 2 19:50:36 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 2 Apr 2015 15:50:36 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> Message-ID: <21789.40332.276582.854995@world.std.com> The essence of this discussion is IMHO a little...um...trite. Be that as it may how many of you have attempted to contact these providers in Chinese? Or do you all have good reason to believe that is never the problem? On April 2, 2015 at 11:05 goemon at anime.net (goemon at anime.net) wrote: > On Thu, 2 Apr 2015, Mark Tinka wrote: > > Most of the spam I get comes from North America. Go figure. I'm not > > about to cut access to that continent off. > > Big difference is that north america is usually responsive to abuse > notifications and sometimes has LEO who will listen. > > china is neither. > > -Dan -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From colinj at gt86car.org.uk Thu Apr 2 20:10:34 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 2 Apr 2015 21:10:34 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <21789.40332.276582.854995@world.std.com> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> Message-ID: <2D14A693-8E41-4660-B4E4-F4E170816F49@gt86car.org.uk> yes have tried chinese language communication as well. none of it works, they dont believe bad traffic is a big issue where it has been proved 100% is bad we do belive this is due to bad abuse practice not informing customers and also deliberately sending bad traffic to test exploits on a large scale. ssl bad cert signing in china is just a example of this culture shutting the door if it is shown unfriendly traffic makes sense to me colin Sent from my iPhone > On 2 Apr 2015, at 20:50, Barry Shein wrote: > > > The essence of this discussion is IMHO a little...um...trite. > > Be that as it may how many of you have attempted to contact these > providers in Chinese? > > Or do you all have good reason to believe that is never the problem? > > >> On April 2, 2015 at 11:05 goemon at anime.net (goemon at anime.net) wrote: >>> On Thu, 2 Apr 2015, Mark Tinka wrote: >>> Most of the spam I get comes from North America. Go figure. I'm not >>> about to cut access to that continent off. >> >> Big difference is that north america is usually responsive to abuse >> notifications and sometimes has LEO who will listen. >> >> china is neither. >> >> -Dan > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Thu Apr 2 20:34:26 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 2 Apr 2015 16:34:26 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <2D14A693-8E41-4660-B4E4-F4E170816F49@gt86car.org.uk> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <2D14A693-8E41-4660-B4E4-F4E170816F49@gt86car.org.uk> Message-ID: <21789.42962.110880.533064@world.std.com> Sounds there's a need for a higher level of dialogue. Hey, if it can be done with Iran... These are identifiable companies not sub-rosa criminal gangs (as we get with spam) so there ought to be some hope. On April 2, 2015 at 21:10 colinj at gt86car.org.uk (Colin Johnston) wrote: > yes have tried chinese language communication as well. > none of it works, they dont believe bad traffic is a big issue where it has been proved 100% is bad > we do belive this is due to bad abuse practice not informing customers and also deliberately sending bad traffic to test exploits on a large scale. > > ssl bad cert signing in china is just a example of this culture > > shutting the door if it is shown unfriendly traffic makes sense to me > > colin > > > Sent from my iPhone > > > On 2 Apr 2015, at 20:50, Barry Shein wrote: > > > > > > The essence of this discussion is IMHO a little...um...trite. > > > > Be that as it may how many of you have attempted to contact these > > providers in Chinese? > > > > Or do you all have good reason to believe that is never the problem? > > > > > >> On April 2, 2015 at 11:05 goemon at anime.net (goemon at anime.net) wrote: > >>> On Thu, 2 Apr 2015, Mark Tinka wrote: > >>> Most of the spam I get comes from North America. Go figure. I'm not > >>> about to cut access to that continent off. > >> > >> Big difference is that north america is usually responsive to abuse > >> notifications and sometimes has LEO who will listen. > >> > >> china is neither. > >> > >> -Dan > > > > -- > > -Barry Shein > > > > The World | bzs at TheWorld.com | http://www.TheWorld.com > > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From nanog at ics-il.net Thu Apr 2 20:37:31 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 2 Apr 2015 15:37:31 -0500 (CDT) Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <21789.42962.110880.533064@world.std.com> Message-ID: <32938721.8030.1428007052944.JavaMail.mhammett@ThunderFuck> If you fix that, I think you deserve an award of some kind. You sir, will have won the Internet. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Barry Shein" To: "Colin Johnston" Cc: goemon at anime.net, nanog at nanog.org Sent: Thursday, April 2, 2015 3:34:26 PM Subject: Re: BGP offloading (fixing legacy router BGP scalability issues) Sounds there's a need for a higher level of dialogue. Hey, if it can be done with Iran... These are identifiable companies not sub-rosa criminal gangs (as we get with spam) so there ought to be some hope. On April 2, 2015 at 21:10 colinj at gt86car.org.uk (Colin Johnston) wrote: > yes have tried chinese language communication as well. > none of it works, they dont believe bad traffic is a big issue where it has been proved 100% is bad > we do belive this is due to bad abuse practice not informing customers and also deliberately sending bad traffic to test exploits on a large scale. > > ssl bad cert signing in china is just a example of this culture > > shutting the door if it is shown unfriendly traffic makes sense to me > > colin > > > Sent from my iPhone > > > On 2 Apr 2015, at 20:50, Barry Shein wrote: > > > > > > The essence of this discussion is IMHO a little...um...trite. > > > > Be that as it may how many of you have attempted to contact these > > providers in Chinese? > > > > Or do you all have good reason to believe that is never the problem? > > > > > >> On April 2, 2015 at 11:05 goemon at anime.net (goemon at anime.net) wrote: > >>> On Thu, 2 Apr 2015, Mark Tinka wrote: > >>> Most of the spam I get comes from North America. Go figure. I'm not > >>> about to cut access to that continent off. > >> > >> Big difference is that north america is usually responsive to abuse > >> notifications and sometimes has LEO who will listen. > >> > >> china is neither. > >> > >> -Dan > > > > -- > > -Barry Shein > > > > The World | bzs at TheWorld.com | http://www.TheWorld.com > > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From me at anuragbhatia.com Thu Apr 2 21:11:35 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 3 Apr 2015 02:41:35 +0530 Subject: Question about EX - SRX redundancy In-Reply-To: <20150402185507.GG9851@bamboo.slabnet.com> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> Message-ID: Hi Tried exactly same. Note: it's ae18 and ae20 on EX side and reth4 on SRX side. Initially worked but when I took down ae18, i.e ae18 is disabled, now on ae20 I am getting: show interfaces ae20 Physical interface: ae20, Enabled, Physical link is Up Interface index: 533, SNMP ifIndex: 924 Link-level type: Ethernet, MTU: 1514, Speed: 2Gbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 0 on reth4 on SRX I am getting: show interfaces reth4 Physical interface: reth4, Enabled, Physical link is Down Interface index: 132, SNMP ifIndex: 696 Any idea why so? All physical ports are up (none is shut) and only thing which I shut is one of ae bundles. Also rather then disabling ae18 if I disabled associated physical ports behavior is just the same i.e reth4 goes down. Thanks for your time and help! On Fri, Apr 3, 2015 at 12:25 AM, Hugo Slabbert wrote: > Putting the EXs in a VC and splitting your AEs across the 2x VC members > takes care of that. > > EXVC (ae1) >> Two Patches to SRX0 (reth1) > EXVC (ae2) >> Two Patches to SRX1 (reth1) > > ...where EXVC is a VC composed of EX0 and EX1, and ae1 and ae2 both have > one member interface from each VC member. > > In a failure of EX0 or EX1, your throughput on ae1 and ae2 halves as they > each lose a LAG member, but both SRX0 and SRX1 are still reachable. > > -- > Hugo > > > On Thu 2015-Apr-02 23:50:46 +0530, Anurag Bhatia > wrote: > > Hi >> >> >> >> Yes, >> >> >> Since SRX0 connected to EX0 and SRX1 connected to EX1 (only). Thus either >> pair - 0 will work or pair - 1 will work. I wish if criss crossing worked >> then failure of one EX would have still made both SRX available. >> >> >> In current worst case scenario - failure of EX0 and SRX1 can cause full >> outage. >> >> >> >> Thanks. >> >> On Thu, Apr 2, 2015 at 9:21 PM, Hugo Slabbert wrote: >> >> In: >>> >>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>> >>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>> >>>>> >>>> with: >>> >>> > that if one EX goes down then I cannot make use of other corresponding >>> >>>> SRX. >>>>> >>>>> >>>> Do you mean that e.g. if SRX0 is the chassis cluster primary and EX0 >>> goes >>> down, then you can't use SRX0, but you would like to be able to survive >>> EX0 >>> going down *without* failing over the SRX chassis cluster to SRX1? >>> >>> -- >>> Hugo >>> >>> >>> On Thu 2015-Apr-02 20:47:03 +0530, Anurag Bhatia >>> wrote: >>> >>> Hi >>> >>>> >>>> >>>> I thought cross chassis lag is supposed by the use of reth bundled at >>>> SRX >>>> end. I read this is basically the major difference in reth Vs ae bundle >>>> in >>>> SRX. >>>> >>>> >>>> Interesting factor here is that ae bundles can spread across multiple EX >>>> chassis in a virtual chassis environment but this cannot be the case >>>> with >>>> ae bundles in SRX. >>>> >>>> >>>> >>>> >>>> Thanks. >>>> >>>> On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford >>>> wrote: >>>> >>>> It's my understanding that a cross chassis LAG is not supported. If >>>> there >>>> >>>>> is a way, I'm not aware of it. I'm running the same set up as your >>>>> working >>>>> example in my locations and for now, this suits my requirements. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> > On Apr 2, 2015, at 07:12, Anurag Bhatia wrote: >>>>> > >>>>> > Hello everyone! >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > I have got two Juniper EX series switches (on virtual chassis) and >>>>> two >>>>> SRX >>>>> > devices on native clustering. >>>>> > >>>>> > >>>>> > I am trying to have a highly available redundancy between them with >>>>> atleast >>>>> > 2Gbps capacity all the time but kind of failing. I followed Juniper's >>>>> > official page here >>>>> > as >>>>> well as >>>>> > this detailed forum link here >>>>> > < >>>>> http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way- >>>>> of-redundancy-between-SRX-and-EX/td-p/181365 >>>>> > >>>>> > . >>>>> > >>>>> > >>>>> > I wish to have a case where devices are connected criss cross and >>>>> following >>>>> > the documentation I get two ae bundles in EX side and one single reth >>>>> > bundle on SRX side. Both ae bundles on EX side have identical >>>>> configuration >>>>> > and VLAN has both ae interfaces called up. >>>>> > >>>>> > >>>>> > If I do not go for criss cross connectivity like this: >>>>> > >>>>> > >>>>> > >>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>> > >>>>> > >>>>> > Then it works all well and redundancy works fine. In this case as >>>>> long >>>>> as 1 >>>>> > out of 4 patch is connected connectivity stays live but this has >>>>> trade >>>>> off >>>>> > that if one EX goes down then I cannot make use of other >>>>> corresponding >>>>> SRX. >>>>> > >>>>> > If I do criss connectivity, something like: >>>>> > >>>>> > >>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>> > EX0 (ae1) >> One patch to SRX1 (reth1) >>>>> > >>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>> > EX1 (ae2) >> One patch to SRX0 (reth1) >>>>> > >>>>> > >>>>> > In this config system behaves very oddly with one ae pair (and it's >>>>> > corresponding physical ports) working well while failover to other ae >>>>> > bundle fails completely. >>>>> > >>>>> > >>>>> > >>>>> > I was wondering if someone can point me out here. >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > Appreciate your time and help! >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > >>>>> > >>>>> > Anurag Bhatia >>>>> > anuragbhatia.com >>>>> > >>>>> > Linkedin | Twitter >>>>> > >>>>> > Skype: anuragbhatia.com >>>>> > >>>>> > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E >>>>> 58E2 >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> >>>> Anurag Bhatia >>>> anuragbhatia.com >>>> >>>> Linkedin | Twitter >>>> >>>> Skype: anuragbhatia.com >>>> >>>> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>>> >>>> >>> >> >> -- >> >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | Twitter >> >> Skype: anuragbhatia.com >> >> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >> > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From goemon at anime.net Thu Apr 2 21:19:45 2015 From: goemon at anime.net (goemon at anime.net) Date: Thu, 2 Apr 2015 14:19:45 -0700 (PDT) Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <21789.40332.276582.854995@world.std.com> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> Message-ID: emails to the registered contacts bounce, for one, undeliverable. which is a bit of a change from the old chinanet auto-responder which auto-responded to every email with "i cannot find that IP or that IP not by my Control. Please send the correct IP". a number of years back i did have someone contact in chinese and the response was that the customer was doing nothing wrong. -Dan On Thu, 2 Apr 2015, Barry Shein wrote: > > The essence of this discussion is IMHO a little...um...trite. > > Be that as it may how many of you have attempted to contact these > providers in Chinese? > > Or do you all have good reason to believe that is never the problem? > > > On April 2, 2015 at 11:05 goemon at anime.net (goemon at anime.net) wrote: > > On Thu, 2 Apr 2015, Mark Tinka wrote: > > > Most of the spam I get comes from North America. Go figure. I'm not > > > about to cut access to that continent off. > > > > Big difference is that north america is usually responsive to abuse > > notifications and sometimes has LEO who will listen. > > > > china is neither. > > > > -Dan > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From hugo at slabnet.com Thu Apr 2 22:22:34 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 2 Apr 2015 15:22:34 -0700 Subject: Question about EX - SRX redundancy In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> Message-ID: <20150402222234.GH9851@bamboo.slabnet.com> I just want to confirm your setup. The "criss-cross" setup you were describing is different from what I described. You listed: >>>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>>> > EX0 (ae1) >> One patch to SRX1 (reth1) >>>>>> > >>>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>> > EX1 (ae2) >> One patch to SRX0 (reth1) ...meaning that your AEs cannot survive losing either one of the EX VC members, and you're splitting each AE's connectivity across the two SRX chassis cluster members. You need to dedicate an AE to an SRX chassis cluster member. IOW: ae18 should have one LAG member on EX0 and one member on EX1, and both of those physical ports go to SRX0. Likewise, ae20 should have one LAG member on EX0 and one member on EX1, and both of those physical ports go to SRX1. When you shut one of the AEs (e.g. ae18) in the setup I describe, you *will* lose connectivity to its corresponding SRX, as those are fate-sharing. You would need to configure interface monitoring on the chassis cluster to flip over the primary to 2nd SRX in order to survive that, since the second AE (ae20) that is tied to the 2nd SRX is still up. Your failure modes are: e.g. 1: lose an EX, you lose the throughput that's being contributed to the AE by that VC member's ports, but both SRXs remain available and the primary shouldn't flip (provided your node priorities and interface-monitoring weights are set accordingly). e.g. 2: shut an AE (which spans both EX VC members), one SRX goes dark since you've killed the AE that's dedicated to it, and the primary will need to flip (either through interface monitoring or manually) in order for the setup to remain online. -- Hugo On Fri 2015-Apr-03 02:41:35 +0530, Anurag Bhatia wrote: >Hi > > >Tried exactly same. Note: it's ae18 and ae20 on EX side and reth4 on SRX >side. > > >Initially worked but when I took down ae18, i.e ae18 is disabled, now on >ae20 I am getting: > >show interfaces ae20 >Physical interface: ae20, Enabled, Physical link is Up > Interface index: 533, SNMP ifIndex: 924 > Link-level type: Ethernet, MTU: 1514, Speed: 2Gbps, BPDU Error: None, >MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, > Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth >needed: 0 > > > >on reth4 on SRX I am getting: > >show interfaces reth4 >Physical interface: reth4, Enabled, Physical link is Down > Interface index: 132, SNMP ifIndex: 696 > > > >Any idea why so? All physical ports are up (none is shut) and only thing >which I shut is one of ae bundles. Also rather then disabling ae18 if I >disabled associated physical ports behavior is just the same i.e reth4 goes >down. > > > > >Thanks for your time and help! > > > >On Fri, Apr 3, 2015 at 12:25 AM, Hugo Slabbert wrote: > >> Putting the EXs in a VC and splitting your AEs across the 2x VC members >> takes care of that. >> >> EXVC (ae1) >> Two Patches to SRX0 (reth1) >> EXVC (ae2) >> Two Patches to SRX1 (reth1) >> >> ...where EXVC is a VC composed of EX0 and EX1, and ae1 and ae2 both have >> one member interface from each VC member. >> >> In a failure of EX0 or EX1, your throughput on ae1 and ae2 halves as they >> each lose a LAG member, but both SRX0 and SRX1 are still reachable. >> >> -- >> Hugo >> >> >> On Thu 2015-Apr-02 23:50:46 +0530, Anurag Bhatia >> wrote: >> >> Hi >>> >>> >>> >>> Yes, >>> >>> >>> Since SRX0 connected to EX0 and SRX1 connected to EX1 (only). Thus either >>> pair - 0 will work or pair - 1 will work. I wish if criss crossing worked >>> then failure of one EX would have still made both SRX available. >>> >>> >>> In current worst case scenario - failure of EX0 and SRX1 can cause full >>> outage. >>> >>> >>> >>> Thanks. >>> >>> On Thu, Apr 2, 2015 at 9:21 PM, Hugo Slabbert wrote: >>> >>> In: >>>> >>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>> >>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>> >>>>>> >>>>> with: >>>> >>>> > that if one EX goes down then I cannot make use of other corresponding >>>> >>>>> SRX. >>>>>> >>>>>> >>>>> Do you mean that e.g. if SRX0 is the chassis cluster primary and EX0 >>>> goes >>>> down, then you can't use SRX0, but you would like to be able to survive >>>> EX0 >>>> going down *without* failing over the SRX chassis cluster to SRX1? >>>> >>>> -- >>>> Hugo >>>> >>>> >>>> On Thu 2015-Apr-02 20:47:03 +0530, Anurag Bhatia >>>> wrote: >>>> >>>> Hi >>>> >>>>> >>>>> >>>>> I thought cross chassis lag is supposed by the use of reth bundled at >>>>> SRX >>>>> end. I read this is basically the major difference in reth Vs ae bundle >>>>> in >>>>> SRX. >>>>> >>>>> >>>>> Interesting factor here is that ae bundles can spread across multiple EX >>>>> chassis in a virtual chassis environment but this cannot be the case >>>>> with >>>>> ae bundles in SRX. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford >>>>> wrote: >>>>> >>>>> It's my understanding that a cross chassis LAG is not supported. If >>>>> there >>>>> >>>>>> is a way, I'm not aware of it. I'm running the same set up as your >>>>>> working >>>>>> example in my locations and for now, this suits my requirements. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> > On Apr 2, 2015, at 07:12, Anurag Bhatia wrote: >>>>>> > >>>>>> > Hello everyone! >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > I have got two Juniper EX series switches (on virtual chassis) and >>>>>> two >>>>>> SRX >>>>>> > devices on native clustering. >>>>>> > >>>>>> > >>>>>> > I am trying to have a highly available redundancy between them with >>>>>> atleast >>>>>> > 2Gbps capacity all the time but kind of failing. I followed Juniper's >>>>>> > official page here >>>>>> > as >>>>>> well as >>>>>> > this detailed forum link here >>>>>> > < >>>>>> http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way- >>>>>> of-redundancy-between-SRX-and-EX/td-p/181365 >>>>>> > >>>>>> > . >>>>>> > >>>>>> > >>>>>> > I wish to have a case where devices are connected criss cross and >>>>>> following >>>>>> > the documentation I get two ae bundles in EX side and one single reth >>>>>> > bundle on SRX side. Both ae bundles on EX side have identical >>>>>> configuration >>>>>> > and VLAN has both ae interfaces called up. >>>>>> > >>>>>> > >>>>>> > If I do not go for criss cross connectivity like this: >>>>>> > >>>>>> > >>>>>> > >>>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>> > >>>>>> > >>>>>> > Then it works all well and redundancy works fine. In this case as >>>>>> long >>>>>> as 1 >>>>>> > out of 4 patch is connected connectivity stays live but this has >>>>>> trade >>>>>> off >>>>>> > that if one EX goes down then I cannot make use of other >>>>>> corresponding >>>>>> SRX. >>>>>> > >>>>>> > If I do criss connectivity, something like: >>>>>> > >>>>>> > >>>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>>> > EX0 (ae1) >> One patch to SRX1 (reth1) >>>>>> > >>>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>> > EX1 (ae2) >> One patch to SRX0 (reth1) >>>>>> > >>>>>> > >>>>>> > In this config system behaves very oddly with one ae pair (and it's >>>>>> > corresponding physical ports) working well while failover to other ae >>>>>> > bundle fails completely. >>>>>> > >>>>>> > >>>>>> > >>>>>> > I was wondering if someone can point me out here. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > Appreciate your time and help! >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > >>>>>> > Anurag Bhatia >>>>>> > anuragbhatia.com >>>>>> > >>>>>> > Linkedin | Twitter >>>>>> > >>>>>> > Skype: anuragbhatia.com >>>>>> > >>>>>> > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E >>>>>> 58E2 >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Anurag Bhatia >>>>> anuragbhatia.com >>>>> >>>>> Linkedin | Twitter >>>>> >>>>> Skype: anuragbhatia.com >>>>> >>>>> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>>>> >>>>> >>>> >>> >>> -- >>> >>> >>> Anurag Bhatia >>> anuragbhatia.com >>> >>> Linkedin | Twitter >>> >>> Skype: anuragbhatia.com >>> >>> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>> >> > > >-- > > >Anurag Bhatia >anuragbhatia.com > >Linkedin | Twitter > >Skype: anuragbhatia.com > >PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill at herrin.us Thu Apr 2 23:21:08 2015 From: bill at herrin.us (William Herrin) Date: Thu, 2 Apr 2015 19:21:08 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: Message-ID: On Wed, Apr 1, 2015 at 1:01 PM, Frederik Kriewitz wrote: > In > practice the biggest problem with [Cisco 6500s] is their poor BGP scalability > due to the CPU/memory limitations. Hi Frederik: Are you sure about that? I would expect you to hit the wall on the TCAM long before CPU/RAM limitations. Check your log for errors along the lines of "FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched." This might be masked as a CPU problem since routing for destinations which fall out of the TCAM is forced up to the main CPU. If this is your problem and you're talking about sup-720-3bxl's with a 1M TCAM, you can change how much of the TCAM is allocated to which functions for now. Longer term, you either upgrade to something with a bigger TCAM or you reduce the number of routes you carry by introducing superset routes such as a default route and then filtering out the more-specifics your customers are least likely to use. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bholloway at pavlovmedia.com Thu Apr 2 20:11:43 2015 From: bholloway at pavlovmedia.com (Bryan Holloway) Date: Thu, 2 Apr 2015 20:11:43 +0000 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <21789.40332.276582.854995@world.std.com> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> , <21789.40332.276582.854995@world.std.com> Message-ID: I, for one, wouldn't mind seeing more dialog regarding the original poster's query ... > On Apr 2, 2015, at 14:53, Barry Shein wrote: > > > The essence of this discussion is IMHO a little...um...trite. > > Be that as it may how many of you have attempted to contact these > providers in Chinese? > > Or do you all have good reason to believe that is never the problem? > > >> On April 2, 2015 at 11:05 goemon at anime.net (goemon at anime.net) wrote: >>> On Thu, 2 Apr 2015, Mark Tinka wrote: >>> Most of the spam I get comes from North America. Go figure. I'm not >>> about to cut access to that continent off. >> >> Big difference is that north america is usually responsive to abuse >> notifications and sometimes has LEO who will listen. >> >> china is neither. >> >> -Dan > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From Bob.Watson at wwt.com Thu Apr 2 22:13:10 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Thu, 2 Apr 2015 22:13:10 +0000 Subject: Meeting IRS requirements for encrypted transmission of FTI In-Reply-To: <8c2fac49d96c434b89d3d180621355c4@MEWMAD0P1964.accounts.wistate.us> References: <8c2fac49d96c434b89d3d180621355c4@MEWMAD0P1964.accounts.wistate.us> Message-ID: <37ABCE16-7867-46E0-B09E-D80813200B20@wwt.com> Macsec use cases are valid when working with hop by hop encryption needs between closets / buildings where structured wiring is not within control of agency personnel, in the case of other states we provide consulting services to, think multi tenant building with shared closet from other state agencies or building leases with outsourced cabling. Router / firewall based Vpn is an option as well if transiting a consolidated state network or sp based public or private network. The physical sec control to mitigate true end to end helps reign back some of the costed options. 9.3.16.6 Transmission Confidentiality and Integrity (SC-8) Information systems that receive, process, store, or transmit FTI, must: a. Protecttheconfidentialityandintegrityoftransmittedinformation. b. Implement cryptographic mechanisms to prevent unauthorized disclosure of FTI and detect changes to information during transmission across the wide area network (WAN) and within the local area network (LAN). (CE1) If encryption is not used, to reduce the risk of unauthorized access to FTI, the agency must use physical means (e.g., by employing protected physical distribution systems) to ensure that FTI is not accessible to unauthorized users. The agency must ensure that all network infrastructure, access points, wiring, conduits, and cabling are within the control of authorized agency personnel. Network monitoring capabilities must be implemented to detect and monitor for suspicious network traffic. For physical security protections of transmission medium, see Section 9.3.11.4, Access Control for Transmission Medium (PE-4). This control applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, fax machines). Sent from my iPad On Apr 2, 2015, at 2:15 PM, Hunt, Fred - DCF > wrote: Does anyone have previous experience meeting IRS requirements for the encrypted transmission of FTI across a LAN and WAN, specifically the requirements called for in IRS Publication 1075? The IRS tests for the following: All FTI data in transit is encrypted when moving across a Wide Area Network (WAN) and within the agency's Local Area Network (LAN). If FTI is transmitted over a LAN or WAN it is encrypted with FIPS 140-2 validated encryption, using at least a 128-bit encryption key. MACsec is what we are looking at right now. I'm wondering if anyone who has been through such an implementation could share lessons learned, gotchas, etc. Any input is appreciated? Fred From fred at cisco.com Fri Apr 3 03:44:21 2015 From: fred at cisco.com (Fred Baker (fred)) Date: Fri, 3 Apr 2015 03:44:21 +0000 Subject: Meeting IRS requirements for encrypted transmission of FTI In-Reply-To: <37ABCE16-7867-46E0-B09E-D80813200B20@wwt.com> References: <8c2fac49d96c434b89d3d180621355c4@MEWMAD0P1964.accounts.wistate.us> <37ABCE16-7867-46E0-B09E-D80813200B20@wwt.com> Message-ID: Dumb question. So this is essentially physical or link layer encryption. That’s fine out on the wire, but is decrypted in memory (if I understand what you said), and requires point to point connectivity to be any better than that. Are you aware of anyone at NIST or other places suggesting end to end encryption? > On Apr 2, 2015, at 3:13 PM, Watson, Bob wrote: > > > Macsec use cases are valid when working with hop by hop encryption needs between closets / buildings where structured wiring is not within control of agency personnel, in the case of other states we provide consulting services to, think multi tenant building with shared closet from other state agencies or building leases with outsourced cabling. Router / firewall based Vpn is an option as well if transiting a consolidated state network or sp based public or private network. The physical sec control to mitigate true end to end helps reign back some of the costed options. > > > 9.3.16.6 Transmission Confidentiality and Integrity (SC-8) > > Information systems that receive, process, store, or transmit FTI, must: > > a. Protecttheconfidentialityandintegrityoftransmittedinformation. > b. Implement cryptographic mechanisms to prevent unauthorized disclosure of FTI > > and detect changes to information during transmission across the wide area network (WAN) and within the local area network (LAN). (CE1) > > If encryption is not used, to reduce the risk of unauthorized access to FTI, the agency must use physical means (e.g., by employing protected physical distribution systems) to ensure that FTI is not accessible to unauthorized users. The agency must ensure that all network infrastructure, access points, wiring, conduits, and cabling are within the control of authorized agency personnel. Network monitoring capabilities must be implemented to detect and monitor for suspicious network traffic. For physical security protections of transmission medium, see Section 9.3.11.4, Access Control for Transmission Medium (PE-4). > > This control applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, fax machines). > > Sent from my iPad > > On Apr 2, 2015, at 2:15 PM, Hunt, Fred - DCF > wrote: > > Does anyone have previous experience meeting IRS requirements for the encrypted transmission of FTI across a LAN and WAN, specifically the requirements called for in IRS Publication 1075? > The IRS tests for the following: > All FTI data in transit is encrypted when moving across a Wide Area Network (WAN) and within the agency's Local Area Network (LAN). If FTI is transmitted over a LAN or WAN it is encrypted with FIPS 140-2 validated encryption, using at least a 128-bit encryption key. > > MACsec is what we are looking at right now. I'm wondering if anyone who has been through such an implementation could share lessons learned, gotchas, etc. > > Any input is appreciated? > > Fred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nanog at afxr.net Fri Apr 3 03:53:53 2015 From: nanog at afxr.net (Randy) Date: Thu, 02 Apr 2015 22:53:53 -0500 Subject: Any google network admins out there? In-Reply-To: <20150402222234.GH9851@bamboo.slabnet.com> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> Message-ID: <551E0ED1.5000806@afxr.net> I've started to get some message today from google claiming that my computer or network was sending automated queries, and they are blocking me. I'm not sending automated queries, Ive logged all of my outbound traffic and there is only my browser traffic going to google. I'm not responsible for any one else on "my network" since it is owned by my ISP, and solely blocking me based on what some one else with an ip address close to mine is not an acceptable practice to have for an address used for personal web browsing. I would like to know if there is any way to get into contact with google about this other then by legal means? From colinj at gt86car.org.uk Fri Apr 3 05:08:51 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 3 Apr 2015 06:08:51 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <551CF2DD.6080805@seacom.mu> References: <551CE8BE.1010304@seacom.mu> <551CF2DD.6080805@seacom.mu> Message-ID: customers are paying for good traffic to generate eye balls and revenue, not bad traffic which clouds the good work done. I know we are getting into filtering traffic wars here but if the source admins refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then why not put up walls. I would like country trade talks to get down to the technical point that there are some fundamental problems being seen with bad traffic usage and it is significant percentage of waste bandwidth. Colin > On 2 Apr 2015, at 08:42, Mark Tinka wrote: > > > >> On 2/Apr/15 09:35, Colin Johnston wrote: >> or ignore/block russia and north korea and china network blocks >> takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. >> Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not > > I think that's a little extreme, especially since customers are paying > me to deliver packets to the whole Internet. > > But that's just me... > > Mark. From jchisolm at computer.org Fri Apr 3 06:03:54 2015 From: jchisolm at computer.org (Joe Chisolm) Date: Fri, 03 Apr 2015 01:03:54 -0500 Subject: PoC for shortlisted DDoS Vendors In-Reply-To: <551C222A.6080004@noor.net> References: <551C222A.6080004@noor.net> Message-ID: <551E2D4A.30709@computer.org> I have recommended RioRey to our clients. There have been no, or only minor, issues with any of the testing, mismatch with optics and that was a client issue. The RioRey box can be set in full bypass, monitor, or mitigation. You can install in bypass mode first to make sure everything is wired up correctly, then switch on monitor mode and see how it is doing. When your comfort level increases you can turn on full mitigation mode. Full disclosure I did work for RioRey years back, but for our clients we always try to recommend what works best for the client. On 04/01/2015 11:51 AM, Mohamed Kamal wrote: > In our effort to pick up a reasonably priced DDoS appliance with a > competitive features, we're in a process of doing a PoC for the > following shortlisted vendors: > > 1- RioRey > 2- NSFocus > 3- Arbor > 4- A10 > > The setup will be inline. So it would be great if anyone have done this > before and can help provide the appropriate tools, advices, or the > testing documents for efficient PoC. > > Thanks. > -- Joe Chisolm Computer Translations, Inc. Network and Datacenter Consulting Marble Falls, Tx. From pavel.odintsov at gmail.com Fri Apr 3 06:27:40 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Fri, 3 Apr 2015 09:27:40 +0300 Subject: PoC for shortlisted DDoS Vendors In-Reply-To: <551D5C83.1050005@noor.net> References: <20150402065225.61BB32C04A8@mail.nanog.org> <551D5C83.1050005@noor.net> Message-ID: Hello! Yes, my toolkit can detect only volumetric attacks now. But I have finished performance tests for http protocol parser which could work on wire speed too. And I'm sure I will add support for http attack detection soon. Btw, syn flood attack detection could be implemented in few hours in current code base. If anyone interested in it I will do it shortly. In my day to day work we got fewbattacks everyday. They divided 50/50 for dns/ssdp/snmp amplification and syn flood on http servers. Other attacks is not dangerous for our network and backbone and mitifated manually in each case. On Thursday, April 2, 2015, Mohamed Kamal wrote: > Hello Pavel, > > I'm certainly biased to the open-source tools if they do the job required, > and I appreciate your effort exerted on this project. However, based upon > what I saw under the "features" list of your tool, I assume that it can > detect only volumetric DDoS attacks based upon anomalies such as excessive > number of packets/bits/connections/flows per second based upon some > previously learnt or set threshold values. > > But what about the protocol types of attack, which, in my humble opinion > is becoming more aggressive day after day? > > Mohamed Kamal > Core Network Sr. Engineer > > On 4/2/2015 5:03 PM, Pavel Odintsov wrote: > > Hello! > > What about open source alternatives? Main part of commercial ddos > filters are simple high performace firewalls with detection logic (which > much times more stupid than well trained network engineer). > > But attacks for ISP is not arrived so iften and detection part coukd be > executed manually (or with oss tools like netflow analyzers or my own > FastNetMon toolkit). > > For wire speed filtration on 10ge (and even more if you have modern cpu; > up to 40ge) you could use netmap-ipfw with linux or freebsd with simple > patches (for enabling multy process mode). > > On Thursday, April 2, 2015, dennis at justipit.com > > wrote: > >> You should include Radware on that list . >> >> ----- Reply message ----- >> From: "Mohamed Kamal" >> To: "NANOG" >> Subject: PoC for shortlisted DDoS Vendors >> Date: Wed, Apr 1, 2015 9:51 AM >> >> In our effort to pick up a reasonably priced DDoS appliance with a >> competitive features, we're in a process of doing a PoC for the >> following shortlisted vendors: >> >> 1- RioRey >> 2- NSFocus >> 3- Arbor >> 4- A10 >> >> The setup will be inline. So it would be great if anyone have done this >> before and can help provide the appropriate tools, advices, or the >> testing documents for efficient PoC. >> >> Thanks. >> >> -- >> Mohamed Kamal >> Core Network Sr. Engineer > > > > -- > Sincerely yours, Pavel Odintsov > > > -- Sincerely yours, Pavel Odintsov From pmsac.nanog at gmail.com Fri Apr 3 10:39:36 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Fri, 3 Apr 2015 11:39:36 +0100 Subject: Any google network admins out there? In-Reply-To: <551E0ED1.5000806@afxr.net> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> Message-ID: https://support.google.com/websearch/answer/86640?hl=en On 3 April 2015 at 04:53, Randy wrote: > I've started to get some message today from google claiming that my > computer or network was sending automated queries, and they are blocking me. > I'm not sending automated queries, Ive logged all of my outbound traffic > and there is only my browser traffic going to google. > > I'm not responsible for any one else on "my network" since it is owned by > my ISP, and solely blocking me based on what some one else with an ip > address close to mine is not an acceptable practice to have for an address > used for personal web browsing. > I would like to know if there is any way to get into contact with google > about this other then by legal means? > From bzs at world.std.com Fri Apr 3 16:57:41 2015 From: bzs at world.std.com (Barry Shein) Date: Fri, 3 Apr 2015 12:57:41 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> Message-ID: <21790.50821.147502.621931@world.std.com> On April 2, 2015 at 14:19 goemon at anime.net (goemon at anime.net) wrote: > a number of years back i did have someone contact in chinese and the > response was that the customer was doing nothing wrong. Ok, that's progress of a sort, what's the authoritative source of right and wrong, something beyond "c'mon it's obvious!"? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From cscora at apnic.net Fri Apr 3 18:14:57 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Apr 2015 04:14:57 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201504031814.t33IEvg1024420@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 04 Apr, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 539115 Prefixes after maximum aggregation (per Origin AS): 205855 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 262872 Total ASes present in the Internet Routing Table: 49858 Prefixes per ASN: 10.81 Origin-only ASes present in the Internet Routing Table: 36536 Origin ASes announcing only one prefix: 16266 Transit ASes present in the Internet Routing Table: 6290 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 59 Max AS path prepend of ASN ( 55644) 56 Prefixes from unregistered ASNs in the Routing Table: 1130 Unregistered ASNs in the Routing Table: 410 Number of 32-bit ASNs allocated by the RIRs: 9061 Number of 32-bit ASNs visible in the Routing Table: 7032 Prefixes from 32-bit ASNs in the Routing Table: 25439 Number of bogon 32-bit ASNs visible in the Routing Table: 4 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 372 Number of addresses announced to Internet: 2740392868 Equivalent to 163 /8s, 87 /16s and 19 /24s Percentage of available address space announced: 74.0 Percentage of allocated address space announced: 74.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 181677 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133140 Total APNIC prefixes after maximum aggregation: 38684 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 138839 Unique aggregates announced from the APNIC address blocks: 56616 APNIC Region origin ASes present in the Internet Routing Table: 5036 APNIC Prefixes per ASN: 27.57 APNIC Region origin ASes announcing only one prefix: 1214 APNIC Region transit ASes present in the Internet Routing Table: 872 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 59 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1365 Number of APNIC addresses announced to Internet: 747782656 Equivalent to 44 /8s, 146 /16s and 66 /24s Percentage of available APNIC address space announced: 87.4 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, 131072-135580 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: 177915 Total ARIN prefixes after maximum aggregation: 87703 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 180188 Unique aggregates announced from the ARIN address blocks: 84227 ARIN Region origin ASes present in the Internet Routing Table: 16510 ARIN Prefixes per ASN: 10.91 ARIN Region origin ASes announcing only one prefix: 6072 ARIN Region transit ASes present in the Internet Routing Table: 1716 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 386 Number of ARIN addresses announced to Internet: 1064986400 Equivalent to 63 /8s, 122 /16s and 103 /24s Percentage of available ARIN address space announced: 56.3 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, 393216-394239 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: 130559 Total RIPE prefixes after maximum aggregation: 65255 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 136997 Unique aggregates announced from the RIPE address blocks: 84491 RIPE Region origin ASes present in the Internet Routing Table: 17929 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 8164 RIPE Region transit ASes present in the Internet Routing Table: 2969 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3568 Number of RIPE addresses announced to Internet: 694387588 Equivalent to 41 /8s, 99 /16s and 131 /24s Percentage of available RIPE address space announced: 100.9 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, 196608-202239 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: 59226 Total LACNIC prefixes after maximum aggregation: 11187 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 68995 Unique aggregates announced from the LACNIC address blocks: 32144 LACNIC Region origin ASes present in the Internet Routing Table: 2423 LACNIC Prefixes per ASN: 28.48 LACNIC Region origin ASes announcing only one prefix: 623 LACNIC Region transit ASes present in the Internet Routing Table: 495 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 22 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1609 Number of LACNIC addresses announced to Internet: 168041728 Equivalent to 10 /8s, 4 /16s and 29 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12673 Total AfriNIC prefixes after maximum aggregation: 2982 AfriNIC Deaggregation factor: 4.25 Prefixes being announced from the AfriNIC address blocks: 13724 Unique aggregates announced from the AfriNIC address blocks: 5057 AfriNIC Region origin ASes present in the Internet Routing Table: 725 AfriNIC Prefixes per ASN: 18.93 AfriNIC Region origin ASes announcing only one prefix: 193 AfriNIC Region transit ASes present in the Internet Routing Table: 159 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 104 Number of AfriNIC addresses announced to Internet: 64489472 Equivalent to 3 /8s, 216 /16s and 8 /24s Percentage of available AfriNIC address space announced: 64.1 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 4766 2877 11556 919 Korea Telecom 17974 2794 904 78 PT Telekomunikasi Indonesia 7545 2546 336 128 TPG Telecom Limited 4755 2003 422 212 TATA Communications formerly 4538 1760 4190 71 China Education and Research 9829 1678 1324 47 National Internet Backbone 9808 1555 8717 28 Guangdong Mobile Communicatio 4808 1452 2259 447 CNCGROUP IP network China169 9583 1405 116 574 Sify Limited 9498 1313 334 94 BHARTI Airtel Ltd. 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 3018 2956 142 Cox Communications Inc. 6389 2880 3688 51 BellSouth.net Inc. 3356 2541 10683 475 Level 3 Communications, Inc. 18566 2041 379 183 MegaPath Corporation 20115 1851 1832 431 Charter Communications 6983 1752 866 245 EarthLink, Inc. 4323 1618 1020 407 tw telecom holdings, inc. 30036 1508 308 527 Mediacom Communications Corp 701 1391 11270 677 MCI Communications Services, 22561 1338 412 242 CenturyTel Internet Holdings, 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 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1980 303 357 TELLCOM ILETISIM HIZMETLERI A 20940 1689 648 1248 Akamai International B.V. 8402 1214 544 15 OJSC "Vimpelcom" 6849 1212 356 24 JSC "Ukrtelecom" 31148 1046 45 21 Freenet Ltd. 13188 1024 96 72 TOV "Bank-Inform" 12479 898 801 79 France Telecom Espana SA 8551 885 373 48 Bezeq International-Ltd 6830 852 2341 452 Liberty Global Operations B.V 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 3156 514 222 Telmex Colombia S.A. 28573 2358 2173 118 NET Servi�os de Comunica��o S 7303 1704 1102 241 Telecom Argentina S.A. 6147 1596 374 30 Telefonica del Peru S.A.A. 8151 1559 3159 449 Uninet S.A. de C.V. 6503 1209 421 57 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 963 2325 35 Tim Celular S.A. 3816 922 418 154 COLOMBIA TELECOMUNICACIONES S 18881 867 1036 22 Global Village Telecom 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 8452 1694 958 13 TE-AS 24863 962 284 27 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 417 1229 32 ETISALAT MISR 37492 318 159 71 Orange Tunisie 24835 300 144 9 Vodafone Data 3741 249 857 208 Internet Solutions 29571 232 21 13 Cote d'Ivoire Telecom 36947 192 807 13 Telecom Algeria 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3156 514 222 Telmex Colombia S.A. 22773 3018 2956 142 Cox Communications Inc. 6389 2880 3688 51 BellSouth.net Inc. 4766 2877 11556 919 Korea Telecom 17974 2794 904 78 PT Telekomunikasi Indonesia 7545 2546 336 128 TPG Telecom Limited 3356 2541 10683 475 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2358 2173 118 NET Servi�os de Comunica��o S 18566 2041 379 183 MegaPath Corporation 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 3018 2876 Cox Communications Inc. 6389 2880 2829 BellSouth.net Inc. 17974 2794 2716 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2546 2418 TPG Telecom Limited 28573 2358 2240 NET Servi�os de Comunica��o S 3356 2541 2066 Level 3 Communications, Inc. 4766 2877 1958 Korea Telecom 18566 2041 1858 MegaPath Corporation 4755 2003 1791 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 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:12 /10:34 /11:93 /12:264 /13:510 /14:1001 /15:1717 /16:12950 /17:7205 /18:12232 /19:25319 /20:35828 /21:38593 /22:58523 /23:51163 /24:290671 /25:1111 /26:1167 /27:660 /28:14 /29:11 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2230 3018 Cox Communications Inc. 18566 1996 2041 MegaPath Corporation 6389 1670 2880 BellSouth.net Inc. 6983 1399 1752 EarthLink, Inc. 30036 1355 1508 Mediacom Communications Corp 34984 1285 1980 TELLCOM ILETISIM HIZMETLERI A 6147 1144 1596 Telefonica del Peru S.A.A. 10620 1116 3156 Telmex Colombia S.A. 11492 1109 1172 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1544 2:666 4:93 5:1751 6:21 8:1415 12:1819 13:9 14:1315 15:17 16:2 17:44 18:21 20:49 23:1192 24:1695 27:1854 31:1513 32:39 33:2 34:5 35:3 36:117 37:1893 38:1012 39:11 40:246 41:2929 42:265 43:1238 44:26 45:342 46:2122 47:37 49:883 50:796 52:12 54:72 55:4 56:8 57:37 58:1222 59:681 60:468 61:1759 62:1336 63:1908 64:4448 65:2257 66:4120 67:2054 68:1077 69:3270 70:959 71:441 72:1959 74:2647 75:322 76:407 77:1489 78:1223 79:798 80:1317 81:1351 82:819 83:685 84:679 85:1369 86:381 87:1074 88:511 89:1807 90:153 91:5984 92:824 93:2174 94:1964 95:2068 96:428 97:348 98:1067 99:47 100:68 101:815 103:7079 104:1481 105:61 106:224 107:913 108:616 109:2019 110:1078 111:1485 112:770 113:1051 114:834 115:1249 116:1366 117:1024 118:1707 119:1436 120:450 121:1037 122:2183 123:1728 124:1505 125:1578 128:567 129:377 130:390 131:1183 132:481 133:172 134:415 135:109 136:300 137:313 138:576 139:164 140:239 141:421 142:669 143:487 144:569 145:108 146:712 147:580 148:1104 149:464 150:562 151:605 152:491 153:240 154:339 155:738 156:406 157:334 158:319 159:969 160:373 161:639 162:1959 163:422 164:663 165:686 166:289 167:803 168:1277 169:161 170:1466 171:240 172:41 173:1548 174:701 175:662 176:1406 177:3797 178:2062 179:879 180:1926 181:1599 182:1748 183:620 184:744 185:3193 186:2622 187:1783 188:2018 189:1584 190:7696 191:909 192:8204 193:5591 194:4107 195:3661 196:1705 197:1076 198:5512 199:5528 200:6575 201:3045 202:9447 203:9108 204:4694 205:2830 206:3083 207:3003 208:3943 209:3966 210:3525 211:1856 212:2451 213:2279 214:854 215:70 216:5581 217:1798 218:676 219:453 220:1436 221:790 222:464 223:670 End of report From baconzombie at gmail.com Fri Apr 3 18:22:10 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Fri, 3 Apr 2015 20:22:10 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <21790.50821.147502.621931@world.std.com> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> Message-ID: Is port scanning illegal in China? If not the there is no reason for then to do anything about it. On 3 Apr 2015 19:00, "Barry Shein" wrote: > > On April 2, 2015 at 14:19 goemon at anime.net (goemon at anime.net) wrote: > > a number of years back i did have someone contact in chinese and the > > response was that the customer was doing nothing wrong. > > Ok, that's progress of a sort, what's the authoritative source of > right and wrong, something beyond "c'mon it's obvious!"? > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From bzs at world.std.com Fri Apr 3 18:51:13 2015 From: bzs at world.std.com (Barry Shein) Date: Fri, 3 Apr 2015 14:51:13 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> Message-ID: <21790.57633.475328.833696@world.std.com> On April 3, 2015 at 20:22 baconzombie at gmail.com (Bacon Zombie) wrote: > Is port scanning illegal in China? > > If not the there is no reason for then to do anything about it. I don't think that's a minimal standard one has to use, illegal or not. Management of the internet infrastructure is primarily a cooperative, voluntary (in terms of cooperation and communication and agreement to BCPs and standards), and good-faith effort, not just bounded by what is or isn't illegal. As I said before these are companies most probably with many millions of dollars on the table, not miscreants out to cause problems. I suspect if one got them to the table the answers would be a bit more nuanced than "it's not illegal!" even if someone burdened with manning a support desk may have said something like that. All we really know at this point is that flinging emails at their admins hasn't been as effective as one might like. That's not entirely surprising. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From colinj at gt86car.org.uk Fri Apr 3 18:58:49 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 3 Apr 2015 19:58:49 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> Message-ID: <681C8DE1-5729-43B4-9D10-EA565FC64884@gt86car.org.uk> portscanning on mass scale where unable to get knowledgable network/sysadmins to fix gets to the point of every part of large network ranges are affected. then country blocks make sense to protect countries from armies of exploited machines and protect valuable costly network resource colin Sent from my iPhone > On 3 Apr 2015, at 19:22, Bacon Zombie wrote: > > Is port scanning illegal in China? > > If not the there is no reason for then to do anything about it. >> On 3 Apr 2015 19:00, "Barry Shein" wrote: >> >> >>> On April 2, 2015 at 14:19 goemon at anime.net (goemon at anime.net) wrote: >>> a number of years back i did have someone contact in chinese and the >>> response was that the customer was doing nothing wrong. >> >> Ok, that's progress of a sort, what's the authoritative source of >> right and wrong, something beyond "c'mon it's obvious!"? >> >> -- >> -Barry Shein >> >> The World | bzs at TheWorld.com | >> http://www.TheWorld.com >> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >> Canada >> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* >> From colinj at gt86car.org.uk Fri Apr 3 19:02:47 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 3 Apr 2015 20:02:47 +0100 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <21790.57633.475328.833696@world.std.com> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> <21790.57633.475328.833696@world.std.com> Message-ID: <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> china says not a problem since they have head in sand and ignore cooperation phone contact with chinse folks does not help either colin Sent from my iPhone > On 3 Apr 2015, at 19:51, Barry Shein wrote: > > >> On April 3, 2015 at 20:22 baconzombie at gmail.com (Bacon Zombie) wrote: >> Is port scanning illegal in China? >> >> If not the there is no reason for then to do anything about it. > > I don't think that's a minimal standard one has to use, illegal or > not. > > Management of the internet infrastructure is primarily a cooperative, > voluntary (in terms of cooperation and communication and agreement to > BCPs and standards), and good-faith effort, not just bounded by what > is or isn't illegal. > > As I said before these are companies most probably with many millions > of dollars on the table, not miscreants out to cause problems. > > I suspect if one got them to the table the answers would be a bit more > nuanced than "it's not illegal!" even if someone burdened with manning > a support desk may have said something like that. > > All we really know at this point is that flinging emails at their > admins hasn't been as effective as one might like. That's not entirely > surprising. > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From Rod.Beck at hibernianetworks.com Fri Apr 3 19:06:16 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Fri, 3 Apr 2015 19:06:16 +0000 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> <21790.57633.475328.833696@world.std.com>, <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> Message-ID: <1428087982327.83330@hibernianetworks.com> Gentlemen, be happy .... Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.beck at hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From cboyd at gizmopartners.com Fri Apr 3 19:18:07 2015 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 3 Apr 2015 14:18:07 -0500 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> <21790.57633.475328.833696@world.std.com> <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> Message-ID: Can we please get back to the original topic? So far we have had one interesting and useful suggestion that I've seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir Have I missed any other solutions other than the prefix length filtering? --Chris From goemon at anime.net Fri Apr 3 20:08:40 2015 From: goemon at anime.net (goemon at anime.net) Date: Fri, 3 Apr 2015 13:08:40 -0700 (PDT) Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <21790.50821.147502.621931@world.std.com> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> Message-ID: On Fri, 3 Apr 2015, Barry Shein wrote: > On April 2, 2015 at 14:19 goemon at anime.net (goemon at anime.net) wrote: > > a number of years back i did have someone contact in chinese and the > > response was that the customer was doing nothing wrong. > Ok, that's progress of a sort, what's the authoritative source of > right and wrong, something beyond "c'mon it's obvious!"? in their case the excuse was 1) they are a paying customer (thus can do no wrong) 2) they were breaking no chinese law (attacking US hosts) -Dan From Valdis.Kletnieks at vt.edu Fri Apr 3 20:41:11 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Apr 2015 16:41:11 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: Your message of "Fri, 03 Apr 2015 13:08:40 -0700." References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> Message-ID: <82134.1428093671@turing-police.cc.vt.edu> On Fri, 03 Apr 2015 13:08:40 -0700, goemon at anime.net said: > On Fri, 3 Apr 2015, Barry Shein wrote: > > On April 2, 2015 at 14:19 goemon at anime.net (goemon at anime.net) wrote: > > > a number of years back i did have someone contact in chinese and the > > > response was that the customer was doing nothing wrong. > > Ok, that's progress of a sort, what's the authoritative source of > > right and wrong, something beyond "c'mon it's obvious!"? > > in their case the excuse was > 1) they are a paying customer (thus can do no wrong) > 2) they were breaking no chinese law (attacking US hosts) And a moment's thought shows that attitude, while not very neighborly, is an economically sound one - he maximizes his profit by doing nothing about it. Actually taking action results in the costs of taking action *plus* the possibility of losing that customer's revenue. Unless you demonstrate that his total profit actually increases by dealing with the miscreants, he has no reason to do so. We've been down this road before - we've had our own problems on this side of the puddle with transit providers who refused to deal with problem customers because the provider billed by the packet, and the customers were good about paying their bill - so dealing with the problem caused less packets and thus less revenue. (The real problem here is, of course, that the *cost* of the abuse is an externality born by somebody other than the provider who's enabling the bad behavior... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From surfer at mauigateway.com Fri Apr 3 21:30:06 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 3 Apr 2015 14:30:06 -0700 Subject: BGP offloading (fixing legacy router BGP scalability issues) Message-ID: <20150403143006.382D90E9@m0048141.ppops.net> > ...if not then country bans are in place and will > remain in place until culture change is done : I would like country trade talks to get down to the : technical point that there are some fundamental : problems being seen with bad traffic usage and it is : significant percentage of waste bandwidth. Good luck with all that inter-governmental cooperation and whole-country culture change, so your blocks can be removed and they can reach your customers. ;-) scott From mpalmer at hezmatt.org Fri Apr 3 21:53:21 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 4 Apr 2015 08:53:21 +1100 Subject: Any google network admins out there? In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> Message-ID: <20150403215321.GL12292@hezmatt.org> Or, to answer your question more simply: "No". - Matt On Fri, Apr 03, 2015 at 11:39:36AM +0100, Pedro Cavaca wrote: > https://support.google.com/websearch/answer/86640?hl=en > > On 3 April 2015 at 04:53, Randy wrote: > > > I've started to get some message today from google claiming that my > > computer or network was sending automated queries, and they are blocking me. > > I'm not sending automated queries, Ive logged all of my outbound traffic > > and there is only my browser traffic going to google. > > > > I'm not responsible for any one else on "my network" since it is owned by > > my ISP, and solely blocking me based on what some one else with an ip > > address close to mine is not an acceptable practice to have for an address > > used for personal web browsing. > > I would like to know if there is any way to get into contact with google > > about this other then by legal means? > > > -- How many Apple Newton users does it take to change a lightbulb? Foux. There to eat lemons, axe gravy soup. -- Seen on the 'net From cidr-report at potaroo.net Fri Apr 3 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Apr 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201504032200.t33M00wE069249@wattle.apnic.net> This report has been generated at Fri Apr 3 21:14:33 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-03-15 545205 299195 28-03-15 546683 299138 29-03-15 545452 299227 30-03-15 545779 299008 31-03-15 545703 299451 01-04-15 546312 299210 02-04-15 546063 299362 03-04-15 546119 299436 AS Summary 50132 Number of ASes in routing system 20013 Number of ASes announcing only one prefix 3156 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120946176 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Apr15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 546347 299444 246903 45.2% All ASes AS22773 3020 171 2849 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2879 84 2795 97.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2794 78 2716 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 17 2456 99.3% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2358 285 2073 87.9% NET Servi�os de Comunica��o S.A.,BR AS4755 2001 265 1736 86.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2877 1322 1555 54.0% KIXS-AS-KR Korea Telecom,KR AS6983 1751 248 1503 85.8% ITCDELTA - Earthlink, Inc.,US AS9808 1555 67 1488 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6147 1596 159 1437 90.0% Telefonica del Peru S.A.A.,PE AS7303 1701 289 1412 83.0% Telecom Argentina S.A.,AR AS10620 3156 1800 1356 43.0% Telmex Colombia S.A.,CO AS20115 1851 501 1350 72.9% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2583 1324 1259 48.7% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1625 409 1216 74.8% TWTC - tw telecom holdings, inc.,US AS9498 1313 110 1203 91.6% BBIL-AP BHARTI Airtel Ltd.,IN AS8402 1201 24 1177 98.0% CORBINA-AS OJSC "Vimpelcom",RU AS18566 2040 869 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS34984 1982 889 1093 55.1% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1338 253 1085 81.1% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1134 61 1073 94.6% VIETEL-AS-AP Viettel Corporation,VN AS3356 2545 1483 1062 41.7% LEVEL3 - Level 3 Communications, Inc.,US AS6849 1209 171 1038 85.9% UKRTELNET JSC UKRTELECOM,UA AS8151 1564 638 926 59.2% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 983 115 868 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS8452 1856 999 857 46.2% TE-AS TE-AS,EG AS4780 1084 257 827 76.3% SEEDNET Digital United Inc.,TW AS4538 1778 956 822 46.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 963 158 805 83.6% Tim Celular S.A.,BR Total 56209 14085 42124 74.9% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 64.25.16.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.20.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.21.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.22.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.24.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.137.0.0/17 AS13886 CLOUD-SOUTH - Cloud South,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.221.76.0/23 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.41.124.0/24 AS63854 103.41.125.0/24 AS63854 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.225.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.76.0.0/14 AS5650 FRONTIER-FRTR - Frontier Communications of America, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.96.0/24 AS51088 A2B A2B IP B.V.,NL 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.232.0/23 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 193.93.234.0/23 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.239.84.0/22 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.187.36.0/22 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.184.90.0/23 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.83.88.0/22 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.90.0/23 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.91.0/24 AS12910 -Reserved AS-,ZZ 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.126.208.0/22 AS33339 NEMONT-CELLULAR - Nemont,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 3 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Apr 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201504032200.t33M022F069265@wattle.apnic.net> BGP Update Report Interval: 26-Mar-15 -to- 02-Apr-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4837 703462 11.0% 149.4 -- CHINA169-BACKBONE CNCGROUP China169 Backbone,CN 2 - AS7782 468010 7.3% 93602.0 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 3 - AS393276 467695 7.3% 77949.2 -- CEA - Chugach Electric Association, Inc.,US 4 - AS23752 237310 3.7% 2894.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 5 - AS9829 210308 3.3% 195.3 -- BSNL-NIB National Internet Backbone,IN 6 - AS7908 178184 2.8% 1113.7 -- BT LATAM Venezuela, S.A.,VE 7 - AS28024 147067 2.3% 96.3 -- Nuevatel PCS de Bolivia S.A.,BO 8 - AS4134 135317 2.1% 48.5 -- CHINANET-BACKBONE No.31,Jin-rong Street,CN 9 - AS61894 120038 1.9% 30009.5 -- FreeBSD Brasil LTDA,BR 10 - AS54970 93554 1.5% 93554.0 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 11 - AS36947 78996 1.2% 503.2 -- ALGTEL-AS,DZ 12 - AS21669 75881 1.2% 12646.8 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 13 - AS4808 75147 1.2% 85.1 -- CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 14 - AS9808 68327 1.1% 43.4 -- CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN 15 - AS53563 48472 0.8% 12118.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 16 - AS4812 41486 0.7% 100.5 -- CHINANET-SH-AP China Telecom (Group),CN 17 - AS14287 41057 0.6% 760.3 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 18 - AS33529 39436 0.6% 1792.5 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 19 - AS24444 38823 0.6% 59.6 -- CMNET-V4SHANDONG-AS-AP Shandong Mobile Communication Company Limited,CN 20 - AS25563 35471 0.6% 11823.7 -- WEBLAND-AS Webland AG, Autonomous System,CH TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7782 468010 7.3% 93602.0 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 2 - AS54970 93554 1.5% 93554.0 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 3 - AS393276 467695 7.3% 77949.2 -- CEA - Chugach Electric Association, Inc.,US 4 - AS61894 120038 1.9% 30009.5 -- FreeBSD Brasil LTDA,BR 5 - AS21669 75881 1.2% 12646.8 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 6 - AS197914 12596 0.2% 12596.0 -- STOCKHO-AS Stockho Hosting SARL,FR 7 - AS53563 48472 0.8% 12118.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS25563 35471 0.6% 11823.7 -- WEBLAND-AS Webland AG, Autonomous System,CH 9 - AS393588 9517 0.1% 9517.0 -- MUBEA-FLO - Mubea,US 10 - AS46336 8892 0.1% 8892.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 11 - AS60673 8130 0.1% 8130.0 -- ACTIVCOM Activcom Kft,HU 12 - AS61294 8107 0.1% 8107.0 -- STIHLHU-AS Andreas Stihl Kereskedelmi Kft,HU 13 - AS58396 22241 0.3% 7413.7 -- DETELNETWORKS-AS-ID PT. DEWATA TELEMATIKA,ID 14 - AS7713 7029 0.1% 7029.0 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 15 - AS33356 13640 0.2% 6820.0 -- CTWS - Eagle-Tech Systems,US 16 - AS27873 6059 0.1% 6059.0 -- Compa�ia Goly, S.A.,PA 17 - AS22059 33582 0.5% 4797.4 -- APVIO-1 - Apvio, Inc.,US 18 - AS39913 3555 0.1% 3555.0 -- COTEWA-AS Manuel Wannemacher,DE 19 - AS62174 2960 0.1% 2960.0 -- INTERPAN-AS INTERPAN LTD.,BG 20 - AS23752 237310 3.7% 2894.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 120031 1.7% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 119133 1.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 117543 1.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 192.206.58.0/24 93928 1.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 5 - 198.163.32.0/21 93898 1.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 6 - 192.189.216.0/24 93764 1.3% AS393276 -- CEA - Chugach Electric Association, Inc.,US 7 - 192.189.217.0/24 93718 1.3% AS393276 -- CEA - Chugach Electric Association, Inc.,US 8 - 162.211.56.0/21 93650 1.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 9 - 192.189.218.0/24 93570 1.3% AS393276 -- CEA - Chugach Electric Association, Inc.,US 10 - 198.17.216.0/24 93554 1.3% AS54970 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 11 - 192.189.215.0/24 93392 1.3% AS393276 -- CEA - Chugach Electric Association, Inc.,US 12 - 107.152.112.0/20 93364 1.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 13 - 192.189.219.0/24 93238 1.3% AS393276 -- CEA - Chugach Electric Association, Inc.,US 14 - 104.254.224.0/21 93170 1.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 15 - 105.96.0.0/22 77559 1.1% AS36947 -- ALGTEL-AS,DZ 16 - 209.212.8.0/24 75843 1.1% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 17 - 199.38.164.0/23 48461 0.7% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 18 - 208.73.244.0/22 40330 0.6% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 19 - 69.194.4.0/24 39406 0.6% AS33529 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 20 - 64.34.125.0/24 16321 0.2% AS22059 -- APVIO-1 - Apvio, Inc.,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jbfixurpc at gmail.com Fri Apr 3 22:14:22 2015 From: jbfixurpc at gmail.com (Joe) Date: Fri, 3 Apr 2015 17:14:22 -0500 Subject: Any google network admins out there? In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> Message-ID: Maybe - 1 (650) 253-0000? At least that what comes up when I google google for google's phone number....Of course the more apparent course of action would be to follow the directions and contact your ISP.I highly doubt they'd be trying to block some IP address that's close to yours and accidentally block the wrong one. I know the dude that does all the blocking and its not likely he fat fingered it. He doesn't make mistakes like that unless you made him really mad.... Happy Friday All! -Joe On Fri, Apr 3, 2015 at 5:39 AM, Pedro Cavaca wrote: > https://support.google.com/websearch/answer/86640?hl=en > > On 3 April 2015 at 04:53, Randy wrote: > >> I've started to get some message today from google claiming that my >> computer or network was sending automated queries, and they are blocking me. >> I'm not sending automated queries, Ive logged all of my outbound traffic >> and there is only my browser traffic going to google. >> >> I'm not responsible for any one else on "my network" since it is owned by >> my ISP, and solely blocking me based on what some one else with an ip >> address close to mine is not an acceptable practice to have for an address >> used for personal web browsing. >> I would like to know if there is any way to get into contact with google >> about this other then by legal means? >> From fred at web2objects.com Fri Apr 3 22:28:51 2015 From: fred at web2objects.com (Fred Hollis) Date: Sat, 04 Apr 2015 00:28:51 +0200 Subject: Any google network admins out there? In-Reply-To: <20150403215321.GL12292@hezmatt.org> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> <20150403215321.GL12292@hezmatt.org> Message-ID: <551F1423.5040707@web2objects.com> I need contact to a Google network Admin as well. Having some serious issues with our clients reaching Google services. On 03.04.2015 at 23:53 Matt Palmer wrote: > Or, to answer your question more simply: "No". > > - Matt > > On Fri, Apr 03, 2015 at 11:39:36AM +0100, Pedro Cavaca wrote: >> https://support.google.com/websearch/answer/86640?hl=en >> >> On 3 April 2015 at 04:53, Randy wrote: >> >>> I've started to get some message today from google claiming that my >>> computer or network was sending automated queries, and they are blocking me. >>> I'm not sending automated queries, Ive logged all of my outbound traffic >>> and there is only my browser traffic going to google. >>> >>> I'm not responsible for any one else on "my network" since it is owned by >>> my ISP, and solely blocking me based on what some one else with an ip >>> address close to mine is not an acceptable practice to have for an address >>> used for personal web browsing. >>> I would like to know if there is any way to get into contact with google >>> about this other then by legal means? >>> >> > From pmsac.nanog at gmail.com Fri Apr 3 22:54:27 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Fri, 3 Apr 2015 23:54:27 +0100 Subject: Any google network admins out there? In-Reply-To: <20150403215321.GL12292@hezmatt.org> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> <20150403215321.GL12292@hezmatt.org> Message-ID: On 3 April 2015 at 22:53, Matt Palmer wrote: > Or, to answer your question more simply: "No". > That completely mischaracterizes my answer. > > - Matt > > On Fri, Apr 03, 2015 at 11:39:36AM +0100, Pedro Cavaca wrote: > > https://support.google.com/websearch/answer/86640?hl=en > > > > On 3 April 2015 at 04:53, Randy wrote: > > > > > I've started to get some message today from google claiming that my > > > computer or network was sending automated queries, and they are > blocking me. > > > I'm not sending automated queries, Ive logged all of my outbound > traffic > > > and there is only my browser traffic going to google. > > > > > > I'm not responsible for any one else on "my network" since it is owned > by > > > my ISP, and solely blocking me based on what some one else with an ip > > > address close to mine is not an acceptable practice to have for an > address > > > used for personal web browsing. > > > I would like to know if there is any way to get into contact with > google > > > about this other then by legal means? > > > > > > > -- > How many Apple Newton users does it take to change a lightbulb? > Foux. There to eat lemons, axe gravy soup. > -- Seen on the 'net > > From morrowc.lists at gmail.com Sat Apr 4 01:16:59 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 Apr 2015 21:16:59 -0400 Subject: Any google network admins out there? In-Reply-To: <551F1423.5040707@web2objects.com> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> <20150403215321.GL12292@hezmatt.org> <551F1423.5040707@web2objects.com> Message-ID: On Fri, Apr 3, 2015 at 6:28 PM, Fred Hollis wrote: > I need contact to a Google network Admin as well. Having some serious issues > with our clients reaching Google services. it always helps to provide more data in your request ... From alvarezp at alvarezp.ods.org Sat Apr 4 01:25:14 2015 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 03 Apr 2015 18:25:14 -0700 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> <21790.57633.475328.833696@world.std.com> <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> Message-ID: <551F3D7A.20008@alvarezp.ods.org> On 04/03/2015 12:18 PM, Chris Boyd wrote: > Can we please get back to the original topic? Also interested in the original topic. > So far we have had one interesting and useful suggestion that I've > seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir > > Have I missed any other solutions other than the prefix length > filtering? Cisco BGP Selective Download was suggested on April 27th: http://seclists.org/nanog/2015/Apr/27 Best regards. From baldur.norddahl at gmail.com Sat Apr 4 01:55:34 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 4 Apr 2015 03:55:34 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> <21790.57633.475328.833696@world.std.com> <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> Message-ID: The SIR approach might not work if your switch does not support selective installing routes. Also the switch might have a very slow CPU and be memory constrained, making downloading a large number of routes impractical even if you do not install all. IX and transit providers are making this harder that it needs to be. Just allow two IP and MAC addresses on the peering network. Then you can just have a server running BIRD directly on the peering network using next hop attribute to redirect traffic through the switch. Actually I believe Cogent offers /29 on the peering link so you can do exactly that. Regards Baldur Den 03/04/2015 21.19 skrev "Chris Boyd" : > Can we please get back to the original topic? > > So far we have had one interesting and useful suggestion that I've seen -- > Paul S. mentioned SIR https://github.com/dbarrosop/sir > > Have I missed any other solutions other than the prefix length filtering? > > --Chris > > From cmaurand at xyonet.com Sat Apr 4 03:14:48 2015 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 03 Apr 2015 23:14:48 -0400 Subject: Infected hosts Message-ID: <551F5728.3040409@xyonet.com> The number of infected hosts out there is just astounding. I have bots attacking a server from all over the world. Lots of them from a network known as micfo. I could write abuse complaints from here until doomsday and I'd never be done. --Curtis -- Best Regards Curtis Maurand Principal Xyonet Web Hosting mailto:cmaurand at xyonet.com http://www.xyonet.com From COLIN at COLINBAKER.ORG Fri Apr 3 21:28:18 2015 From: COLIN at COLINBAKER.ORG (Colin Baker) Date: Fri, 3 Apr 2015 16:28:18 -0500 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> <21790.57633.475328.833696@world.std.com> <9862D7B2-AB24-433D-ADB5-E82D3DD084AF@gt86car.org.uk> Message-ID: On 2015-04-03 14:18, Chris Boyd wrote: > Can we please get back to the original topic? > > So far we have had one interesting and useful suggestion that I've > seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir > > Have I missed any other solutions other than the prefix length > filtering? > Indeed. OP - How much rack space do you have available, and do you pay for power? There are some decent alternatives to 3BXL, provided these aren't a concern - some better (and larger) than others. From listas at esds.com.br Sat Apr 4 05:52:37 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Sat, 4 Apr 2015 02:52:37 -0300 Subject: Any google network admins out there? In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> Message-ID: Inoc-dba? -- Eduardo Schoedler Em sexta-feira, 3 de abril de 2015, Joe escreveu: > Maybe - 1 (650) 253-0000? At least that what comes up when I google > google for google's phone number....Of course the more apparent course > of action would be to follow the directions and contact your ISP.I > highly doubt they'd be trying to block some IP address that's close to > yours and accidentally block the wrong one. I know the dude that does > all the blocking and its not likely he fat fingered it. He doesn't > make mistakes like that unless you made him really mad.... > > Happy Friday All! > -Joe > > > > On Fri, Apr 3, 2015 at 5:39 AM, Pedro Cavaca > wrote: > > https://support.google.com/websearch/answer/86640?hl=en > > > > On 3 April 2015 at 04:53, Randy > wrote: > > > >> I've started to get some message today from google claiming that my > >> computer or network was sending automated queries, and they are > blocking me. > >> I'm not sending automated queries, Ive logged all of my outbound traffic > >> and there is only my browser traffic going to google. > >> > >> I'm not responsible for any one else on "my network" since it is owned > by > >> my ISP, and solely blocking me based on what some one else with an ip > >> address close to mine is not an acceptable practice to have for an > address > >> used for personal web browsing. > >> I would like to know if there is any way to get into contact with google > >> about this other then by legal means? > >> > -- Eduardo Schoedler From admin at marcoteixeira.com Sat Apr 4 13:38:43 2015 From: admin at marcoteixeira.com (Marco Teixeira) Date: Sat, 4 Apr 2015 14:38:43 +0100 Subject: Infected hosts In-Reply-To: <551F5728.3040409@xyonet.com> References: <551F5728.3040409@xyonet.com> Message-ID: Dont' worry, it will calm down as the InternetOfThings takes off... :-S --- Cumprimentos / Best regards Marco Teixeira --- On Sat, Apr 4, 2015 at 4:14 AM, Curtis Maurand wrote: > The number of infected hosts out there is just astounding. I have bots > attacking a server from all over the world. Lots of them from a network > known as micfo. I could write abuse complaints from here until doomsday > and I'd never be done. > > --Curtis > > -- > Best Regards > Curtis Maurand > Principal > Xyonet Web Hosting > mailto:cmaurand at xyonet.com > http://www.xyonet.com > > From dhubbard at dino.hostasaurus.com Sat Apr 4 19:08:20 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sat, 4 Apr 2015 15:08:20 -0400 Subject: Google's Gmail SMTP SSL has expired (again) Message-ID: It appears something Google allowed to happen in 2008 has happened again: # openssl s_client -starttls smtp -connect smtp.gmail.com:587 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify error:num=10:certificate has expired notAfter=Apr 4 15:15:55 2015 GMT Just an FYI in case anyone has end users start reporting errors sending email. From colinj at mx5.org.uk Sat Apr 4 19:14:31 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Sat, 4 Apr 2015 20:14:31 +0100 Subject: Fwd: Google Apps Status Alert References: Message-ID: <79BC786F-75E8-42C4-9B2A-ED0783D4E761@mx5.org.uk> Sent from my iPhone Begin forwarded message: > From: Google Apps > Date: 4 April 2015 20:05:33 BST > To: colinj at mx5.org.uk > Subject: Google Apps Status Alert > > > > Status: Service disruption > We expect to resolve the problem affecting a majority of users of Gmail at April 4, 2015 1:00:00 PM PDT. Please note that this time frame is an estimate and may change. > smtp.gmail.com is displaying an invalid certificate. > April 4, 2015 11:58:00 AM PDT > > You are receiving this email as you have been subscribed to this alert. Unsubscribe | Learn more > > © 2013 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043 From johnl at iecc.com Sat Apr 4 19:43:52 2015 From: johnl at iecc.com (John Levine) Date: 4 Apr 2015 19:43:52 -0000 Subject: Google's Gmail SMTP SSL has expired (again) In-Reply-To: Message-ID: <20150404194352.13410.qmail@ary.lan> I get a cert good through Dec 31. Certificate: Data: Version: 3 (0x2) Serial Number: 4993746626803195625 (0x454d5a195ce8dee9) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2 Validity Not Before: Feb 18 10:19:56 2015 GMT Not After : Dec 31 00:00:00 2015 GMT Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=smtp.gmail.com From job at instituut.net Sat Apr 4 19:52:39 2015 From: job at instituut.net (Job Snijders) Date: Sat, 4 Apr 2015 21:52:39 +0200 Subject: Google's Gmail SMTP SSL has expired (again) In-Reply-To: <20150404194352.13410.qmail@ary.lan> References: <20150404194352.13410.qmail@ary.lan> Message-ID: <20150404195239.GT22984@Vurt.local> On Sat, Apr 04, 2015 at 07:43:52PM -0000, John Levine wrote: > I get a cert good through Dec 31. Yeah, seems to be fixed now. Vurt:~ job$ echo QUIT | openssl s_client -verify 6 -connect smtp.gmail.com:465 -showcerts | openssl x509 -noout -dates verify depth is 6 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:1 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify error:num=27:certificate not trusted verify return:1 depth=1 /C=US/O=Google Inc/CN=Google Internet Authority G2 verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com verify return:1 DONE notBefore=Feb 18 10:19:56 2015 GMT notAfter=Dec 31 00:00:00 2015 GMT From nanog at ics-il.net Sat Apr 4 21:06:02 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 4 Apr 2015 16:06:02 -0500 (CDT) Subject: Small IX IP Blocks In-Reply-To: <13831159.13894.1428179660929.JavaMail.mhammett@ThunderFuck> Message-ID: <982266.14031.1428181537100.JavaMail.mhammett@ThunderFuck> I am starting up a small IX. The thought process was a /24 for every IX location (there will be multiple of them geographically disparate), even though we never expected anywhere near that many on a given fabric. Then okay, how do we do v6? We got a /48, so the thought was a /64 for each. That one seems more cut and dry. A NANOG BCOP says to subnet no smaller than /64, so that makes sense to have one for each location. However, that brings me back to v4. Should I be cutting that /24 down into say /25s or /26s? We don't expect to have more than a /27 worth of networks at any one location, so a /26 should provide enough risk avoidance in not re-numbering an IX. That said... maybe best practice is to just leave it as /24. That's what I've seen at the other small IXes. Yes, I looked at NANOG's BCOPs and an article put out by Euro-IX. Didn't see much there. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From Valdis.Kletnieks at vt.edu Sat Apr 4 22:49:37 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 04 Apr 2015 18:49:37 -0400 Subject: Small IX IP Blocks In-Reply-To: Your message of "Sat, 04 Apr 2015 16:06:02 -0500." <982266.14031.1428181537100.JavaMail.mhammett@ThunderFuck> References: <982266.14031.1428181537100.JavaMail.mhammett@ThunderFuck> Message-ID: <72541.1428187777@turing-police.cc.vt.edu> On Sat, 04 Apr 2015 16:06:02 -0500, Mike Hammett said: > I am starting up a small IX. The thought process was a /24 for every IX > location (there will be multiple of them geographically disparate), even though > we nqever expected anywhere near that many on a given fabric. Then okay, how do < we d o v6? We got a /48, so the thought was a /64 for each. You probably want a /56 for each so you can hand a /64 to each customner. That way, customer isolation becomes easy because it's a routing problem. If customers share a subnet, it gets a little harder.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at ics-il.net Sat Apr 4 23:02:52 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 4 Apr 2015 18:02:52 -0500 (CDT) Subject: Small IX IP Blocks In-Reply-To: <72541.1428187777@turing-police.cc.vt.edu> Message-ID: <15804197.14541.1428188536934.JavaMail.mhammett@ThunderFuck> That makes sense. I do recall now reading about having that 8 bit separation between tiers of networks. However, in an IX everyone is supposed to be able to talk to everyone else. Traditionally (AFAIK), it's all been on the same subnet. At least the ones I've been involved with have been single subnets, but that's v4 too. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Valdis Kletnieks" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, April 4, 2015 5:49:37 PM Subject: Re: Small IX IP Blocks On Sat, 04 Apr 2015 16:06:02 -0500, Mike Hammett said: > I am starting up a small IX. The thought process was a /24 for every IX > location (there will be multiple of them geographically disparate), even though > we nqever expected anywhere near that many on a given fabric. Then okay, how do < we d o v6? We got a /48, so the thought was a /64 for each. You probably want a /56 for each so you can hand a /64 to each customner. That way, customer isolation becomes easy because it's a routing problem. If customers share a subnet, it gets a little harder.... From kauer at biplane.com.au Sat Apr 4 23:53:14 2015 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 05 Apr 2015 09:53:14 +1000 Subject: Small IX IP Blocks In-Reply-To: <15804197.14541.1428188536934.JavaMail.mhammett@ThunderFuck> References: <15804197.14541.1428188536934.JavaMail.mhammett@ThunderFuck> Message-ID: <1428191594.2734.20.camel@karl> On Sat, 2015-04-04 at 18:02 -0500, Mike Hammett wrote: > That makes sense. I do recall now reading about having that 8 bit > separation between tiers of networks. However, in an IX everyone is > supposed to be able to talk to everyone else. Traditionally (AFAIK), > it's all been on the same subnet. At least the ones I've been involved > with have been single subnets, but that's v4 too. Think flexible, think big, think future. Limiting yourself to tiny subnets and assuming your circumstances and requirements will not change is a recipe for difficult times ahead. Go as large as you can now, and route between participants. They might not always be friends with each other, or indeed with you, and the ability to isolate, redirect, offload, recombine and filter is critical to the flexibility of your (future) product offering. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From nanog at ics-il.net Sun Apr 5 00:35:55 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 4 Apr 2015 19:35:55 -0500 (CDT) Subject: Small IX IP Blocks In-Reply-To: Message-ID: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> Okay, so I decided to look at what current IXes are doing. It looks like AMS-IX, Equinix and Coresite as well as some of the smaller IXes are all using /64s for their IX fabrics. Seems to be a slam dunk then as how to handle the IPv6. We've got a /48, so a /64 per IX. For all of those advocating otherwise, do you have much experience with IXes? Multiple people talked about routing. There is no routing within an IX. I may grow, but an IX in a tier-2 American city will never scale larger than AMS-IX. If it's good enough for them, it's good enough for me. Back to v4, I went through a few pages of PeeringDB and most everyone used a /24 or larger. INEX appears to use a /25 for each of their segments. IX Australia uses mainly /24s, but two locations split a /24 into /25s. A couple of the smaller single location US IXes used /25s and /26s. It seems there's precedent for people using smaller than /24s, but it's not overly common. Cash and address space preservation. What does the community think about IXes on smaller than /24s? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Brendan Halley" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Saturday, April 4, 2015 6:10:34 PM Subject: Re: Small IX IP Blocks IPv4 and IPv6 subnets are different. While a single IPv4 is taken to be a single device, an IPv6 /64 is designed to be treated as an end user subnet. https://tools.ietf.org/html/rfc3177 section 3. On 05/04/2015 9:05 am, "Mike Hammett" < nanog at ics-il.net > wrote: That makes sense. I do recall now reading about having that 8 bit separation between tiers of networks. However, in an IX everyone is supposed to be able to talk to everyone else. Traditionally (AFAIK), it's all been on the same subnet. At least the ones I've been involved with have been single subnets, but that's v4 too. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Valdis Kletnieks" < Valdis.Kletnieks at vt.edu > To: "Mike Hammett" < nanog at ics-il.net > Cc: "NANOG" < nanog at nanog.org > Sent: Saturday, April 4, 2015 5:49:37 PM Subject: Re: Small IX IP Blocks On Sat, 04 Apr 2015 16:06:02 -0500, Mike Hammett said: > I am starting up a small IX. The thought process was a /24 for every IX > location (there will be multiple of them geographically disparate), even though > we nqever expected anywhere near that many on a given fabric. Then okay, how do < we d o v6? We got a /48, so the thought was a /64 for each. You probably want a /56 for each so you can hand a /64 to each customner. That way, customer isolation becomes easy because it's a routing problem. If customers share a subnet, it gets a little harder.... From laszlo at heliacal.net Sun Apr 5 01:27:02 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Sun, 5 Apr 2015 01:27:02 +0000 Subject: Small IX IP Blocks In-Reply-To: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> References: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> Message-ID: <553CCD00-DB1A-4BC8-A788-CCBC3B34E77B@heliacal.net> Mike, I think it's fine to cut it up smaller than /24, and might actually help in keeping people from routing the IX prefix globally. -Laszlo On Apr 5, 2015, at 12:35 AM, Mike Hammett wrote: > Okay, so I decided to look at what current IXes are doing. > > It looks like AMS-IX, Equinix and Coresite as well as some of the smaller IXes are all using /64s for their IX fabrics. Seems to be a slam dunk then as how to handle the IPv6. We've got a /48, so a /64 per IX. For all of those advocating otherwise, do you have much experience with IXes? Multiple people talked about routing. There is no routing within an IX. I may grow, but an IX in a tier-2 American city will never scale larger than AMS-IX. If it's good enough for them, it's good enough for me. > > Back to v4, I went through a few pages of PeeringDB and most everyone used a /24 or larger. INEX appears to use a /25 for each of their segments. IX Australia uses mainly /24s, but two locations split a /24 into /25s. A couple of the smaller single location US IXes used /25s and /26s. It seems there's precedent for people using smaller than /24s, but it's not overly common. Cash and address space preservation. What does the community think about IXes on smaller than /24s? > > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Brendan Halley" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Saturday, April 4, 2015 6:10:34 PM > Subject: Re: Small IX IP Blocks > > > IPv4 and IPv6 subnets are different. While a single IPv4 is taken to be a single device, an IPv6 /64 is designed to be treated as an end user subnet. > https://tools.ietf.org/html/rfc3177 section 3. > On 05/04/2015 9:05 am, "Mike Hammett" < nanog at ics-il.net > wrote: > > > That makes sense. I do recall now reading about having that 8 bit separation between tiers of networks. However, in an IX everyone is supposed to be able to talk to everyone else. Traditionally (AFAIK), it's all been on the same subnet. At least the ones I've been involved with have been single subnets, but that's v4 too. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Valdis Kletnieks" < Valdis.Kletnieks at vt.edu > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "NANOG" < nanog at nanog.org > > Sent: Saturday, April 4, 2015 5:49:37 PM > Subject: Re: Small IX IP Blocks > > On Sat, 04 Apr 2015 16:06:02 -0500, Mike Hammett said: > >> I am starting up a small IX. The thought process was a /24 for every IX >> location (there will be multiple of them geographically disparate), even though >> we nqever expected anywhere near that many on a given fabric. Then okay, how do > < we d o v6? We got a /48, so the thought was a /64 for each. > > You probably want a /56 for each so you can hand a /64 to each customner. > > That way, customer isolation becomes easy because it's a routing problem. > If customers share a subnet, it gets a little harder.... > > > > From cgucker at onesc.net Sun Apr 5 02:28:00 2015 From: cgucker at onesc.net (Charles Gucker) Date: Sat, 4 Apr 2015 22:28:00 -0400 Subject: Small IX IP Blocks In-Reply-To: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> References: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> Message-ID: I've been involved in IX renumbering efforts because exchange(s) decided to use /25's instead of /24's. It's painful because troubleshooting can be a little difficult as differing subnetmasks are in play. If you have the address space, use a /24. ARIN has IPv4 address space specifically reserved for the use by IXPs. charles On Sat, Apr 4, 2015 at 8:35 PM, Mike Hammett wrote: > Okay, so I decided to look at what current IXes are doing. > > It looks like AMS-IX, Equinix and Coresite as well as some of the smaller IXes are all using /64s for their IX fabrics. Seems to be a slam dunk then as how to handle the IPv6. We've got a /48, so a /64 per IX. For all of those advocating otherwise, do you have much experience with IXes? Multiple people talked about routing. There is no routing within an IX. I may grow, but an IX in a tier-2 American city will never scale larger than AMS-IX. If it's good enough for them, it's good enough for me. > > Back to v4, I went through a few pages of PeeringDB and most everyone used a /24 or larger. INEX appears to use a /25 for each of their segments. IX Australia uses mainly /24s, but two locations split a /24 into /25s. A couple of the smaller single location US IXes used /25s and /26s. It seems there's precedent for people using smaller than /24s, but it's not overly common. Cash and address space preservation. What does the community think about IXes on smaller than /24s? > > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Brendan Halley" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Saturday, April 4, 2015 6:10:34 PM > Subject: Re: Small IX IP Blocks > > > IPv4 and IPv6 subnets are different. While a single IPv4 is taken to be a single device, an IPv6 /64 is designed to be treated as an end user subnet. > https://tools.ietf.org/html/rfc3177 section 3. > On 05/04/2015 9:05 am, "Mike Hammett" < nanog at ics-il.net > wrote: > > > That makes sense. I do recall now reading about having that 8 bit separation between tiers of networks. However, in an IX everyone is supposed to be able to talk to everyone else. Traditionally (AFAIK), it's all been on the same subnet. At least the ones I've been involved with have been single subnets, but that's v4 too. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Valdis Kletnieks" < Valdis.Kletnieks at vt.edu > > To: "Mike Hammett" < nanog at ics-il.net > > Cc: "NANOG" < nanog at nanog.org > > Sent: Saturday, April 4, 2015 5:49:37 PM > Subject: Re: Small IX IP Blocks > > On Sat, 04 Apr 2015 16:06:02 -0500, Mike Hammett said: > >> I am starting up a small IX. The thought process was a /24 for every IX >> location (there will be multiple of them geographically disparate), even though >> we nqever expected anywhere near that many on a given fabric. Then okay, how do > < we d o v6? We got a /48, so the thought was a /64 for each. > > You probably want a /56 for each so you can hand a /64 to each customner. > > That way, customer isolation becomes easy because it's a routing problem. > If customers share a subnet, it gets a little harder.... > > > > From rs at seastrom.com Sun Apr 5 02:32:46 2015 From: rs at seastrom.com (Robert Seastrom) Date: Sat, 4 Apr 2015 22:32:46 -0400 Subject: Consumer products with baked-in VLAN tagging Message-ID: <133C37AE-4C25-4004-B2B2-DF3E068836E6@seastrom.com> Hi folks, As you may know if you've played around with recent Apple Airports (Express at least) in bridge mode with "guest network" turned on, they seem to know about 802.1q and have fairly reasonable or at least defensible behavior out of the box - that is to say they move the "native" SSID as untagged, and the "guest" SSID tagged 802.1q VLAN 1003. This behavior does not appear to be field-modifyable. So, who else has seen this sort of behavior from other consumer devices, running mixed tagged/untagged VLANs in a non-reconfigurable way? I'd be grateful for any and all pointers. Thanks, -r From woody at pch.net Sun Apr 5 02:36:17 2015 From: woody at pch.net (Bill Woodcock) Date: Sat, 4 Apr 2015 19:36:17 -0700 Subject: Small IX IP Blocks In-Reply-To: References: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> Message-ID: > On Apr 4, 2015, at 7:28 PM, Charles Gucker wrote: > > I've been involved in IX renumbering efforts because exchange(s) > decided to use /25's instead of /24's. It's painful because > troubleshooting can be a little difficult as differing subnetmasks are > in play. If you have the address space, use a /24. ARIN has IPv4 > address space specifically reserved for the use by IXPs. Yes. Listen to Charlie. We did a bunch of analysis on size of IXP subnets, and how it changes over time, relative to the age of the IXP. To summarize drastically, the first /24 typically lasts about 15-18 years. Only a tiny handful of exchanges (less than 2%) are actually supporting more than 254 participants yet at this point. That number will continue to grow over time. At the same time, it’s not worth the trouble of renumbering more than once in that time period, so don’t be penny-wise and pound-foolish by trying to use a /25, particularly when ARIN hands out /24s to IXPs specifically to keep them from running into that trap. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brendan at halley.net.au Sat Apr 4 23:10:34 2015 From: brendan at halley.net.au (Brendan Halley) Date: Sun, 5 Apr 2015 09:10:34 +1000 Subject: Small IX IP Blocks In-Reply-To: <15804197.14541.1428188536934.JavaMail.mhammett@ThunderFuck> References: <72541.1428187777@turing-police.cc.vt.edu> <15804197.14541.1428188536934.JavaMail.mhammett@ThunderFuck> Message-ID: IPv4 and IPv6 subnets are different. While a single IPv4 is taken to be a single device, an IPv6 /64 is designed to be treated as an end user subnet. https://tools.ietf.org/html/rfc3177 section 3. On 05/04/2015 9:05 am, "Mike Hammett" wrote: > That makes sense. I do recall now reading about having that 8 bit > separation between tiers of networks. However, in an IX everyone is > supposed to be able to talk to everyone else. Traditionally (AFAIK), it's > all been on the same subnet. At least the ones I've been involved with have > been single subnets, but that's v4 too. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Valdis Kletnieks" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Saturday, April 4, 2015 5:49:37 PM > Subject: Re: Small IX IP Blocks > > On Sat, 04 Apr 2015 16:06:02 -0500, Mike Hammett said: > > > I am starting up a small IX. The thought process was a /24 for every IX > > location (there will be multiple of them geographically disparate), even > though > > we nqever expected anywhere near that many on a given fabric. Then okay, > how do > < we d o v6? We got a /48, so the thought was a /64 for each. > > You probably want a /56 for each so you can hand a /64 to each customner. > > That way, customer isolation becomes easy because it's a routing problem. > If customers share a subnet, it gets a little harder.... > > From mark.tinka at seacom.mu Sun Apr 5 04:46:59 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 5 Apr 2015 06:46:59 +0200 Subject: Small IX IP Blocks In-Reply-To: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> References: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> Message-ID: <5520BE43.4080303@seacom.mu> On 5/Apr/15 02:35, Mike Hammett wrote: > Okay, so I decided to look at what current IXes are doing. > > It looks like AMS-IX, Equinix and Coresite as well as some of the smaller IXes are all using /64s for their IX fabrics. Seems to be a slam dunk then as how to handle the IPv6. We've got a /48, so a /64 per IX. For all of those advocating otherwise, do you have much experience with IXes? Multiple people talked about routing. There is no routing within an IX. I may grow, but an IX in a tier-2 American city will never scale larger than AMS-IX. If it's good enough for them, it's good enough for me. > > Back to v4, I went through a few pages of PeeringDB and most everyone used a /24 or larger. INEX appears to use a /25 for each of their segments. IX Australia uses mainly /24s, but two locations split a /24 into /25s. A couple of the smaller single location US IXes used /25s and /26s. It seems there's precedent for people using smaller than /24s, but it's not overly common. Cash and address space preservation. What does the community think about IXes on smaller than /24s? Your main issue with a smaller IPv4 subnet is when you grow, you'll end up having to renumber. This has hit some large exchange points in the recent past. Of course, it's easy to say that you won't grow beyond X members now, but there's no knowing how that will go if you're working hard at your project. Mark. From nanog at afxr.net Sun Apr 5 08:01:24 2015 From: nanog at afxr.net (Randy) Date: Sun, 05 Apr 2015 03:01:24 -0500 Subject: Any google network admins out there? In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> Message-ID: <5520EBD4.6040500@afxr.net> On 4/4/2015 3:11 AM, Lou Ashtonhurst wrote: > Randy, you can just use the contact details on their page about it: > > https://support.google.com/websearch/contact/ban > > Ask them for the netflow or other source of proof. My understanding > was they blocked on /32s not larger subnets which would indicate that > the traffic is coming from your network, and not someone with a > similar address, but you should be able to check once they give you > the info. > > Hope that helps a bit > Lou > I've gotten a new IP by my ISP and the issue has gone away, but it was extra cost and inconvenience as I have to resetup my "non google" related services back up. I'm a developer, and one whos adept at removing malware, of which I broke my computer twice trying to find any existence of. Google has not responded yet from that contact form from when I submitted that originally. I've also found several places/fourms where people are having the same issue I was, hopefully it doesn't come back. > > > On 3 April 2015 at 04:53, Randy > wrote: > > I've started to get some message today from google claiming that > my computer or network was sending automated queries, and they are > blocking me. > I'm not sending automated queries, Ive logged all of my outbound > traffic and there is only my browser traffic going to google. > > I'm not responsible for any one else on "my network" since it is > owned by my ISP, and solely blocking me based on what some one > else with an ip address close to mine is not an acceptable > practice to have for an address used for personal web browsing. > I would like to know if there is any way to get into contact with > google about this other then by legal means? > > From nick at foobar.org Sun Apr 5 10:59:51 2015 From: nick at foobar.org (Nick Hilliard) Date: Sun, 05 Apr 2015 11:59:51 +0100 Subject: Consumer products with baked-in VLAN tagging In-Reply-To: <133C37AE-4C25-4004-B2B2-DF3E068836E6@seastrom.com> References: <133C37AE-4C25-4004-B2B2-DF3E068836E6@seastrom.com> Message-ID: <552115A7.9060508@foobar.org> On 05/04/2015 03:32, Robert Seastrom wrote: > As you may know if you've played around with recent Apple Airports > (Express at least) in bridge mode with "guest network" turned on, they > seem to know about 802.1q and have fairly reasonable or at least > defensible behavior out of the box - that is to say they move the > "native" SSID as untagged, and the "guest" SSID tagged 802.1q VLAN > 1003. > > This behavior does not appear to be field-modifyable. Didn't know about that trick. I'm going to immediately enable vlan 1003 on the cisco switch that my express is connected to. Nick From paul at paulstewart.org Sun Apr 5 11:29:57 2015 From: paul at paulstewart.org (Paul Stewart) Date: Sun, 5 Apr 2015 07:29:57 -0400 Subject: Small IX IP Blocks In-Reply-To: References: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> Message-ID: <274801d06f93$dafe02e0$90fa08a0$@paulstewart.org> +1 I worked for a provider until recently that happened to get an IP assignment at an IXP that was transitioning from /25 to /24. It was painful chasing down peers to get them to change their netmask just so we could connect. This went on for several months dealing with the peering/network contacts of whom many of them didn't know the mask had changed in the first place. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bill Woodcock Sent: Saturday, April 4, 2015 10:36 PM To: Mike Hammett Cc: NANOG list Subject: Re: Small IX IP Blocks > On Apr 4, 2015, at 7:28 PM, Charles Gucker wrote: > > I've been involved in IX renumbering efforts because exchange(s) > decided to use /25's instead of /24's. It's painful because > troubleshooting can be a little difficult as differing subnetmasks are > in play. If you have the address space, use a /24. ARIN has IPv4 > address space specifically reserved for the use by IXPs. Yes. Listen to Charlie. We did a bunch of analysis on size of IXP subnets, and how it changes over time, relative to the age of the IXP. To summarize drastically, the first /24 typically lasts about 15-18 years. Only a tiny handful of exchanges (less than 2%) are actually supporting more than 254 participants yet at this point. That number will continue to grow over time. At the same time, it's not worth the trouble of renumbering more than once in that time period, so don't be penny-wise and pound-foolish by trying to use a /25, particularly when ARIN hands out /24s to IXPs specifically to keep them from running into that trap. -Bill From gourmetcisco at hotmail.com Sun Apr 5 13:16:19 2015 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Sun, 5 Apr 2015 09:16:19 -0400 Subject: lotsa pcap reporting Message-ID: hi nanog folks, i have 7GB of darn pcap data separated into individual 50MB files. Collected via Wireshark. i need a tool that can slurp in all this data and regurgitate pretty, colourful and management-friendly reports. Windows or Linux. any suggestions? thanks, Hank From hhoffman at ip-solutions.net Sun Apr 5 13:30:03 2015 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sun, 05 Apr 2015 09:30:03 -0400 Subject: lotsa pcap reporting In-Reply-To: Message-ID: <550e4389-30de-48d5-82f3-7972154dab23@email.android.com> Hmm, maybe start with defining what you want to report about? Top talkers, top protocols/ports, open services, DNS info, reconstructed files, etc... Lots of different tools but it depends on what you want to do. Cheers, Harry On Apr 5, 2015 9:16 AM, Hank Disuko wrote: > > hi nanog folks, > i have 7GB of darn pcap data separated into individual 50MB files.  Collected via Wireshark. > i need a tool that can slurp in all this data and regurgitate pretty, colourful and management-friendly reports.  Windows or Linux. > any suggestions? > thanks, > Hank      From gourmetcisco at hotmail.com Sun Apr 5 13:36:51 2015 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Sun, 5 Apr 2015 09:36:51 -0400 Subject: lotsa pcap reporting In-Reply-To: <550e4389-30de-48d5-82f3-7972154dab23@email.android.com> References: , <550e4389-30de-48d5-82f3-7972154dab23@email.android.com> Message-ID: Thanks for the response, Harry. the basic stuff that managers are interested in seeing: - yes what you said- who or what is taking up all my precious network bandwidth- colourful 3D pie charts Kind regards, Hank > Date: Sun, 5 Apr 2015 09:30:03 -0400 > Subject: Re: lotsa pcap reporting > From: hhoffman at ip-solutions.net > To: gourmetcisco at hotmail.com > CC: nanog at nanog.org > > Hmm, maybe start with defining what you want to report about? > > Top talkers, top protocols/ports, open services, DNS info, reconstructed files, etc... > > Lots of different tools but it depends on what you want to do. > > Cheers, > Harry > > > > On Apr 5, 2015 9:16 AM, Hank Disuko wrote: > > > > hi nanog folks, > > i have 7GB of darn pcap data separated into individual 50MB files. Collected via Wireshark. > > i need a tool that can slurp in all this data and regurgitate pretty, colourful and management-friendly reports. Windows or Linux. > > any suggestions? > > thanks, > > Hank From hhoffman at ip-solutions.net Sun Apr 5 14:05:29 2015 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sun, 05 Apr 2015 10:05:29 -0400 Subject: lotsa pcap reporting In-Reply-To: References: , <550e4389-30de-48d5-82f3-7972154dab23@email.android.com> Message-ID: <55214129.5000501@ip-solutions.net> So, NTop or Afterglow might be a good start. They are both user-friendly tools that can ingest pcap files and output all sorts of pretty things. Cheers, Harry On 04/05/2015 09:36 AM, Hank Disuko wrote: > Thanks for the response, Harry. > > the basic stuff that managers are interested in seeing: > > - yes what you said > - who or what is taking up all my precious network bandwidth > - colourful 3D pie charts > > Kind regards, > > Hank > >> Date: Sun, 5 Apr 2015 09:30:03 -0400 >> Subject: Re: lotsa pcap reporting >> From: hhoffman at ip-solutions.net >> To: gourmetcisco at hotmail.com >> CC: nanog at nanog.org >> >> Hmm, maybe start with defining what you want to report about? >> >> Top talkers, top protocols/ports, open services, DNS info, > reconstructed files, etc... >> >> Lots of different tools but it depends on what you want to do. >> >> Cheers, >> Harry >> >> >> >> On Apr 5, 2015 9:16 AM, Hank Disuko wrote: >> > >> > hi nanog folks, >> > i have 7GB of darn pcap data separated into individual 50MB files. > Collected via Wireshark. >> > i need a tool that can slurp in all this data and regurgitate > pretty, colourful and management-friendly reports. Windows or Linux. >> > any suggestions? >> > thanks, >> > Hank From chk at pobox.com Sun Apr 5 14:33:51 2015 From: chk at pobox.com (Harald Koch) Date: Sun, 5 Apr 2015 10:33:51 -0400 Subject: Any google network admins out there? In-Reply-To: <5520EBD4.6040500@afxr.net> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <551E0ED1.5000806@afxr.net> <5520EBD4.6040500@afxr.net> Message-ID: > > On 4/4/2015 3:11 AM, Lou Ashtonhurst wrote: > >> Randy, you can just use the contact details on their page about it: >> >> https://support.google.com/websearch/contact/ban >> >> Ask them for the netflow or other source of proof. My understanding was >> they blocked on /32s not larger subnets which would indicate that the >> traffic is coming from your network, and not someone with a similar >> address, but you should be able to check once they give you the info. >> > This reply suggests you've never actually used that contact page. Have you received a response from them? I get this message about once a month using one or both of my Linode-based web proxies. Google remains silent; as they say in the contact page: the process is completely automated and there's nothing mere humans can do about it. Bow to our robot overlords. From john.mason.jr at gmail.com Sun Apr 5 14:44:56 2015 From: john.mason.jr at gmail.com (John Mason Jr) Date: Sun, 5 Apr 2015 10:44:56 -0400 Subject: lotsa pcap reporting In-Reply-To: <55214129.5000501@ip-solutions.net> References: <550e4389-30de-48d5-82f3-7972154dab23@email.android.com> <55214129.5000501@ip-solutions.net> Message-ID: <5C6B508C-61C7-4BC4-BB4E-DD86DD8B5EEF@gmail.com> http://www.riverbed.com/products/performance-management-control/network-performance-management/packet-analysis.html#Overview > On Apr 5, 2015, at 10:05 AM, Harry Hoffman wrote: > > So, NTop or Afterglow might be a good start. They are both user-friendly > tools that can ingest pcap files and output all sorts of pretty things. > > Cheers, > Harry > > > >> On 04/05/2015 09:36 AM, Hank Disuko wrote: >> Thanks for the response, Harry. >> >> the basic stuff that managers are interested in seeing: >> >> - yes what you said >> - who or what is taking up all my precious network bandwidth >> - colourful 3D pie charts >> >> Kind regards, >> >> Hank >> >>> Date: Sun, 5 Apr 2015 09:30:03 -0400 >>> Subject: Re: lotsa pcap reporting >>> From: hhoffman at ip-solutions.net >>> To: gourmetcisco at hotmail.com >>> CC: nanog at nanog.org >>> >>> Hmm, maybe start with defining what you want to report about? >>> >>> Top talkers, top protocols/ports, open services, DNS info, >> reconstructed files, etc... >>> >>> Lots of different tools but it depends on what you want to do. >>> >>> Cheers, >>> Harry >>> >>> >>> >>>> On Apr 5, 2015 9:16 AM, Hank Disuko wrote: >>>> >>>> hi nanog folks, >>>> i have 7GB of darn pcap data separated into individual 50MB files. >> Collected via Wireshark. >>>> i need a tool that can slurp in all this data and regurgitate >> pretty, colourful and management-friendly reports. Windows or Linux. >>>> any suggestions? >>>> thanks, >>>> Hank From will at harg.net Sun Apr 5 15:39:37 2015 From: will at harg.net (Will Hargrave) Date: Sun, 5 Apr 2015 08:39:37 -0700 Subject: Small IX IP Blocks In-Reply-To: <274801d06f93$dafe02e0$90fa08a0$@paulstewart.org> References: <31685005.14783.1428194111120.JavaMail.mhammett@ThunderFuck> <274801d06f93$dafe02e0$90fa08a0$@paulstewart.org> Message-ID: <833BF2F6-EBED-418E-8B66-A5D27D9CA951@harg.net> On 5 Apr 2015, at 04:29, Paul Stewart wrote: > I worked for a provider until recently that happened to get an IP assignment > at an IXP that was transitioning from /25 to /24. It was painful chasing > down peers to get them to change their netmask just so we could connect. > This went on for several months dealing with the peering/network contacts of > whom many of them didn't know the mask had changed in the first place. If you had problems peering because other participants have the wrong netmask, the IXP is not being operated correctly. It’s such a very bad thing to have the incorrect netmask on interfaces (think, more-specifics, route leaks, etc) that the IXP should manage the netmask change process itself - in fact to the point of disconnecting networks who do not configure it correctly. When we renumbered LONAP from /24 to /22, we had to change netblocks too. I can’t recall if we had any netmask problems too but it seems perfectly possible if lazy people just went %s/193.203.5/5.57.80/g. So we did check for that - it’s quite a simple task. From an IXP user point of view, the change was easier for J users, but we built a config validator/renumbererer for C IOS users to help them out. (‘paste your config in this webform’ ‘examine the output’ sort of thing) Will From gourmetcisco at hotmail.com Sun Apr 5 16:13:43 2015 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Sun, 5 Apr 2015 12:13:43 -0400 Subject: lotsa pcap reporting In-Reply-To: <5C6B508C-61C7-4BC4-BB4E-DD86DD8B5EEF@gmail.com> References: , <550e4389-30de-48d5-82f3-7972154dab23@email.android.com>, , <55214129.5000501@ip-solutions.net>, <5C6B508C-61C7-4BC4-BB4E-DD86DD8B5EEF@gmail.com> Message-ID: This is fantastic. Thank-you everyone for your input. I have a busy day of software evaluation ahead of me. Thanks again! Hank > Subject: Re: lotsa pcap reporting > From: john.mason.jr at gmail.com > Date: Sun, 5 Apr 2015 10:44:56 -0400 > To: nanog at nanog.org > > > http://www.riverbed.com/products/performance-management-control/network-performance-management/packet-analysis.html#Overview > > > > On Apr 5, 2015, at 10:05 AM, Harry Hoffman wrote: > > > > So, NTop or Afterglow might be a good start. They are both user-friendly > > tools that can ingest pcap files and output all sorts of pretty things. > > > > Cheers, > > Harry > > > > > > > >> On 04/05/2015 09:36 AM, Hank Disuko wrote: > >> Thanks for the response, Harry. > >> > >> the basic stuff that managers are interested in seeing: > >> > >> - yes what you said > >> - who or what is taking up all my precious network bandwidth > >> - colourful 3D pie charts > >> > >> Kind regards, > >> > >> Hank > >> > >>> Date: Sun, 5 Apr 2015 09:30:03 -0400 > >>> Subject: Re: lotsa pcap reporting > >>> From: hhoffman at ip-solutions.net > >>> To: gourmetcisco at hotmail.com > >>> CC: nanog at nanog.org > >>> > >>> Hmm, maybe start with defining what you want to report about? > >>> > >>> Top talkers, top protocols/ports, open services, DNS info, > >> reconstructed files, etc... > >>> > >>> Lots of different tools but it depends on what you want to do. > >>> > >>> Cheers, > >>> Harry > >>> > >>> > >>> > >>>> On Apr 5, 2015 9:16 AM, Hank Disuko wrote: > >>>> > >>>> hi nanog folks, > >>>> i have 7GB of darn pcap data separated into individual 50MB files. > >> Collected via Wireshark. > >>>> i need a tool that can slurp in all this data and regurgitate > >> pretty, colourful and management-friendly reports. Windows or Linux. > >>>> any suggestions? > >>>> thanks, > >>>> Hank From brandon at rd.bbc.co.uk Sun Apr 5 17:15:43 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 5 Apr 2015 18:15:43 +0100 (BST) Subject: Small IX IP Blocks Message-ID: <201504051715.SAA26066@sunf10.rd.bbc.co.uk> > When we renumbered LONAP from /24 to /22, we had to change netblocks too The LONAP change was the snoothest, speediest, no drama IXP addressing change I've seen. All IXP should copy their process. brandon From rjs at rob.sh Sun Apr 5 17:33:46 2015 From: rjs at rob.sh (Rob Shakir) Date: Sun, 5 Apr 2015 18:33:46 +0100 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: <55196012.9050508@noor.net> References: <55196012.9050508@noor.net> Message-ID: On 30 March 2015 at 15:42:59, Mohamed Kamal (mkamal at noor.net) wrote: > I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?! > > Should I be getting a 9k/CRS on the edge to implement an automatic tool > to build MPLS-TE tunnels! In general, PCE(P) implementations have been limited. IMHO the last 10 years of RSVP-TE management has generally been done with auto-mesh tools, or in-house driven offline path calculation tools (e.g., WANDL, Cariden, Aria…).  As such, the demand for online calculation has increased - either due to dependencies for new TE path-instantiating protocols (e.g., SR), or more complex constraints that cannot be well met by offline calculation or CSPF (e.g., path-diversity with disjoint head-end PEs). This demand is mainly coming in higher-scale environments - and hence being implemented on IOS-XR within the Cisco environment today. I expect this is why IOS-XE is lagging. There are certainly requests for support - but as Mark says, you’ll need to interface with your account team to figure out when code will be available for your platform. As to whether you should buy an IOS XR device for your edge, I’m not sure what kind of logic would mean that device selection is solely based on PCEP support :-). I would certainly look more into the existing “automatic” tools, and possibilities for offline calculation in the interim period. r. From mkamal at noor.net Sun Apr 5 19:42:46 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Sun, 05 Apr 2015 22:42:46 +0300 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: References: <55196012.9050508@noor.net> Message-ID: <55219036.2080403@noor.net> > and hence being implemented on IOS-XR within the Cisco environment today I disagree! .. Engineering is all about optimization, and using an ASR1k (which is being marketed as an "edge/PE router") in my edge doesn't mean that my network is not a "high-scale environment", it does mean that it fits my needs in this location, where other IOS-XR (ASR9k) fits in others. Plus, PCEP is no magic, Juniper's MX series starting from the vMX is supporting PCEP. They didn't claim that, a "higher-scale environment" is being required for this. > the demand for online calculation has increased - either due to dependencies for new TE path-instantiating protocols (e.g., SR), or more complex constraints that cannot be well met by offline calculation or CSPF That's why PCEP support should be added to the road-map in the near future. Mohamed Kamal Core Network Sr. Engineer On 4/5/2015 8:33 PM, Rob Shakir wrote: > On 30 March 2015 at 15:42:59, Mohamed Kamal (mkamal at noor.net) wrote: >> I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?! >> >> Should I be getting a 9k/CRS on the edge to implement an automatic tool >> to build MPLS-TE tunnels! > In general, PCE(P) implementations have been limited. IMHO the last 10 years of RSVP-TE management has generally been done with auto-mesh tools, or in-house driven offline path calculation tools (e.g., WANDL, Cariden, Aria…). > > As such, the demand for online calculation has increased - either due to dependencies for new TE path-instantiating protocols (e.g., SR), or more complex constraints that cannot be well met by offline calculation or CSPF (e.g., path-diversity with disjoint head-end PEs). This demand is mainly coming in higher-scale environments - and hence being implemented on IOS-XR within the Cisco environment today. I expect this is why IOS-XE is lagging. There are certainly requests for support - but as Mark says, you’ll need to interface with your account team to figure out when code will be available for your platform. > > As to whether you should buy an IOS XR device for your edge, I’m not sure what kind of logic would mean that device selection is solely based on PCEP support :-). I would certainly look more into the existing “automatic” tools, and possibilities for offline calculation in the interim period. > > r. > From rjs at rob.sh Sun Apr 5 20:29:33 2015 From: rjs at rob.sh (Rob Shakir) Date: Sun, 5 Apr 2015 21:29:33 +0100 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: <55219036.2080403@noor.net> References: <55196012.9050508@noor.net> <55219036.2080403@noor.net> Message-ID: On 5 April 2015 at 20:43:24, Mohamed Kamal (mkamal at noor.net) wrote: > and hence being implemented on IOS-XR within the Cisco environment today  I disagree! .. Engineering is all about optimization, and using an ASR1k  (which is being marketed as an "edge/PE router") in my edge doesn't mean  that my network is not a "high-scale environment", it does mean that it  fits my needs in this location, where other IOS-XR (ASR9k) fits in others.  Plus, PCEP is no magic, Juniper's MX series starting from the vMX is  supporting PCEP. They didn't claim that, a "higher-scale environment" is  being required for this.  I did not say that a high-scale environment is required. Just that as far as I have seen a number of deployments (e.g., Internet core/peering-edge) that are stating requirements for TE+PCEP are of the traffic scale that XR boxes are likely to be more widely deployed. IMHO, it’s this that means that XR is seeing the *first* implementations. Some very large networks (including some that I have responsibility for) make extensive use of IOS XE, and hence there are also requests for PCEP implementations there. I encourage you to request it of Cisco too! r. From mehmet at akcin.net Mon Apr 6 06:57:54 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 5 Apr 2015 23:57:54 -0700 Subject: Usage data from Turkey In-Reply-To: <551BC9A7.2090802@netassist.ua> References: <551BC9A7.2090802@netassist.ua> Message-ID: Turkey unfortunately doesn't have a major internet exchange point as we know it. It has T-NAP which is few isps coming together and establishing L3 link between each other and sending some prefixes to keep traffic local. It's however more like a coordinated PNI not an exchange point. there are several others like IST-IX, etc which I don't think actually changes any significant (1G-10G...etc) traffic mehmet On Wed, Apr 1, 2015 at 3:34 AM, Max Tulyev wrote: > Hello, > > may be a bit off-topic, but which major Internet Exchange points are in > Tukrey? I can't google it. > > On 03/31/15 20:19, Mehmet Akcin wrote: > > Hello > > > > Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major > power outage impacting nearly 70M people. I am writing a blog post about > power outage vs impact to network usage. I am looking for as much as useful > network usage information possible related to Turkey. > > > > If you can share network usage information, i will be making sure to buy > you some drinks at next nanog ;) > > > > Cheers > > > > Mehmet > > > > From goemon at anime.net Mon Apr 6 18:04:47 2015 From: goemon at anime.net (goemon at anime.net) Date: Mon, 6 Apr 2015 11:04:47 -0700 (PDT) Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <82134.1428093671@turing-police.cc.vt.edu> References: <551CE8BE.1010304@seacom.mu> <551CF281.30700@winterei.se> <551CF52E.4010405@stefan-neufeind.de> <551CF666.7090100@seacom.mu> <551D1B31.1020009@stefan-neufeind.de> <551D1EA7.8060605@seacom.mu> <21789.40332.276582.854995@world.std.com> <21790.50821.147502.621931@world.std.com> <82134.1428093671@turing-police.cc.vt.edu> Message-ID: On Fri, 3 Apr 2015, Valdis.Kletnieks at vt.edu wrote: > We've been down this road before - we've had our own problems on this > side of the puddle with transit providers who refused to deal with problem > customers because the provider billed by the packet, and the customers were > good about paying their bill - so dealing with the problem caused less packets > and thus less revenue. At least in the US the provider could be charged with willful negligence and face liability. But in most cases RBL is enough pressure to get the US providers to do the right thing. -Dan From xionox at gmail.com Mon Apr 6 18:47:40 2015 From: xionox at gmail.com (Arzhel Younsi) Date: Tue, 07 Apr 2015 06:47:40 +1200 Subject: PoC for shortlisted DDoS Vendors In-Reply-To: <20150402065225.BDD922C04AB@mail.nanog.org> References: <20150402065225.BDD922C04AB@mail.nanog.org> Message-ID: <1428346060.335551.249898177.74182BBA@webmail.messagingengine.com> Not an appliance but WanGaurd might be a good match as well. We're currently evaluating it. http://www.andrisoft.com/software/wanguard -- Arzhel On Fri, Apr 3, 2015, at 01:31, dennis at justipit.com wrote: > You should include Radware on that list . > > ----- Reply message ----- > From: "Mohamed Kamal" > To: "NANOG" > Subject: PoC for shortlisted DDoS Vendors > Date: Wed, Apr 1, 2015 9:51 AM > > In our effort to pick up a reasonably priced DDoS appliance with a > competitive features, we're in a process of doing a PoC for the > following shortlisted vendors: > > 1- RioRey > 2- NSFocus > 3- Arbor > 4- A10 > > The setup will be inline. So it would be great if anyone have done this > before and can help provide the appropriate tools, advices, or the > testing documents for efficient PoC. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer From johnl at iecc.com Mon Apr 6 18:51:34 2015 From: johnl at iecc.com (John Levine) Date: 6 Apr 2015 18:51:34 -0000 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: Message-ID: <20150406185134.23814.qmail@ary.lan> In article you write: >On Fri, 3 Apr 2015, Valdis.Kletnieks at vt.edu wrote: >> We've been down this road before - we've had our own problems on this >> side of the puddle with transit providers who refused to deal with problem >> customers because the provider billed by the packet, and the customers were >> good about paying their bill - so dealing with the problem caused less packets >> and thus less revenue. > >At least in the US the provider could be charged with willful negligence >and face liability. Please provide legal citations. R's, John From kate at quadranet.com Mon Apr 6 18:54:57 2015 From: kate at quadranet.com (Kate Gerry) Date: Mon, 6 Apr 2015 11:54:57 -0700 Subject: PoC for shortlisted DDoS Vendors In-Reply-To: <1428346060.335551.249898177.74182BBA@webmail.messagingengine.com> References: <20150402065225.BDD922C04AB@mail.nanog.org> <1428346060.335551.249898177.74182BBA@webmail.messagingengine.com> Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F601A7FDA1C60F@EXCH> WANGuard is great for detection but WANFilter failed my tests. I couldn't filter a 700mbit SYN flood. The best it did was to completely block TCP/80. It uses netfilter to block Layer3 attacks. It does have ACL support for some Intel NICs, but it doesn't use it near enough. -- Kate      -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Arzhel Younsi Sent: Monday, April 06, 2015 11:48 AM To: nanog at nanog.org Subject: Re: PoC for shortlisted DDoS Vendors Not an appliance but WanGaurd might be a good match as well. We're currently evaluating it. http://www.andrisoft.com/software/wanguard -- Arzhel On Fri, Apr 3, 2015, at 01:31, dennis at justipit.com wrote: > You should include Radware on that list . > > ----- Reply message ----- > From: "Mohamed Kamal" > To: "NANOG" > Subject: PoC for shortlisted DDoS Vendors > Date: Wed, Apr 1, 2015 9:51 AM > > In our effort to pick up a reasonably priced DDoS appliance with a > competitive features, we're in a process of doing a PoC for the > following shortlisted vendors: > > 1- RioRey > 2- NSFocus > 3- Arbor > 4- A10 > > The setup will be inline. So it would be great if anyone have done > this before and can help provide the appropriate tools, advices, or > the testing documents for efficient PoC. > > Thanks. > > -- > Mohamed Kamal > Core Network Sr. Engineer From goemon at anime.net Mon Apr 6 21:26:14 2015 From: goemon at anime.net (goemon at anime.net) Date: Mon, 6 Apr 2015 14:26:14 -0700 (PDT) Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <20150406185134.23814.qmail@ary.lan> References: <20150406185134.23814.qmail@ary.lan> Message-ID: On Mon, 6 Apr 2015, John Levine wrote: > In article you write: >> On Fri, 3 Apr 2015, Valdis.Kletnieks at vt.edu wrote: >>> We've been down this road before - we've had our own problems on this >>> side of the puddle with transit providers who refused to deal with problem >>> customers because the provider billed by the packet, and the customers were >>> good about paying their bill - so dealing with the problem caused less packets >>> and thus less revenue. >> At least in the US the provider could be charged with willful negligence >> and face liability. > Please provide legal citations. ignore a dmca takedown request, see what happens. -Dan From bill at herrin.us Mon Apr 6 21:41:35 2015 From: bill at herrin.us (William Herrin) Date: Mon, 6 Apr 2015 17:41:35 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <20150406185134.23814.qmail@ary.lan> References: <20150406185134.23814.qmail@ary.lan> Message-ID: On Mon, Apr 6, 2015 at 2:51 PM, John Levine wrote: > In article you write: >>At least in the US the provider could be charged with willful negligence >>and face liability. > > Please provide legal citations. http://www.americanbar.org/newsletter/publications/gp_solo_magazine_home/gp_solo_magazine_index/civilliability.html https://www.ftc.gov/news-events/press-releases/2009/06/ftc-shuts-down-notorious-rogue-internet-service-provider-3fn It happens. Not often enough. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From johnl at iecc.com Mon Apr 6 22:30:57 2015 From: johnl at iecc.com (John R. Levine) Date: 6 Apr 2015 18:30:57 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <20150406185134.23814.qmail@ary.lan> Message-ID: > http://www.americanbar.org/newsletter/publications/gp_solo_magazine_home/gp_solo_magazine_index/civilliability.html Nothing there about ISP liability other than noting the third-party immunity from the CDA. > https://www.ftc.gov/news-events/press-releases/2009/06/ftc-shuts-down-notorious-rogue-internet-service-provider-3fn Well, yeah, they were actively running a crimeware service. "Don't do that." From johnl at iecc.com Tue Apr 7 00:41:24 2015 From: johnl at iecc.com (John R. Levine) Date: 6 Apr 2015 20:41:24 -0400 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: <20150406185134.23814.qmail@ary.lan> Message-ID: >> Please provide legal citations. > > ignore a dmca takedown request, see what happens. I know people who have ignored lots of DMCA notices. Of course, it was pretty clear that the notices were bogus. R's, John From j at arpa.com Tue Apr 7 06:09:46 2015 From: j at arpa.com (jamie rishaw) Date: Tue, 7 Apr 2015 01:09:46 -0500 Subject: Charter plant/backbone engineers? Message-ID: I have a couple of questions re v6 and QoS'ing. If I can get an off list "what's up" from an infrastructure type I'd really appreciate it as neither resi nor business support seem to have a clue about what I'm asking. TIA, -jamie From colton.conor at gmail.com Tue Apr 7 14:59:42 2015 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 7 Apr 2015 09:59:42 -0500 Subject: Low Cost CWDM or DWDM Message-ID: What vendors do you recommend for low cost CWDM / DWDM gear? Assume you have a fiber ring of 50 miles of fiber, and want to have POPs evenly spaced around the ring that you want to jump on and off of. Assume you only have 2 fiber strands to work with, but can obtain two more at an additional cost. Does 2 vs 4 fibers make a difference? The goal is to be able to offer multiple 10G connections to clients on the ring. All ethernet/wave no support for legacy SONET needed. How do you decide between CWDM vs DWDM? There are so many manufacturers that make transport gear I do not even know where to begin. Is there a guide to navigating through the big optical transport vendors? There are over 20 of them, and they all seem to do the same thing on paper. From ryan.dirocco at totalserversolutions.com Tue Apr 7 15:19:55 2015 From: ryan.dirocco at totalserversolutions.com (Ryan DiRocco) Date: Tue, 7 Apr 2015 15:19:55 +0000 Subject: Low Cost CWDM or DWDM In-Reply-To: References: Message-ID: We have been very happy with Adva for our DWDM ring deployments with multiple drop-add points. As always proper engineering is critical to make sure you are taking into account the loss points from all the muxes, drop-adds, etc. Adva's sales / engineering / and subsequent support have been fantastic. Granted they aren't as cheap as the "low cost" ebay gear out of china but you are getting quality instead of a crapshoot of loss on each mux or drop/add you source. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Tuesday, April 07, 2015 11:00 AM To: NANOG Subject: Low Cost CWDM or DWDM What vendors do you recommend for low cost CWDM / DWDM gear? Assume you have a fiber ring of 50 miles of fiber, and want to have POPs evenly spaced around the ring that you want to jump on and off of. Assume you only have 2 fiber strands to work with, but can obtain two more at an additional cost. Does 2 vs 4 fibers make a difference? The goal is to be able to offer multiple 10G connections to clients on the ring. All ethernet/wave no support for legacy SONET needed. How do you decide between CWDM vs DWDM? There are so many manufacturers that make transport gear I do not even know where to begin. Is there a guide to navigating through the big optical transport vendors? There are over 20 of them, and they all seem to do the same thing on paper. From huc at ieee.org Tue Apr 7 18:09:47 2015 From: huc at ieee.org (huc@ieee) Date: Tue, 7 Apr 2015 20:09:47 +0200 Subject: [OT]call for backers: open source hardware for networking innovation (ONetSwitch) In-Reply-To: <44C748D7-F4EC-41DD-A809-37863D722AB2@ieee.org> References: <44C748D7-F4EC-41DD-A809-37863D722AB2@ieee.org> Message-ID: <99FD159C-A77D-4208-A3CB-6A1FDE768CB9@ieee.org> The kickstarter project is going to be expired in about 2 days. The price will go up a bit after the kickstarter promotion. One board now is $699 (which will go up to over $1000), and we also have sets of 1299 for two boards, 2599 for four boards, and 3899 for 6 boards. We still has gap to make the kickstarter project success, so if you'd like to buy some boards, we appreciate you to back now at https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking Thanks and regards, Chengchen On 2015-3-3, at 下午9:47, huc at ieee wrote: > > Sorry for a little bit off topic. > > This email is to inform you a new open source hardware for networking innovation called ONetSwitch. It is an all-programmable networking platform combining ARM and FPGA in a 17cm*13cm area (notebook size) for testing and verifying research idea related to networking. Different from previous FPGA develop board like NetFPGA/Xilinx PCIe board, host PC is not required any more for ONetSwitch, and it is smaller, cheaper, and more power efficient. and more flexible. > > We have launched the ONetSwitch project on Kickstarter.com weeks ago. You can get an abstract from the short video, which will not take you long to get our idea :-) > > https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking > > We had a paper at ONS 2014 presenting the preliminary design of ONetSwitch (https://www.usenix.org/system/files/conference/ons2014/ons2014-paper-hu_chengchen.pdf) and a demo at SIGCOMM'14 setting a data center testbed on only desktop using ONetSwitch (http://nskeylab.xjtu.edu.cn/people/huc/Pub/DesktopDC_2014.pdf). In the new version now at kickstarter, we add further physical support on 802.11 AC, mSATA, which suits for more scenarios. Also, we have open source ref. design and supporting wiki available at github (https://github.com/MeshSr/wiki/wiki/REF-OpenFlowSwitch-HWFT). The processing logic can be modified in both software (ARM) and hardware (FPGA) to fit your own needs. Although it is currently highlighted mainly on SDN and DCN, we aim to provide the research community a way to set their testbeds for any networking innovations easily. > > I send the info. about ONetSwitch to this mail list since I think it may be useful to guys in this community. Please do us a favor and back us to get your own programmable testbed. We believe ONetSwitch would give much help to your research and development work. Also, can you help distribute it to friends and colleagues who will be interested with this? Even for the guys, who do not need ONetSwitch but think it is good, we greatly appreciate you to back us with $1 for encouraging. > > Regards, > > Chengchen > > ======================================================================= > Dr. Chengchen Hu, > > ERCIM Fellow > Norwegian University of Science and Technology (NTNU) > > Associate Professor (Sabbatical leave till Oct., 2015) > Xi'an Jiaotong University > > http://nskeylab.xjtu.edu.cn/people/cchu > ======================================================================= > > > From sander at steffann.nl Tue Apr 7 19:49:40 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 Apr 2015 21:49:40 +0200 Subject: Looking for Sky UK contact Message-ID: <0A6602FB-CF23-4621-921E-07628A1078D6@steffann.nl> Hi, If there is anybody from Sky UK here please contact me off-list. Cheers! Sander From johnl at iecc.com Tue Apr 7 22:26:09 2015 From: johnl at iecc.com (John Levine) Date: 7 Apr 2015 22:26:09 -0000 Subject: Fixing Google geolocation screwups Message-ID: <20150407222609.28626.qmail@ary.lan> A friend of mine lives in Alabama and has business service from at&t. But Google thinks he's in France. We've checked for various possibilities of VPNs and proxies and such, and it's pretty clear that the Goog's geolocation for addresses around 99.106.185.0/24 is screwed up. Bing and other services correctly find him in Alabama. Poking around I see lots of advice about how to use Google's geolocation data, but nothing on how to update it. Anyone know the secret? TIA Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From pmsac.nanog at gmail.com Tue Apr 7 22:41:04 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Tue, 7 Apr 2015 23:41:04 +0100 Subject: Fixing Google geolocation screwups Message-ID: https://support.google.com/websearch/answer/873?hl=en On 7 April 2015 at 23:26, John Levine wrote: > A friend of mine lives in Alabama and has business service from at&t. > But Google thinks he's in France. We've checked for various > possibilities of VPNs and proxies and such, and it's pretty clear that > the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > up. Bing and other services correctly find him in Alabama. > > Poking around I see lots of advice about how to use Google's > geolocation data, but nothing on how to update it. Anyone > know the secret? TIA > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > > From fred at web2objects.com Tue Apr 7 22:42:00 2015 From: fred at web2objects.com (Fred Hollis) Date: Wed, 08 Apr 2015 00:42:00 +0200 Subject: Fixing Google geolocation screwups In-Reply-To: <20150407222609.28626.qmail@ary.lan> References: <20150407222609.28626.qmail@ary.lan> Message-ID: <55245D38.1020308@web2objects.com> Thanks for sending this to the list: We have the very same issue as well (both IPv4+IPv6). If someone knows the magic button to solve this, please contact me as well. On 08.04.2015 at 00:26 John Levine wrote: > A friend of mine lives in Alabama and has business service from at&t. > But Google thinks he's in France. We've checked for various > possibilities of VPNs and proxies and such, and it's pretty clear that > the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > up. Bing and other services correctly find him in Alabama. > > Poking around I see lots of advice about how to use Google's > geolocation data, but nothing on how to update it. Anyone > know the secret? TIA > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > From xionox at gmail.com Tue Apr 7 23:09:21 2015 From: xionox at gmail.com (Arzhel Younsi) Date: Wed, 08 Apr 2015 11:09:21 +1200 Subject: Fixing Google geolocation screwups In-Reply-To: <55245D38.1020308@web2objects.com> References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> Message-ID: <1428448161.730017.250496609.728B77DE@webmail.messagingengine.com> The list on http://nanog.peeringdb.com/index.php/GeoIP is useful, especially if several GeoIP databases return incorrect locations. -- Arzhel On Wed, Apr 8, 2015, at 10:42, Fred Hollis wrote: > Thanks for sending this to the list: We have the very same issue as well > (both IPv4+IPv6). If someone knows the magic button to solve this, > please contact me as well. > > On 08.04.2015 at 00:26 John Levine wrote: > > A friend of mine lives in Alabama and has business service from at&t. > > But Google thinks he's in France. We've checked for various > > possibilities of VPNs and proxies and such, and it's pretty clear that > > the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > > up. Bing and other services correctly find him in Alabama. > > > > Poking around I see lots of advice about how to use Google's > > geolocation data, but nothing on how to update it. Anyone > > know the secret? TIA > > > > Regards, > > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > > Please consider the environment before reading this e-mail. http://jl.ly > > > > From aaron at heyaaron.com Tue Apr 7 23:10:27 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 7 Apr 2015 16:10:27 -0700 Subject: Fixing Google geolocation screwups In-Reply-To: <55245D38.1020308@web2objects.com> References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> Message-ID: You might try here: https://www.maxmind.com/en/correction -A On Tue, Apr 7, 2015 at 3:42 PM, Fred Hollis wrote: > Thanks for sending this to the list: We have the very same issue as well > (both IPv4+IPv6). If someone knows the magic button to solve this, please > contact me as well. > > > On 08.04.2015 at 00:26 John Levine wrote: >> >> A friend of mine lives in Alabama and has business service from at&t. >> But Google thinks he's in France. We've checked for various >> possibilities of VPNs and proxies and such, and it's pretty clear that >> the Goog's geolocation for addresses around 99.106.185.0/24 is screwed >> up. Bing and other services correctly find him in Alabama. >> >> Poking around I see lots of advice about how to use Google's >> geolocation data, but nothing on how to update it. Anyone >> know the secret? TIA >> >> Regards, >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >> Dummies", >> Please consider the environment before reading this e-mail. http://jl.ly >> >> > From blair.trosper at gmail.com Tue Apr 7 23:17:20 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 7 Apr 2015 18:17:20 -0500 Subject: Fixing Google geolocation screwups In-Reply-To: References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> Message-ID: No, Google has their own internal system. Doubt MaxMind will help out. This discussions and others like it may lead you in the right direction: https://productforums.google.com/forum/#!topic/websearch/fkyem9xUKOQ On Tue, Apr 7, 2015 at 6:10 PM, Aaron C. de Bruyn wrote: > You might try here: https://www.maxmind.com/en/correction > > -A > > On Tue, Apr 7, 2015 at 3:42 PM, Fred Hollis wrote: > > Thanks for sending this to the list: We have the very same issue as well > > (both IPv4+IPv6). If someone knows the magic button to solve this, please > > contact me as well. > > > > > > On 08.04.2015 at 00:26 John Levine wrote: > >> > >> A friend of mine lives in Alabama and has business service from at&t. > >> But Google thinks he's in France. We've checked for various > >> possibilities of VPNs and proxies and such, and it's pretty clear that > >> the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > >> up. Bing and other services correctly find him in Alabama. > >> > >> Poking around I see lots of advice about how to use Google's > >> geolocation data, but nothing on how to update it. Anyone > >> know the secret? TIA > >> > >> Regards, > >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > >> Dummies", > >> Please consider the environment before reading this e-mail. > http://jl.ly > >> > >> > > > From aaron at heyaaron.com Tue Apr 7 23:29:57 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 7 Apr 2015 16:29:57 -0700 Subject: Fixing Google geolocation screwups In-Reply-To: References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> Message-ID: I figure they all collaborate. I updated one of our IPs with MaxMind and a few weeks later Google was fixed. Of course that could be because half the staff here carry tiny GPS-enabled Google location reporting devices in their pocket too... -A On Tue, Apr 7, 2015 at 4:17 PM, Blair Trosper wrote: > No, Google has their own internal system. Doubt MaxMind will help out. > > This discussions and others like it may lead you in the right direction: > https://productforums.google.com/forum/#!topic/websearch/fkyem9xUKOQ > > On Tue, Apr 7, 2015 at 6:10 PM, Aaron C. de Bruyn > wrote: >> >> You might try here: https://www.maxmind.com/en/correction >> >> -A >> >> On Tue, Apr 7, 2015 at 3:42 PM, Fred Hollis wrote: >> > Thanks for sending this to the list: We have the very same issue as well >> > (both IPv4+IPv6). If someone knows the magic button to solve this, >> > please >> > contact me as well. >> > >> > >> > On 08.04.2015 at 00:26 John Levine wrote: >> >> >> >> A friend of mine lives in Alabama and has business service from at&t. >> >> But Google thinks he's in France. We've checked for various >> >> possibilities of VPNs and proxies and such, and it's pretty clear that >> >> the Goog's geolocation for addresses around 99.106.185.0/24 is screwed >> >> up. Bing and other services correctly find him in Alabama. >> >> >> >> Poking around I see lots of advice about how to use Google's >> >> geolocation data, but nothing on how to update it. Anyone >> >> know the secret? TIA >> >> >> >> Regards, >> >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >> >> Dummies", >> >> Please consider the environment before reading this e-mail. >> >> http://jl.ly >> >> >> >> >> > > > From blair.trosper at gmail.com Tue Apr 7 23:32:18 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 7 Apr 2015 18:32:18 -0500 Subject: Fixing Google geolocation screwups In-Reply-To: References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> Message-ID: It wouldn't hurt to correct it with MaxMind (a great product), but you'd probably have better results dealing with Google directly. If you have Google Apps, you've got support, and that would be one way to go about getting it addressed. On Tue, Apr 7, 2015 at 6:29 PM, Aaron C. de Bruyn wrote: > I figure they all collaborate. I updated one of our IPs with MaxMind > and a few weeks later Google was fixed. > > Of course that could be because half the staff here carry tiny > GPS-enabled Google location reporting devices in their pocket too... > > -A > > On Tue, Apr 7, 2015 at 4:17 PM, Blair Trosper > wrote: > > No, Google has their own internal system. Doubt MaxMind will help out. > > > > This discussions and others like it may lead you in the right direction: > > https://productforums.google.com/forum/#!topic/websearch/fkyem9xUKOQ > > > > On Tue, Apr 7, 2015 at 6:10 PM, Aaron C. de Bruyn > > wrote: > >> > >> You might try here: https://www.maxmind.com/en/correction > >> > >> -A > >> > >> On Tue, Apr 7, 2015 at 3:42 PM, Fred Hollis > wrote: > >> > Thanks for sending this to the list: We have the very same issue as > well > >> > (both IPv4+IPv6). If someone knows the magic button to solve this, > >> > please > >> > contact me as well. > >> > > >> > > >> > On 08.04.2015 at 00:26 John Levine wrote: > >> >> > >> >> A friend of mine lives in Alabama and has business service from at&t. > >> >> But Google thinks he's in France. We've checked for various > >> >> possibilities of VPNs and proxies and such, and it's pretty clear > that > >> >> the Goog's geolocation for addresses around 99.106.185.0/24 is > screwed > >> >> up. Bing and other services correctly find him in Alabama. > >> >> > >> >> Poking around I see lots of advice about how to use Google's > >> >> geolocation data, but nothing on how to update it. Anyone > >> >> know the secret? TIA > >> >> > >> >> Regards, > >> >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet > for > >> >> Dummies", > >> >> Please consider the environment before reading this e-mail. > >> >> http://jl.ly > >> >> > >> >> > >> > > > > > > From johnl at iecc.com Wed Apr 8 01:24:26 2015 From: johnl at iecc.com (John R. Levine) Date: 7 Apr 2015 21:24:26 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: References: Message-ID: > https://support.google.com/websearch/answer/873?hl=en He says he sent in the IP update three weeks ago, nothing happened. Any other suggestions? > > > On 7 April 2015 at 23:26, John Levine wrote: > >> A friend of mine lives in Alabama and has business service from at&t. >> But Google thinks he's in France. We've checked for various >> possibilities of VPNs and proxies and such, and it's pretty clear that >> the Goog's geolocation for addresses around 99.106.185.0/24 is screwed >> up. Bing and other services correctly find him in Alabama. >> >> Poking around I see lots of advice about how to use Google's >> geolocation data, but nothing on how to update it. Anyone >> know the secret? TIA >> >> Regards, >> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >> Dummies", >> Please consider the environment before reading this e-mail. http://jl.ly >> >> >> > From morrowc.lists at gmail.com Wed Apr 8 01:41:40 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 7 Apr 2015 21:41:40 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: References: Message-ID: "We'll investigate your report and, if necessary, pass the details on to our engineering team. Updates to IP addresses may take more than a month. We won't follow up with you individually but we'll do our best to resolve the issue." 'more than a month' > 3wks. On Tue, Apr 7, 2015 at 9:24 PM, John R. Levine wrote: >> https://support.google.com/websearch/answer/873?hl=en > > > He says he sent in the IP update three weeks ago, nothing happened. Any > other suggestions? > > >> >> >> On 7 April 2015 at 23:26, John Levine wrote: >> >>> A friend of mine lives in Alabama and has business service from at&t. >>> But Google thinks he's in France. We've checked for various >>> possibilities of VPNs and proxies and such, and it's pretty clear that >>> the Goog's geolocation for addresses around 99.106.185.0/24 is screwed >>> up. Bing and other services correctly find him in Alabama. >>> >>> Poking around I see lots of advice about how to use Google's >>> geolocation data, but nothing on how to update it. Anyone >>> know the secret? TIA >>> >>> Regards, >>> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >>> Dummies", >>> Please consider the environment before reading this e-mail. http://jl.ly >>> >>> >>> >> > From josh at spitwspots.com Tue Apr 7 23:29:55 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Tue, 07 Apr 2015 15:29:55 -0800 Subject: Fixing Google geolocation screwups In-Reply-To: References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> Message-ID: <55246873.4010701@spitwspots.com> maxmind is the company that does it for speedtest.net So if you've ever wondered why your IP blocks still show up as coming from your upstream and not you, well, that's why. /hard_learned_trade_secret On 04/07/2015 03:17 PM, Blair Trosper wrote: > No, Google has their own internal system. Doubt MaxMind will help out. > > This discussions and others like it may lead you in the right direction: > https://productforums.google.com/forum/#!topic/websearch/fkyem9xUKOQ > > On Tue, Apr 7, 2015 at 6:10 PM, Aaron C. de Bruyn > wrote: > >> You might try here: https://www.maxmind.com/en/correction >> >> -A >> >> On Tue, Apr 7, 2015 at 3:42 PM, Fred Hollis wrote: >>> Thanks for sending this to the list: We have the very same issue as well >>> (both IPv4+IPv6). If someone knows the magic button to solve this, please >>> contact me as well. >>> >>> >>> On 08.04.2015 at 00:26 John Levine wrote: >>>> A friend of mine lives in Alabama and has business service from at&t. >>>> But Google thinks he's in France. We've checked for various >>>> possibilities of VPNs and proxies and such, and it's pretty clear that >>>> the Goog's geolocation for addresses around 99.106.185.0/24 is screwed >>>> up. Bing and other services correctly find him in Alabama. >>>> >>>> Poking around I see lots of advice about how to use Google's >>>> geolocation data, but nothing on how to update it. Anyone >>>> know the secret? TIA >>>> >>>> Regards, >>>> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for >>>> Dummies", >>>> Please consider the environment before reading this e-mail. >> http://jl.ly >>>> From mkamal at noor.net Wed Apr 8 09:11:31 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Wed, 08 Apr 2015 12:11:31 +0300 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: <55219036.2080403@noor.net> References: <55196012.9050508@noor.net> <55219036.2080403@noor.net> Message-ID: <5524F0C3.3020704@noor.net> Here is Cisco's reply! “Given PCEP’s main use-case is inter-area TE tunnels (or SDN controller in TE environment) and ASR1K is not marketed for TE, support is unlikely” What is .. "not marketed for TE"?! All in all, I don't mind replacing them with some cheaper, powerful, flexible and SDN-ready juniper MX that are marketed for TE. Mohamed Kamal Core Network Sr. Engineer On 4/5/2015 10:42 PM, Mohamed Kamal wrote: >> and hence being implemented on IOS-XR within the Cisco environment today > I disagree! .. Engineering is all about optimization, and using an ASR1k > (which is being marketed as an "edge/PE router") in my edge doesn't mean > that my network is not a "high-scale environment", it does mean that it > fits my needs in this location, where other IOS-XR (ASR9k) fits in others. > > Plus, PCEP is no magic, Juniper's MX series starting from the vMX is > supporting PCEP. They didn't claim that, a "higher-scale environment" is > being required for this. > >> the demand for online calculation has increased - either due to dependencies for new TE path-instantiating protocols (e.g., SR), or more complex constraints that cannot be well met by offline calculation or CSPF > That's why PCEP support should be added to the road-map in the near future. > > Mohamed Kamal > Core Network Sr. Engineer > > On 4/5/2015 8:33 PM, Rob Shakir wrote: >> On 30 March 2015 at 15:42:59, Mohamed Kamal (mkamal at noor.net) wrote: >>> I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?! >>> >>> Should I be getting a 9k/CRS on the edge to implement an automatic tool >>> to build MPLS-TE tunnels! >> In general, PCE(P) implementations have been limited. IMHO the last 10 years of RSVP-TE management has generally been done with auto-mesh tools, or in-house driven offline path calculation tools (e.g., WANDL, Cariden, Aria…). >> >> As such, the demand for online calculation has increased - either due to dependencies for new TE path-instantiating protocols (e.g., SR), or more complex constraints that cannot be well met by offline calculation or CSPF (e.g., path-diversity with disjoint head-end PEs). This demand is mainly coming in higher-scale environments - and hence being implemented on IOS-XR within the Cisco environment today. I expect this is why IOS-XE is lagging. There are certainly requests for support - but as Mark says, you’ll need to interface with your account team to figure out when code will be available for your platform. >> >> As to whether you should buy an IOS XR device for your edge, I’m not sure what kind of logic would mean that device selection is solely based on PCEP support :-). I would certainly look more into the existing “automatic” tools, and possibilities for offline calculation in the interim period. >> >> r. >> > From rs at seastrom.com Wed Apr 8 11:17:54 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 08 Apr 2015 07:17:54 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: (Blair Trosper's message of "Tue, 7 Apr 2015 18:32:18 -0500") References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> Message-ID: <86sicadg2l.fsf@valhalla.seastrom.com> Blair Trosper writes: > MaxMind (a great product) I've heard anecdotal accounts of MaxMind intentionally marking all address blocks assigned to a VPN vendor as "open proxy" even when advised repeatedly that the disputed addresses (a) had no VPN services running on them either inbound or outbound, and (b) in fact were web servers for the company's payment system, or mail servers for their corporate email. Kind of reminiscent of dealing with certain RBLs for whom "personal beef" was enough reason to list an address. So, folks might want to temper the "great product" comment with this anti-endorsement. -r From maxtul at netassist.ua Wed Apr 8 11:31:24 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 08 Apr 2015 14:31:24 +0300 Subject: Fixing Google geolocation screwups In-Reply-To: <20150407222609.28626.qmail@ary.lan> References: <20150407222609.28626.qmail@ary.lan> Message-ID: <5525118C.1070003@netassist.ua> We operate IPv6 tunnel broker tb.netassist.ua, so /48 from our /32 is spread all around the world. Google change geo of our WHOLE /32 from time to time to another cute random place ;) One time Google decided we are in IRAN and block a lot of content as "not available in your country" o_O Unfortunately, there is no "magic button" to fix it, as well as no human contact in Google to discuss it. I'm still trying to find a good solution, but not found it. On 04/08/15 01:26, John Levine wrote: > A friend of mine lives in Alabama and has business service from at&t. > But Google thinks he's in France. We've checked for various > possibilities of VPNs and proxies and such, and it's pretty clear that > the Goog's geolocation for addresses around 99.106.185.0/24 is screwed > up. Bing and other services correctly find him in Alabama. > > Poking around I see lots of advice about how to use Google's > geolocation data, but nothing on how to update it. Anyone > know the secret? TIA > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > > > From ag4ve.us at gmail.com Wed Apr 8 11:52:01 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 8 Apr 2015 07:52:01 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: <86sicadg2l.fsf@valhalla.seastrom.com> References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> <86sicadg2l.fsf@valhalla.seastrom.com> Message-ID: On Apr 8, 2015 7:19 AM, "Rob Seastrom" wrote: > > > Blair Trosper writes: > > > MaxMind (a great product) > > I've heard anecdotal accounts of MaxMind intentionally marking all > address blocks assigned to a VPN vendor as "open proxy" even when > advised repeatedly that the disputed addresses (a) had no VPN services > running on them either inbound or outbound, and (b) in fact were web > servers for the company's payment system, or mail servers for their > corporate email. > I would wonder if these apps didn't have issues that allowed web proxy to the world. Maybe MaxMind is doing something wrong or maybe they're seeing the result of malicious activities and classifying from that. From jeroen at massar.ch Wed Apr 8 11:56:20 2015 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 08 Apr 2015 13:56:20 +0200 Subject: Fixing Google geolocation screwups In-Reply-To: <5525118C.1070003@netassist.ua> References: <20150407222609.28626.qmail@ary.lan> <5525118C.1070003@netassist.ua> Message-ID: <55251764.5060204@massar.ch> On 2015-04-08 13:31, Max Tulyev wrote: > We operate IPv6 tunnel broker tb.netassist.ua, so /48 from our /32 is > spread all around the world. > Google change geo of our WHOLE /32 from time to time to another cute > random place ;) One time Google decided we are in IRAN and block a lot > of content as "not available in your country" o_O > Unfortunately, there is no "magic button" to fix it, as well as no human > contact in Google to discuss it. I'm still trying to find a good > solution, but not found it. Do check: http://tools.ietf.org/html/draft-google-self-published-geofeeds-02 That draft also contains folks to kick who wrote it. Or more details on how SixXS uses that: https://www.sixxs.net/faq/misc/?faq=geolocation It is a hard problem unfortunately as there are a variety of reasons why content owners perform Geolocation (language detection / Content restrictions etc). For most organizations "Geolocation" all comes down to "IP Protection" (Stupid Property aka "Content", not Internet Protocol). Hence, if you have a /32 IPv6 assigned to the Ukraine (which is already considered a shady country by most unfortunately for you) and then start offering VPN services, you'll likely just end up blocked in most of these "IP protecting networks" as folks just think you are trying to circumvent their great and awesome IP Protection strategies. That stated, properly providing a WHOIS entry for each prefix (inetnum/inet6num) is a good idea as that kind of indicates that that prefix is fixed in that location and not just moving around. As for Google, well, they have the method described above, but as they are primarily a HTTP company, they could just detect Language setting by the HTTP Accept-Language header. For YouTube etc they are in the same boat as everybody else: IP Protection. (property not network). In the end, having a prefix per country/region is the correct way to go. Do make sure though that you do not show any foreign address in the whois data (even if that is the correct entity that the prefix is registered under) otherwise that whole prefix will suddenly be blocked by for instance Netflix as "it is foreign"... Though Netflix always considers VPNs as a bad thing, ignoring the fact that for some folks that is the only real way to get a reasonable Internet experience. That all said: Restricting content based on location is complete and utter nonsense in 2015. The world is global, people want to pay for content and the content owners just don't allow people to pay for it. We all know what the end result of that is ;) Greets, Jeroen From tim at pelican.org Wed Apr 8 12:17:09 2015 From: tim at pelican.org (Tim Franklin) Date: Wed, 8 Apr 2015 13:17:09 +0100 (BST) Subject: Fixing Google geolocation screwups In-Reply-To: <55251764.5060204@massar.ch> References: <20150407222609.28626.qmail@ary.lan> <5525118C.1070003@netassist.ua> <55251764.5060204@massar.ch> Message-ID: <1980853012.6341.1428495429797.JavaMail.zimbra@pelican.org> > That all said: Restricting content based on location is complete and > utter nonsense in 2015. The world is global, people want to pay for > content and the content owners just don't allow people to pay for it. Globalisation is for your corporate lords and masters to buy labour and raw materials where they're cheap. If mere peons try to buy goods and services in the same way, expect to be crushed by the best legislation money can buy :( Regards, Tim. From colinj at gt86car.org.uk Wed Apr 8 12:36:29 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 8 Apr 2015 13:36:29 +0100 Subject: Fixing Google geolocation screwups In-Reply-To: <1980853012.6341.1428495429797.JavaMail.zimbra@pelican.org> References: <20150407222609.28626.qmail@ary.lan> <5525118C.1070003@netassist.ua> <55251764.5060204@massar.ch> <1980853012.6341.1428495429797.JavaMail.zimbra@pelican.org> Message-ID: <9367629C-E697-41CF-828B-C0146F611051@gt86car.org.uk> Globalisation only works if network abuse and network contacts follow best practice and engage. Else trade blocks and network country blocks are done and remain in place until certain countries ethically/practically do the right thing. Colin > On 8 Apr 2015, at 13:17, Tim Franklin wrote: > >> That all said: Restricting content based on location is complete and >> utter nonsense in 2015. The world is global, people want to pay for >> content and the content owners just don't allow people to pay for it. > > Globalisation is for your corporate lords and masters to buy labour and raw materials where they're cheap. > > If mere peons try to buy goods and services in the same way, expect to be crushed by the best legislation money can buy :( > > Regards, > Tim. From bedard.phil at gmail.com Wed Apr 8 13:11:04 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 8 Apr 2015 09:11:04 -0400 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: <5524F0C3.3020704@noor.net> References: <55196012.9050508@noor.net> <55219036.2080403@noor.net> <5524F0C3.3020704@noor.net> Message-ID: <55252903.71518c0a.03cc.55c8@mx.google.com> One of the downsides to having four (at least) different control plane operating systems across your product lines. Phil -----Original Message----- From: "Mohamed Kamal" Sent: ‎4/‎8/‎2015 5:13 AM To: "NANOG" Subject: Re: Cisco's IOS-XE and PCEP implementation Here is Cisco's reply! “Given PCEP’s main use-case is inter-area TE tunnels (or SDN controller in TE environment) and ASR1K is not marketed for TE, support is unlikely” What is .. "not marketed for TE"?! All in all, I don't mind replacing them with some cheaper, powerful, flexible and SDN-ready juniper MX that are marketed for TE. Mohamed Kamal Core Network Sr. Engineer On 4/5/2015 10:42 PM, Mohamed Kamal wrote: >> and hence being implemented on IOS-XR within the Cisco environment today > I disagree! .. Engineering is all about optimization, and using an ASR1k > (which is being marketed as an "edge/PE router") in my edge doesn't mean > that my network is not a "high-scale environment", it does mean that it > fits my needs in this location, where other IOS-XR (ASR9k) fits in others. > > Plus, PCEP is no magic, Juniper's MX series starting from the vMX is > supporting PCEP. They didn't claim that, a "higher-scale environment" is > being required for this. > >> the demand for online calculation has increased - either due to dependencies for new TE path-instantiating protocols (e.g., SR), or more complex constraints that cannot be well met by offline calculation or CSPF > That's why PCEP support should be added to the road-map in the near future. > > Mohamed Kamal > Core Network Sr. Engineer > > On 4/5/2015 8:33 PM, Rob Shakir wrote: >> On 30 March 2015 at 15:42:59, Mohamed Kamal (mkamal at noor.net) wrote: >>> I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?! >>> >>> Should I be getting a 9k/CRS on the edge to implement an automatic tool >>> to build MPLS-TE tunnels! >> In general, PCE(P) implementations have been limited. IMHO the last 10 years of RSVP-TE management has generally been done with auto-mesh tools, or in-house driven offline path calculation tools (e.g., WANDL, Cariden, Aria…). >> >> As such, the demand for online calculation has increased - either due to dependencies for new TE path-instantiating protocols (e.g., SR), or more complex constraints that cannot be well met by offline calculation or CSPF (e.g., path-diversity with disjoint head-end PEs). This demand is mainly coming in higher-scale environments - and hence being implemented on IOS-XR within the Cisco environment today. I expect this is why IOS-XE is lagging. There are certainly requests for support - but as Mark says, you’ll need to interface with your account team to figure out when code will be available for your platform. >> >> As to whether you should buy an IOS XR device for your edge, I’m not sure what kind of logic would mean that device selection is solely based on PCEP support :-). I would certainly look more into the existing “automatic” tools, and possibilities for offline calculation in the interim period. >> >> r. >> > From maxtul at netassist.ua Wed Apr 8 13:26:49 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 08 Apr 2015 16:26:49 +0300 Subject: Fixing Google geolocation screwups In-Reply-To: <55251764.5060204@massar.ch> References: <20150407222609.28626.qmail@ary.lan> <5525118C.1070003@netassist.ua> <55251764.5060204@massar.ch> Message-ID: <55252C99.9050305@netassist.ua> On 04/08/15 14:56, Jeroen Massar wrote: > That stated, properly providing a WHOIS entry for each prefix > (inetnum/inet6num) is a good idea as that kind of indicates that that > prefix is fixed in that location and not just moving around. [skip] > Do make sure though that you do not show any foreign address in the > whois data (even if that is the correct entity that the prefix is > registered under) Seems that it is contrary to each other ;) I thought to do something like automated whois query on tunnel destination and put that (geo)data to each /48 inet6num tunnelled. But as I don't believe it will help, so priority of that task is low and not yet realized. From rs at seastrom.com Wed Apr 8 13:48:37 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 08 Apr 2015 09:48:37 -0400 Subject: Fixing Google geolocation screwups In-Reply-To: (shawn wilson's message of "Wed, 8 Apr 2015 07:52:01 -0400") References: <20150407222609.28626.qmail@ary.lan> <55245D38.1020308@web2objects.com> <86sicadg2l.fsf@valhalla.seastrom.com> Message-ID: <86k2xmu3wq.fsf@valhalla.seastrom.com> shawn wilson writes: > On Apr 8, 2015 7:19 AM, "Rob Seastrom" <[[rs at seastrom.com]]> wrote: >> >> >> Blair Trosper <[[blair.trosper at gmail.com]]> writes: >> >> > MaxMind (a great product) >> >> I've heard anecdotal accounts of MaxMind intentionally marking all >> address blocks assigned to a VPN vendor as "open proxy" even when >> advised repeatedly that the disputed addresses (a) had no VPN services >> running on them either inbound or outbound, and (b) in fact were web >> servers for the company's payment system, or mail servers for their >> corporate email. >> > > I would wonder if these apps didn't have issues that allowed web proxy to the > world. Maybe MaxMind is doing something wrong or maybe they're seeing the > result of malicious activities and classifying from that. That was not the conclusion that one would draw from their replies. -r From mkamal at noor.net Wed Apr 8 16:06:30 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Wed, 08 Apr 2015 19:06:30 +0300 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: <55252903.71518c0a.03cc.55c8@mx.google.com> References: <55196012.9050508@noor.net> <55219036.2080403@noor.net> <5524F0C3.3020704@noor.net> <55252903.71518c0a.03cc.55c8@mx.google.com> Message-ID: <55255206.2010606@noor.net> Yes, indeed! Things like VPLS, full-features ESI and PCEP exist on IOS-XR but not IOS and IOS-XE! ISSU and HA operates differently between IOS-XE and NX-OS! Their claim is not even logical, the ASR1k is supporting 600 TE tunnels head-end, and up-to 10k midpoint! So, if I had an average of 30 ASR1k in the edge, each with 500 TE, there will be over 15000 TE tunnels in the core which will be creating a need for automatic tool such as NorthStar of Juniper! Mohamed Kamal Core Network Sr. Engineer On 4/8/2015 4:11 PM, Phil Bedard wrote: > One of the downsides to having four (at least) different control plane > operating systems across your product lines. > > Phil > ------------------------------------------------------------------------ > From: Mohamed Kamal > Sent: ‎4/‎8/‎2015 5:13 AM > To: NANOG > Subject: Re: Cisco's IOS-XE and PCEP implementation > > Here is Cisco's reply! > > “Given PCEP’s main use-case is inter-area TE tunnels (or SDN controller in > TE environment) and ASR1K is not marketed for TE, support is unlikely” > > What is .. "not marketed for TE"?! > > All in all, I don't mind replacing them with some cheaper, powerful, > flexible and SDN-ready juniper MX that are marketed for TE. > > Mohamed Kamal > Core Network Sr. Engineer > > On 4/5/2015 10:42 PM, Mohamed Kamal wrote: > >> and hence being implemented on IOS-XR within the Cisco environment > today > > I disagree! .. Engineering is all about optimization, and using an ASR1k > > (which is being marketed as an "edge/PE router") in my edge doesn't mean > > that my network is not a "high-scale environment", it does mean that it > > fits my needs in this location, where other IOS-XR (ASR9k) fits in > others. > > > > Plus, PCEP is no magic, Juniper's MX series starting from the vMX is > > supporting PCEP. They didn't claim that, a "higher-scale environment" is > > being required for this. > > > >> the demand for online calculation has increased - either due to > dependencies for new TE path-instantiating protocols (e.g., SR), or > more complex constraints that cannot be well met by offline > calculation or CSPF > > That's why PCEP support should be added to the road-map in the near > future. > > > > Mohamed Kamal > > Core Network Sr. Engineer > > > > On 4/5/2015 8:33 PM, Rob Shakir wrote: > >> On 30 March 2015 at 15:42:59, Mohamed Kamal (mkamal at noor.net) wrote: > >>> I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till > now?! > >>> > >>> Should I be getting a 9k/CRS on the edge to implement an automatic > tool > >>> to build MPLS-TE tunnels! > >> In general, PCE(P) implementations have been limited. IMHO the last > 10 years of RSVP-TE management has generally been done with auto-mesh > tools, or in-house driven offline path calculation tools (e.g., WANDL, > Cariden, Aria…). > >> > >> As such, the demand for online calculation has increased - either > due to dependencies for new TE path-instantiating protocols (e.g., > SR), or more complex constraints that cannot be well met by offline > calculation or CSPF (e.g., path-diversity with disjoint head-end PEs). > This demand is mainly coming in higher-scale environments - and hence > being implemented on IOS-XR within the Cisco environment today. I > expect this is why IOS-XE is lagging. There are certainly requests for > support - but as Mark says, you’ll need to interface with your account > team to figure out when code will be available for your platform. > >> > >> As to whether you should buy an IOS XR device for your edge, I’m > not sure what kind of logic would mean that device selection is solely > based on PCEP support :-). I would certainly look more into the > existing “automatic” tools, and possibilities for offline calculation > in the interim period. > >> > >> r. > >> > > > From dave.taht at gmail.com Wed Apr 8 17:58:12 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 8 Apr 2015 10:58:12 -0700 Subject: Consumer products with baked-in VLAN tagging In-Reply-To: <552115A7.9060508@foobar.org> References: <133C37AE-4C25-4004-B2B2-DF3E068836E6@seastrom.com> <552115A7.9060508@foobar.org> Message-ID: On Sun, Apr 5, 2015 at 3:59 AM, Nick Hilliard wrote: > On 05/04/2015 03:32, Robert Seastrom wrote: >> As you may know if you've played around with recent Apple Airports >> (Express at least) in bridge mode with "guest network" turned on, they >> seem to know about 802.1q and have fairly reasonable or at least >> defensible behavior out of the box - that is to say they move the >> "native" SSID as untagged, and the "guest" SSID tagged 802.1q VLAN >> 1003. >> >> This behavior does not appear to be field-modifyable. I do wish they had bufferbloat-fighting queue managment on the ISP side, it is otherwise pretty good hardware. Do they also supply that vlan to the ethernet? How is their ipv6 with comcast? > Didn't know about that trick. > > I'm going to immediately enable vlan 1003 on the cisco switch that my > express is connected to. > > Nick -- Dave Täht We CAN make better hardware, ourselves, beat bufferbloat, and take back control of the edge of the internet! If we work together, on making it: https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking From piotr.1234 at interia.pl Wed Apr 8 19:01:59 2015 From: piotr.1234 at interia.pl (Piotr) Date: Wed, 08 Apr 2015 21:01:59 +0200 Subject: 100Gb/s TOR switch Message-ID: <55257B27.4090300@interia.pl> Hi, There is something like this on market ? Looking for standalone switch, 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. regards, Peter From rcarpen at network1.net Wed Apr 8 19:14:47 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 8 Apr 2015 15:14:47 -0400 (EDT) Subject: 100Gb/s TOR switch In-Reply-To: <55257B27.4090300@interia.pl> References: <55257B27.4090300@interia.pl> Message-ID: <1848722768.835930.1428520487451.JavaMail.zimbra@network1.net> The Juniper QFX10002-36Q has 36 40GbE Ports. They can be broken out to up to 144 10GbE ports, or 1/3 of them can be used for 100GbE. So, if you use 6 100GbE ports and still have 72 10GbE ports. I have not seen one of these yet in person, but it is the smallest form factor I know of that has that sort of capacity, particularly on the 100GbE. thanks, -Randy ----- On Apr 8, 2015, at 3:01 PM, Piotr piotr.1234 at interia.pl wrote: > Hi, > > There is something like this on market ? Looking for standalone switch, > 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > regards, > Peter From royboy at umich.edu Wed Apr 8 19:37:08 2015 From: royboy at umich.edu (Hockett, Roy) Date: Wed, 8 Apr 2015 15:37:08 -0400 Subject: 100Gb/s TOR switch In-Reply-To: <55257B27.4090300@interia.pl> References: <55257B27.4090300@interia.pl> Message-ID: I did see these switches at SC14. http://www.corsa.com/products/dp6440/ Thanks, -Roy Hockett Network Architect, ITS Communications Systems and Data Centers University of Michigan Tel: (734) 763-7325 Fax: (734) 615-1727 email: royboy at umich.edu On Apr 8, 2015, at 3:01 PM, Piotr wrote: > Hi, > > There is something like this on market ? Looking for standalone switch, 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > regards, > Peter From Kirill.Klimakhin at COREBTS.com Wed Apr 8 19:16:28 2015 From: Kirill.Klimakhin at COREBTS.com (Klimakhin, Kirill) Date: Wed, 8 Apr 2015 19:16:28 +0000 Subject: 100Gb/s TOR switch In-Reply-To: <55257B27.4090300@interia.pl> References: <55257B27.4090300@interia.pl> Message-ID: Cisco Nexus 7700 2 slot chassis supports 48 x 10 Gbps, 24 x 40 Gbps, and 12 x 100 Gbps. It is 3RU. Part number is N77-C7702. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Piotr Sent: Wednesday, April 08, 2015 3:02 PM To: nanog at nanog.org Subject: 100Gb/s TOR switch Hi, There is something like this on market ? Looking for standalone switch, 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. regards, Peter ________________________________ Important Notice: This email message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Core BTS. Core BTS specifically disclaims liability for any damage caused by any virus transmitted by this email. From jofurst at akamai.com Wed Apr 8 19:43:33 2015 From: jofurst at akamai.com (Furst, John-Nicholas) Date: Wed, 8 Apr 2015 19:43:33 +0000 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> Message-ID: If you can wait, you will see the market flooded with 32x100G with the ability to down-clock to 40g / breakout to 4x10g in the Q3/Q4 timeframe ;) John-Nicholas Furst Hardware Engineer Office: +1.617.274.7212 Akamai Technologies 150 Broadway Cambridge, MA 02142 On 4/8/15, 3:37 PM, "Hockett, Roy" wrote: >I did see these switches at SC14. > >http://www.corsa.com/products/dp6440/ > >Thanks, >-Roy Hockett > >Network Architect, >ITS Communications Systems and Data Centers >University of Michigan >Tel: (734) 763-7325 >Fax: (734) 615-1727 >email: royboy at umich.edu > >On Apr 8, 2015, at 3:01 PM, Piotr wrote: > >> Hi, >> >> There is something like this on market ? Looking for standalone switch, >>1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. >> >> regards, >> Peter > From rs at seastrom.com Wed Apr 8 20:21:24 2015 From: rs at seastrom.com (Robert Seastrom) Date: Wed, 8 Apr 2015 16:21:24 -0400 Subject: Consumer products with baked-in VLAN tagging In-Reply-To: References: <133C37AE-4C25-4004-B2B2-DF3E068836E6@seastrom.com> <552115A7.9060508@foobar.org> Message-ID: <9B42514B-1B62-4E31-BBA5-0DD1817229A8@seastrom.com> On Apr 8, 2015, at 1:58 PM, Dave Taht wrote: > I do wish they had bufferbloat-fighting queue managment on the ISP > side, it is otherwise > pretty good hardware. As you're well aware since your name is in the acknowledgements, there's been some effort in this direction at CL. If the problem gets solved in the CMTS and the CM, what the router does is kind of beside the point (unless we've progressed to wanting to do it on the wireless side too). > Do they also supply that vlan to the ethernet? You mean to the southbound ethernet when running as a router instead of to the northbound ethernet while running as a bridge? No idea. That's not my normal use case. > How is their ipv6 with comcast? Beats me. No Comcast handy to test with. I *can* tell you that a freshly factory reset Airport Express 802.11n (2nd Generation) aka A1392 - the currently for sale $99 one - does pretty much exactly what you would hope when plugged into a freshly rebooted cablemodem on Another Pretty Darned Big MSO. That is to say, it gets a PD /64 and you're off to the races with native IPv6 on the wireless side. No warranties expressed or implied, but it seems to do what it says on the tin. A similar test with a freshly factory reset Airport Extreme 802.11n (3rd Generation) aka A1301 is disappointing; default configuration is IPv6 link local only and although there is a knob to put it into "native/automatic" IPv6 configuration it doesn't work as advertised. But hey, it was discontinued five and a half years ago at this point so what do you want? I figured that a test with an even older example I have sitting around in the junk box (A1143) would be similarly unsatisfying. I'd really like to try these native IPv6 tests with my Verizon FIOS at home, but I think I already know the outcome... -r From rcarpen at network1.net Wed Apr 8 20:22:55 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 8 Apr 2015 16:22:55 -0400 (EDT) Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> Message-ID: <92079105.836732.1428524575167.JavaMail.zimbra@network1.net> 7700 2 slot looks to only support 1 line card, so 48x10 *or* 12x100 thanks, -Randy ----- On Apr 8, 2015, at 3:16 PM, Klimakhin, Kirill Kirill.Klimakhin at COREBTS.com wrote: > Cisco Nexus 7700 2 slot chassis supports 48 x 10 Gbps, 24 x 40 Gbps, and 12 x > 100 Gbps. > > It is 3RU. Part number is N77-C7702. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Piotr > Sent: Wednesday, April 08, 2015 3:02 PM > To: nanog at nanog.org > Subject: 100Gb/s TOR switch > > Hi, > > There is something like this on market ? Looking for standalone switch, 1/2U, ca > 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > regards, > Peter > > ________________________________ > Important Notice: This email message and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you are not the named addressee, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. Please note that any views or opinions presented > in this email are solely those of the author and do not necessarily represent > those of Core BTS. Core BTS specifically disclaims liability for any damage > caused by any virus transmitted by this email. From Kirill.Klimakhin at COREBTS.com Wed Apr 8 20:25:55 2015 From: Kirill.Klimakhin at COREBTS.com (Klimakhin, Kirill) Date: Wed, 8 Apr 2015 20:25:55 +0000 Subject: 100Gb/s TOR switch In-Reply-To: <92079105.836732.1428524575167.JavaMail.zimbra@network1.net> References: <55257B27.4090300@interia.pl> <92079105.836732.1428524575167.JavaMail.zimbra@network1.net> Message-ID: That is correct, I didn’t mean that it supports all three. Only one of the three combinations. Regards, Kirill -----Original Message----- From: Randy Carpenter [mailto:rcarpen at network1.net] Sent: Wednesday, April 08, 2015 4:23 PM To: Klimakhin, Kirill Cc: Piotr; nanog at nanog.org Subject: Re: 100Gb/s TOR switch 7700 2 slot looks to only support 1 line card, so 48x10 *or* 12x100 thanks, -Randy ----- On Apr 8, 2015, at 3:16 PM, Klimakhin, Kirill Kirill.Klimakhin at COREBTS.com wrote: > Cisco Nexus 7700 2 slot chassis supports 48 x 10 Gbps, 24 x 40 Gbps, > and 12 x > 100 Gbps. > > It is 3RU. Part number is N77-C7702. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Piotr > Sent: Wednesday, April 08, 2015 3:02 PM > To: nanog at nanog.org > Subject: 100Gb/s TOR switch > > Hi, > > There is something like this on market ? Looking for standalone > switch, 1/2U, ca > 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > regards, > Peter > > ________________________________ > Important Notice: This email message and any files transmitted with it > are confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you are not the named addressee, > you should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. Please note > that any views or opinions presented in this email are solely those of > the author and do not necessarily represent those of Core BTS. Core > BTS specifically disclaims liability for any damage caused by any virus transmitted by this email. ________________________________ Important Notice: This email message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Core BTS. Core BTS specifically disclaims liability for any damage caused by any virus transmitted by this email. From rcarpen at network1.net Wed Apr 8 20:28:00 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 8 Apr 2015 16:28:00 -0400 (EDT) Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> Message-ID: <1470649666.836764.1428524880915.JavaMail.zimbra@network1.net> 25/50/100 stuff should start coming out around soon, as well, which may drive pricing down even more. thanks, -Randy ----- On Apr 8, 2015, at 3:43 PM, Furst, John-Nicholas jofurst at akamai.com wrote: > If you can wait, you will see the market flooded with 32x100G with the > ability to down-clock to 40g / breakout to 4x10g in the Q3/Q4 timeframe ;) > > > John-Nicholas Furst > Hardware Engineer > > > Office: +1.617.274.7212 > Akamai Technologies > 150 Broadway > Cambridge, MA 02142 > > > > > On 4/8/15, 3:37 PM, "Hockett, Roy" wrote: > >>I did see these switches at SC14. >> >>http://www.corsa.com/products/dp6440/ >> >>Thanks, >>-Roy Hockett >> >>Network Architect, >>ITS Communications Systems and Data Centers >>University of Michigan >>Tel: (734) 763-7325 >>Fax: (734) 615-1727 >>email: royboy at umich.edu >> >>On Apr 8, 2015, at 3:01 PM, Piotr wrote: >> >>> Hi, >>> >>> There is something like this on market ? Looking for standalone switch, >>>1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. >>> >>> regards, >>> Peter From md at bts.sk Wed Apr 8 20:54:00 2015 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Wed, 8 Apr 2015 22:54:00 +0200 Subject: 100Gb/s TOR switch In-Reply-To: <55257B27.4090300@interia.pl> References: <55257B27.4090300@interia.pl> Message-ID: <20150408204934.M93646@bts.sk> Wait for switches with BCM Tomahawk ASICs. They'll support exactly what you're looking for. M. On Wed, 08 Apr 2015 21:01:59 +0200, Piotr wrote > Hi, > > There is something like this on market ? Looking for standalone switch, > 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > regards, > Peter From morrowc.lists at gmail.com Wed Apr 8 20:55:00 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Apr 2015 16:55:00 -0400 Subject: Consumer products with baked-in VLAN tagging In-Reply-To: <9B42514B-1B62-4E31-BBA5-0DD1817229A8@seastrom.com> References: <133C37AE-4C25-4004-B2B2-DF3E068836E6@seastrom.com> <552115A7.9060508@foobar.org> <9B42514B-1B62-4E31-BBA5-0DD1817229A8@seastrom.com> Message-ID: On Wed, Apr 8, 2015 at 4:21 PM, Robert Seastrom wrote: > I'd really like to try these native IPv6 tests with my Verizon FIOS at home, but I think I already know the outcome... you are cracking me up. srsly. v6 on fios? that'll be the day. From dave.taht at gmail.com Wed Apr 8 21:19:11 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 8 Apr 2015 14:19:11 -0700 Subject: Consumer products with baked-in VLAN tagging In-Reply-To: <9B42514B-1B62-4E31-BBA5-0DD1817229A8@seastrom.com> References: <133C37AE-4C25-4004-B2B2-DF3E068836E6@seastrom.com> <552115A7.9060508@foobar.org> <9B42514B-1B62-4E31-BBA5-0DD1817229A8@seastrom.com> Message-ID: On Wed, Apr 8, 2015 at 1:21 PM, Robert Seastrom wrote: > > On Apr 8, 2015, at 1:58 PM, Dave Taht wrote: > >> I do wish they had bufferbloat-fighting queue managment on the ISP >> side, it is otherwise >> pretty good hardware. Again, I LOVE the apple gear - with stuart cheshire the godfather of the bufferbloat movement I would have expected apple to use these new algos long ago. They have sufficient infrastructure to do a better UI and distributed internet test infrastructure than anyone except google. I suck at UIs. Apples are great. They could fix bufferbloat on all their edge hardware in a matter of days. >As you're well aware since your name is in the acknowledgements, there's been some effort in this direction at CL. And sometimes I wish it wasn't. > If the problem gets solved in the CMTS and the CM, what the router does is kind of beside the point Sore points here, sorry for the noise on your thread. Been at this for 4.5 years now. Comcast, closer to 7. I am getting older, waiting. A) I have seen no public sign of progress from the CMTS makers that they are implementing any fixes. The only public sign of a fix came from ARRIS´s CTO 2 years back, and they got a nice improvement (4 way set associative hashing) in to SFQ but got their AQM horribly wrong. http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Presentation.pdf http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf I would certainly like it if the CMTS makers made a public announcement as to their plans and schedules for addressing bufferbloat on their side. After fixing the uplinks with a fq+aqm, the downlinks also tend to be seriously overbuffered, and any sufficiently long download (one just slightly longer than speedtest!) can trigger unacceptable latency. If their fixes require new hardware it will be a decade before we see them in the field. Thus - it seems better to continue fixing bloat on users equipment, and not waiting for them and their ISPs downstream to get off their duffs. (and multiple cable ISPs are desperate to try anything! anything! that will get bufferbloat off there list of problems especially for their business customers) Someone here feel free to bug Arris, Cisco, and casa-systems as to their CMTS update plans and schedule. B) sfq_codel was the algorithm that won the benchmarks before the numbers got extensively jiggled to favor docsis-pie. The test results were ultimately gamed, the sfq_codel implementation de-optimized ridiculously, and the tests absurdly weighted, to make the pie algorithm come out (barely) on top, in simulation. I have tried not to be too publicly bitter about this. Follow up tests using the algorithm in the real world shows it performing worse on a wider variety of workloads than fq_codel. I STILL support docsis-pie! as it is vastly better than what exists today, but have taken refuge in the fact that the docsis 3.1 CM specification also allows for better fq/aqm technologies to be in the box. C) Since the docsis-3.1 evaluations, of course, fq_codel has swept the aftermarket firmware "market", is now the default qdisc in fedora 22, arch and other linuxes, shipped in ubnt´s edgerouters, and in vyos, part of click, and available across the board in all linux distributions... and a derivative (sch_fq) serves up over 25% of the internet traffic in the world... ... and there is not one single sign of a pie deployment in the real world. I look forward, very much, to my first docsis 3.1 modem to play with... and I do hope some CM maker pays attention to the alternate AQM portion of the DOCSIS 3.1 specification, some CMTS maker fixes their gear where I live, and I can quit this task and go back to making spacecraft. But, until then... We hack. Upcoming is a refinement of fq_codel, now under test, which I hope we will also get into BSD and things like pfsense later this year. Let me know offlist if you are interested. In this chart I included current docsis 3.0 behavior here (and you can´t take the extra bandwidth in the default as real, it is set to native for that portion of the graph, I do have emulated results to show around - but you can take the latency as real!) : http://snapon.lab.bufferbloat.net/~d/cake3-fixed/baseline.png Cake works to manage inbound rates at 115Mbit/12Mbit (a now common cable rate) on cheap hardware, so anyone that wants to, can fix their network for themselves on their own gateways and firewalls. We hope to shave more cpu off of it as we finalize the algorithm. I can´t wait til CMs and CMTSes showed up. :) Aside from the huge induced latency problems, I honestly quite like cable internet, and the ipv6 stuff - aside from being dynamically renumbered at the drop of a hat - is pretty good also. I can´t wait til I can buy a static /48. > (unless we've progressed to wanting to do it on the wireless side too). Yes! we have progressed to that side. Our datasets (mlabs, others) show that once downlink bandwidth cracks 35Mbit the bottlenecks and latencies move to the wifi. Which is often horrible at even lower rates. That project is called make-wifi-fast, which is documented elsewhere. Fixes are starting to land, like "minstrel-blues" - somehow wifi has to scale to the increased densitity of 10 billion more devices in the next 5 years. >> Do they also supply that vlan to the ethernet? > > You mean to the southbound ethernet when running as a router instead of to the northbound ethernet while running as a bridge? No idea. That's not my normal use case. With multiple APS routing guest to guest over ethernet makes sense on the VLAN also. > >> How is their ipv6 with comcast? > > Beats me. No Comcast handy to test with. > > I *can* tell you that a freshly factory reset Airport Express 802.11n (2nd Generation) aka A1392 - the currently for sale $99 one - does pretty much exactly what you would hope when plugged into a freshly rebooted cablemodem on Another Pretty Darned Big MSO. That is to say, it gets a PD /64 and you're off to the races with native IPv6 on the wireless side. No warranties expressed or implied, but it seems to do what it says on the tin. I hope to be able get the /60 often distributed (comcast does /60s and I think /56s now) with an apple device also. I will check. Thx for the update, as you noted the 3rd generation was hopeless here. > > A similar test with a freshly factory reset Airport Extreme 802.11n (3rd Generation) aka A1301 is disappointing; default configuration is IPv6 link local only and although there is a knob to put it into "native/automatic" IPv6 configuration it doesn't work as advertised. But hey, it was discontinued five and a half years ago at this point so what do you want? I figured that a test with an even older example I have sitting around in the junk box (A1143) would be similarly unsatisfying. > > I'd really like to try these native IPv6 tests with my Verizon FIOS at home, but I think I already know the outcome... I know people that reliably use hurricane day in and day out to get ipv6 tunneled over fios. Static ipv6 tunnels are so much easier than dynamic ipv6 native. > -r > > [1] The only place where pie won was with insane amounts of bittorrent, and on vpn access, on benchmarks that were unrealisticly emulating behaviors of both. Other benchmarks - gaming and web access, and other typical use cases, sfq_codel smoked it. and fq_codel is better than sfq_codel. -- Dave Täht We CAN make better hardware, ourselves, beat bufferbloat, and take back control of the edge of the internet! If we work together, on making it: https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking From youssef at 720.fr Wed Apr 8 21:34:12 2015 From: youssef at 720.fr (Youssef Bengelloun-Zahr) Date: Wed, 8 Apr 2015 23:34:12 +0200 Subject: 100Gb/s TOR switch In-Reply-To: <55257B27.4090300@interia.pl> References: <55257B27.4090300@interia.pl> Message-ID: <7C48B122-47A2-41F1-A15D-506AACAEF0A1@720.fr> Hello Piotr, You can always take a look at : - Arista : http://www.arista.com/en/products/7280e-series - Brocade : http://www.brocade.com/products/all/switches/product-details/vdx-6940-switch/index.page HTH. BR. > Le 8 avr. 2015 à 21:01, Piotr a écrit : > > Hi, > > There is something like this on market ? Looking for standalone switch, 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > regards, > Peter From drohan at gmail.com Wed Apr 8 22:46:40 2015 From: drohan at gmail.com (Daniel Rohan) Date: Wed, 8 Apr 2015 15:46:40 -0700 Subject: Multi-gigabit edge devices as CPE Message-ID: I work at a state REN and we are seeking a lead for a new edge device for on prem deployment at customer sites. We currently deploy two classes of routers-- a high end and a low end. Both the high end and the low end use some of the standard edge features: MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these devices to the customers that need them. We recently finished a new ethernet procurement and have a large number of sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our currently deployed low-end router can't handle these speeds and we can't afford to place our high end router at 200+ sites. So, we're looking for a middle tier router to deploy. Something with 2+ SFP+ ports, software that can handle the aforementioned features, and something with an API that we can leverage for programmatic management. So far we've not found anything that checks all the boxes. Layer 3 switches seem like obvious choices, but lack some of the features and RIB/FIB we need at the edge. Other devices like the Juniper MX5/10 certainly meet the requirements, but are priced way beyond what we can afford. Any suggestions for devices we might have overlooked? Preferably in the less than 10K per unit price point. If such a magical device exists. -Dan From jackson.tim at gmail.com Wed Apr 8 23:18:40 2015 From: jackson.tim at gmail.com (Tim Jackson) Date: Wed, 8 Apr 2015 16:18:40 -0700 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: Message-ID: Cisco ASR902 or Juniper ACX.. On Apr 8, 2015 3:48 PM, "Daniel Rohan" wrote: > I work at a state REN and we are seeking a lead for a new edge device for > on prem deployment at customer sites. > > We currently deploy two classes of routers-- a high end and a low end. Both > the high end and the low end use some of the standard edge features: > MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these > devices to the customers that need them. > > We recently finished a new ethernet procurement and have a large number of > sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our > currently deployed low-end router can't handle these speeds and we can't > afford to place our high end router at 200+ sites. > > So, we're looking for a middle tier router to deploy. Something with 2+ > SFP+ ports, software that can handle the aforementioned features, and > something with an API that we can leverage for programmatic management. > > So far we've not found anything that checks all the boxes. Layer 3 switches > seem like obvious choices, but lack some of the features and RIB/FIB we > need at the edge. Other devices like the Juniper MX5/10 certainly meet the > requirements, but are priced way beyond what we can afford. > > Any suggestions for devices we might have overlooked? Preferably in the > less than 10K per unit price point. If such a magical device exists. > > -Dan > From jackson.tim at gmail.com Wed Apr 8 23:19:13 2015 From: jackson.tim at gmail.com (Tim Jackson) Date: Wed, 8 Apr 2015 16:19:13 -0700 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: Message-ID: Woops, missed the full tables requirement there.. Never mind. On Apr 8, 2015 4:18 PM, "Tim Jackson" wrote: > Cisco ASR902 or Juniper ACX.. > On Apr 8, 2015 3:48 PM, "Daniel Rohan" wrote: > >> I work at a state REN and we are seeking a lead for a new edge device for >> on prem deployment at customer sites. >> >> We currently deploy two classes of routers-- a high end and a low end. >> Both >> the high end and the low end use some of the standard edge features: >> MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these >> devices to the customers that need them. >> >> We recently finished a new ethernet procurement and have a large number of >> sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our >> currently deployed low-end router can't handle these speeds and we can't >> afford to place our high end router at 200+ sites. >> >> So, we're looking for a middle tier router to deploy. Something with 2+ >> SFP+ ports, software that can handle the aforementioned features, and >> something with an API that we can leverage for programmatic management. >> >> So far we've not found anything that checks all the boxes. Layer 3 >> switches >> seem like obvious choices, but lack some of the features and RIB/FIB we >> need at the edge. Other devices like the Juniper MX5/10 certainly meet the >> requirements, but are priced way beyond what we can afford. >> >> Any suggestions for devices we might have overlooked? Preferably in the >> less than 10K per unit price point. If such a magical device exists. >> >> -Dan >> > From hmcglinn at gmail.com Wed Apr 8 23:26:00 2015 From: hmcglinn at gmail.com (Hamish McGlinn) Date: Thu, 9 Apr 2015 11:26:00 +1200 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: Message-ID: Is it a necessity to terminate the layer 3 at the edge? You could get a 10Gbps switch and move it all back to a central location where you have your high end routers. It would then be terminated as a VLAN and be a router on a stick kind of topology. Could be a cheaper way to do it without taking MPLS all the way out to the edge. As Tim said above, I too was thinking about the Juniper ACX. The 5048/5096 model could suit your needs. They are primarily designed as layer 1(TDM)/2 backhaul devices and i'm not sure they can do a full table. They do have full JunOS MPLS features. Could be a way to use MPLS-TE to move the layer 2 back to a core location and terminate later 3 there. Would give you some flexibility over just doing ethernet stuff as I mentioned in the first paragraph. Hamish On Thu, Apr 9, 2015 at 10:46 AM, Daniel Rohan wrote: > I work at a state REN and we are seeking a lead for a new edge device for > on prem deployment at customer sites. > > We currently deploy two classes of routers-- a high end and a low end. Both > the high end and the low end use some of the standard edge features: > MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these > devices to the customers that need them. > > We recently finished a new ethernet procurement and have a large number of > sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our > currently deployed low-end router can't handle these speeds and we can't > afford to place our high end router at 200+ sites. > > So, we're looking for a middle tier router to deploy. Something with 2+ > SFP+ ports, software that can handle the aforementioned features, and > something with an API that we can leverage for programmatic management. > > So far we've not found anything that checks all the boxes. Layer 3 switches > seem like obvious choices, but lack some of the features and RIB/FIB we > need at the edge. Other devices like the Juniper MX5/10 certainly meet the > requirements, but are priced way beyond what we can afford. > > Any suggestions for devices we might have overlooked? Preferably in the > less than 10K per unit price point. If such a magical device exists. > > -Dan > From me at geordish.org Wed Apr 8 23:52:42 2015 From: me at geordish.org (Dave Bell) Date: Thu, 9 Apr 2015 00:52:42 +0100 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: Message-ID: Mikrotik? I believe they support all these features other than maybe flowspec, and you can get a box with a 10G SFP+ port for around $500. On 8 April 2015 at 23:46, Daniel Rohan wrote: > I work at a state REN and we are seeking a lead for a new edge device for > on prem deployment at customer sites. > > We currently deploy two classes of routers-- a high end and a low end. Both > the high end and the low end use some of the standard edge features: > MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these > devices to the customers that need them. > > We recently finished a new ethernet procurement and have a large number of > sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our > currently deployed low-end router can't handle these speeds and we can't > afford to place our high end router at 200+ sites. > > So, we're looking for a middle tier router to deploy. Something with 2+ > SFP+ ports, software that can handle the aforementioned features, and > something with an API that we can leverage for programmatic management. > > So far we've not found anything that checks all the boxes. Layer 3 switches > seem like obvious choices, but lack some of the features and RIB/FIB we > need at the edge. Other devices like the Juniper MX5/10 certainly meet the > requirements, but are priced way beyond what we can afford. > > Any suggestions for devices we might have overlooked? Preferably in the > less than 10K per unit price point. If such a magical device exists. > > -Dan From faisal at snappytelecom.net Thu Apr 9 00:14:33 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 9 Apr 2015 00:14:33 +0000 (GMT) Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: Message-ID: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> Mikrotik for OS, and Hardware choice would be to use an X86 appliance (Lanner Electronics, Axiomtek etc) You should be able to get a cost effective box that will meet your performance requirements. As to feature set, while most of them are their you should do some testing to see if feature set meets your requirements. Most folks often forget that Mikrotik is OS and they also make Hardware (a variety of sizes for a variety of needs), and the OS can be deployed on standard or custom hardware server or appliances. You can always go the 'Custom' Linux Route, using x86 boxes with your own distro, too bad that Vyatta OS took a different route under Brocade.. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Daniel Rohan" > To: "NANOG" > Sent: Wednesday, April 8, 2015 6:46:40 PM > Subject: Multi-gigabit edge devices as CPE > > I work at a state REN and we are seeking a lead for a new edge device for > on prem deployment at customer sites. > > We currently deploy two classes of routers-- a high end and a low end. Both > the high end and the low end use some of the standard edge features: > MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these > devices to the customers that need them. > > We recently finished a new ethernet procurement and have a large number of > sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our > currently deployed low-end router can't handle these speeds and we can't > afford to place our high end router at 200+ sites. > > So, we're looking for a middle tier router to deploy. Something with 2+ > SFP+ ports, software that can handle the aforementioned features, and > something with an API that we can leverage for programmatic management. > > So far we've not found anything that checks all the boxes. Layer 3 switches > seem like obvious choices, but lack some of the features and RIB/FIB we > need at the edge. Other devices like the Juniper MX5/10 certainly meet the > requirements, but are priced way beyond what we can afford. > > Any suggestions for devices we might have overlooked? Preferably in the > less than 10K per unit price point. If such a magical device exists. > > -Dan > From Bob.Watson at wwt.com Thu Apr 9 01:01:52 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Thu, 9 Apr 2015 01:01:52 +0000 Subject: Multi-gigabit edge devices as CPE In-Reply-To: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> References: , <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> Message-ID: <25140EAF-A075-4A51-A4CF-D826715513F9@wwt.com> Dan, The new asr920 by cisco would fit 4x10g SFP+ and 24 ports SFP or copper 1g line rate about 6 k list without license . You can leverage netconf yang model as its cisco edge or other flavor choice You can unicast if you want more data as we've done EFI and evaluated them in our labs Bob Watson > On Apr 8, 2015, at 7:15 PM, Faisal Imtiaz wrote: > > Mikrotik for OS, and Hardware choice would be to use an X86 appliance (Lanner Electronics, Axiomtek etc) > You should be able to get a cost effective box that will meet your performance requirements. > As to feature set, while most of them are their you should do some testing to see if feature set meets your requirements. > > Most folks often forget that Mikrotik is OS and they also make Hardware (a variety of sizes for a variety of needs), and the OS can be deployed on standard or custom hardware server or appliances. > > You can always go the 'Custom' Linux Route, using x86 boxes with your own distro, too bad that Vyatta OS took a different route under Brocade.. > > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- >> From: "Daniel Rohan" >> To: "NANOG" >> Sent: Wednesday, April 8, 2015 6:46:40 PM >> Subject: Multi-gigabit edge devices as CPE >> >> I work at a state REN and we are seeking a lead for a new edge device for >> on prem deployment at customer sites. >> >> We currently deploy two classes of routers-- a high end and a low end. Both >> the high end and the low end use some of the standard edge features: >> MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these >> devices to the customers that need them. >> >> We recently finished a new ethernet procurement and have a large number of >> sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our >> currently deployed low-end router can't handle these speeds and we can't >> afford to place our high end router at 200+ sites. >> >> So, we're looking for a middle tier router to deploy. Something with 2+ >> SFP+ ports, software that can handle the aforementioned features, and >> something with an API that we can leverage for programmatic management. >> >> So far we've not found anything that checks all the boxes. Layer 3 switches >> seem like obvious choices, but lack some of the features and RIB/FIB we >> need at the edge. Other devices like the Juniper MX5/10 certainly meet the >> requirements, but are priced way beyond what we can afford. >> >> Any suggestions for devices we might have overlooked? Preferably in the >> less than 10K per unit price point. If such a magical device exists. >> >> -Dan >> From raphael.timothy at gmail.com Thu Apr 9 01:11:11 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 9 Apr 2015 09:11:11 +0800 Subject: Multi-gigabit edge devices as CPE In-Reply-To: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> Message-ID: VyOS is a community fork of Vyatta and is still being developed very actively and it pushing ahead with many new features! It's pretty stable too imo. http://vyos.net/wiki/Main_Page Regards, Tim Raphael > On 9 Apr 2015, at 8:14 am, Faisal Imtiaz wrote: > > Mikrotik for OS, and Hardware choice would be to use an X86 appliance (Lanner Electronics, Axiomtek etc) > You should be able to get a cost effective box that will meet your performance requirements. > As to feature set, while most of them are their you should do some testing to see if feature set meets your requirements. > > Most folks often forget that Mikrotik is OS and they also make Hardware (a variety of sizes for a variety of needs), and the OS can be deployed on standard or custom hardware server or appliances. > > You can always go the 'Custom' Linux Route, using x86 boxes with your own distro, too bad that Vyatta OS took a different route under Brocade.. > > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- >> From: "Daniel Rohan" >> To: "NANOG" >> Sent: Wednesday, April 8, 2015 6:46:40 PM >> Subject: Multi-gigabit edge devices as CPE >> >> I work at a state REN and we are seeking a lead for a new edge device for >> on prem deployment at customer sites. >> >> We currently deploy two classes of routers-- a high end and a low end. Both >> the high end and the low end use some of the standard edge features: >> MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these >> devices to the customers that need them. >> >> We recently finished a new ethernet procurement and have a large number of >> sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our >> currently deployed low-end router can't handle these speeds and we can't >> afford to place our high end router at 200+ sites. >> >> So, we're looking for a middle tier router to deploy. Something with 2+ >> SFP+ ports, software that can handle the aforementioned features, and >> something with an API that we can leverage for programmatic management. >> >> So far we've not found anything that checks all the boxes. Layer 3 switches >> seem like obvious choices, but lack some of the features and RIB/FIB we >> need at the edge. Other devices like the Juniper MX5/10 certainly meet the >> requirements, but are priced way beyond what we can afford. >> >> Any suggestions for devices we might have overlooked? Preferably in the >> less than 10K per unit price point. If such a magical device exists. >> >> -Dan >> From josh at spitwspots.com Thu Apr 9 01:14:56 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Wed, 08 Apr 2015 17:14:56 -0800 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> Message-ID: <5525D290.1040506@spitwspots.com> No MPLS though, if that is a requirement. On 04/08/2015 05:11 PM, Tim Raphael wrote: > VyOS is a community fork of Vyatta and is still being developed very actively and it pushing ahead with many new features! It's pretty stable too imo. > > http://vyos.net/wiki/Main_Page > > Regards, > > Tim Raphael > >> On 9 Apr 2015, at 8:14 am, Faisal Imtiaz wrote: >> >> Mikrotik for OS, and Hardware choice would be to use an X86 appliance (Lanner Electronics, Axiomtek etc) >> You should be able to get a cost effective box that will meet your performance requirements. >> As to feature set, while most of them are their you should do some testing to see if feature set meets your requirements. >> >> Most folks often forget that Mikrotik is OS and they also make Hardware (a variety of sizes for a variety of needs), and the OS can be deployed on standard or custom hardware server or appliances. >> >> You can always go the 'Custom' Linux Route, using x86 boxes with your own distro, too bad that Vyatta OS took a different route under Brocade.. >> >> >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> >> ----- Original Message ----- >>> From: "Daniel Rohan" >>> To: "NANOG" >>> Sent: Wednesday, April 8, 2015 6:46:40 PM >>> Subject: Multi-gigabit edge devices as CPE >>> >>> I work at a state REN and we are seeking a lead for a new edge device for >>> on prem deployment at customer sites. >>> >>> We currently deploy two classes of routers-- a high end and a low end. Both >>> the high end and the low end use some of the standard edge features: >>> MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these >>> devices to the customers that need them. >>> >>> We recently finished a new ethernet procurement and have a large number of >>> sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our >>> currently deployed low-end router can't handle these speeds and we can't >>> afford to place our high end router at 200+ sites. >>> >>> So, we're looking for a middle tier router to deploy. Something with 2+ >>> SFP+ ports, software that can handle the aforementioned features, and >>> something with an API that we can leverage for programmatic management. >>> >>> So far we've not found anything that checks all the boxes. Layer 3 switches >>> seem like obvious choices, but lack some of the features and RIB/FIB we >>> need at the edge. Other devices like the Juniper MX5/10 certainly meet the >>> requirements, but are priced way beyond what we can afford. >>> >>> Any suggestions for devices we might have overlooked? Preferably in the >>> less than 10K per unit price point. If such a magical device exists. >>> >>> -Dan >>> From raphael.timothy at gmail.com Thu Apr 9 01:36:33 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 9 Apr 2015 09:36:33 +0800 Subject: Multi-gigabit edge devices as CPE In-Reply-To: <5525D290.1040506@spitwspots.com> References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> Message-ID: Correct. But hopefully not far off now that there are x86 packages for simple MPLS operations. With a bit of luck an RSVP or LDP implementation isn't far behind. Regards, Tim Raphael > On 9 Apr 2015, at 9:14 am, Josh Reynolds wrote: > > No MPLS though, if that is a requirement. > >> On 04/08/2015 05:11 PM, Tim Raphael wrote: >> VyOS is a community fork of Vyatta and is still being developed very actively and it pushing ahead with many new features! It's pretty stable too imo. >> >> http://vyos.net/wiki/Main_Page >> >> Regards, >> >> Tim Raphael >> >>> On 9 Apr 2015, at 8:14 am, Faisal Imtiaz wrote: >>> >>> Mikrotik for OS, and Hardware choice would be to use an X86 appliance (Lanner Electronics, Axiomtek etc) >>> You should be able to get a cost effective box that will meet your performance requirements. >>> As to feature set, while most of them are their you should do some testing to see if feature set meets your requirements. >>> >>> Most folks often forget that Mikrotik is OS and they also make Hardware (a variety of sizes for a variety of needs), and the OS can be deployed on standard or custom hardware server or appliances. >>> >>> You can always go the 'Custom' Linux Route, using x86 boxes with your own distro, too bad that Vyatta OS took a different route under Brocade.. >>> >>> >>> >>> Faisal Imtiaz >>> Snappy Internet & Telecom >>> >>> ----- Original Message ----- >>>> From: "Daniel Rohan" >>>> To: "NANOG" >>>> Sent: Wednesday, April 8, 2015 6:46:40 PM >>>> Subject: Multi-gigabit edge devices as CPE >>>> >>>> I work at a state REN and we are seeking a lead for a new edge device for >>>> on prem deployment at customer sites. >>>> >>>> We currently deploy two classes of routers-- a high end and a low end. Both >>>> the high end and the low end use some of the standard edge features: >>>> MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these >>>> devices to the customers that need them. >>>> >>>> We recently finished a new ethernet procurement and have a large number of >>>> sites (~200) moving from <1Gbps in bandwidth to 1-10Gb in bandwidth. Our >>>> currently deployed low-end router can't handle these speeds and we can't >>>> afford to place our high end router at 200+ sites. >>>> >>>> So, we're looking for a middle tier router to deploy. Something with 2+ >>>> SFP+ ports, software that can handle the aforementioned features, and >>>> something with an API that we can leverage for programmatic management. >>>> >>>> So far we've not found anything that checks all the boxes. Layer 3 switches >>>> seem like obvious choices, but lack some of the features and RIB/FIB we >>>> need at the edge. Other devices like the Juniper MX5/10 certainly meet the >>>> requirements, but are priced way beyond what we can afford. >>>> >>>> Any suggestions for devices we might have overlooked? Preferably in the >>>> less than 10K per unit price point. If such a magical device exists. >>>> >>>> -Dan > From colton.conor at gmail.com Thu Apr 9 01:57:01 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 8 Apr 2015 20:57:01 -0500 Subject: 100Gb/s TOR switch In-Reply-To: <20150408204934.M93646@bts.sk> References: <55257B27.4090300@interia.pl> <20150408204934.M93646@bts.sk> Message-ID: When will Tomahawk switches be available? On Wed, Apr 8, 2015 at 3:54 PM, Marian Ďurkovič wrote: > Wait for switches with BCM Tomahawk ASICs. > > They'll support exactly what you're looking for. > > M. > > > On Wed, 08 Apr 2015 21:01:59 +0200, Piotr wrote > > Hi, > > > > There is something like this on market ? Looking for standalone switch, > > 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > > > regards, > > Peter > > From colton.conor at gmail.com Thu Apr 9 01:57:36 2015 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 8 Apr 2015 20:57:36 -0500 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> Message-ID: >From which vendors? On Wed, Apr 8, 2015 at 2:43 PM, Furst, John-Nicholas wrote: > If you can wait, you will see the market flooded with 32x100G with the > ability to down-clock to 40g / breakout to 4x10g in the Q3/Q4 timeframe ;) > > > John-Nicholas Furst > Hardware Engineer > > > Office: +1.617.274.7212 > Akamai Technologies > 150 Broadway > Cambridge, MA 02142 > > > > > On 4/8/15, 3:37 PM, "Hockett, Roy" wrote: > > >I did see these switches at SC14. > > > >http://www.corsa.com/products/dp6440/ > > > >Thanks, > >-Roy Hockett > > > >Network Architect, > >ITS Communications Systems and Data Centers > >University of Michigan > >Tel: (734) 763-7325 > >Fax: (734) 615-1727 > >email: royboy at umich.edu > > > >On Apr 8, 2015, at 3:01 PM, Piotr wrote: > > > >> Hi, > >> > >> There is something like this on market ? Looking for standalone switch, > >>1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > >> > >> regards, > >> Peter > > > > From Bob.Watson at wwt.com Thu Apr 9 02:27:05 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Thu, 9 Apr 2015 02:27:05 +0000 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> , Message-ID: <6BF94F6F-128D-4A69-A0F8-2BD92DEF8FAB@wwt.com> If referring to cavium xpa's hitting the oem's lines, next year or so I'm guessing. Bob Watson > On Apr 8, 2015, at 9:01 PM, Colton Conor wrote: > > From which vendors? > > On Wed, Apr 8, 2015 at 2:43 PM, Furst, John-Nicholas > wrote: > >> If you can wait, you will see the market flooded with 32x100G with the >> ability to down-clock to 40g / breakout to 4x10g in the Q3/Q4 timeframe ;) >> >> >> John-Nicholas Furst >> Hardware Engineer >> >> >> Office: +1.617.274.7212 >> Akamai Technologies >> 150 Broadway >> Cambridge, MA 02142 >> >> >> >> >>> On 4/8/15, 3:37 PM, "Hockett, Roy" wrote: >>> >>> I did see these switches at SC14. >>> >>> http://www.corsa.com/products/dp6440/ >>> >>> Thanks, >>> -Roy Hockett >>> >>> Network Architect, >>> ITS Communications Systems and Data Centers >>> University of Michigan >>> Tel: (734) 763-7325 >>> Fax: (734) 615-1727 >>> email: royboy at umich.edu >>> >>>> On Apr 8, 2015, at 3:01 PM, Piotr wrote: >>>> >>>> Hi, >>>> >>>> There is something like this on market ? Looking for standalone switch, >>>> 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. >>>> >>>> regards, >>>> Peter >> >> From bedard.phil at gmail.com Thu Apr 9 02:31:58 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 8 Apr 2015 22:31:58 -0400 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> <20150408204934.M93646@bts.sk> Message-ID: <5525e4bc.843cb60a.7dec.ffff9266@mx.google.com> I think Brocade has one already announced. It might be based off the Trident2+ though, I can't remember. Either way, in 6 months everyone will have 1RU switches with 100G uplinks like they have 40G now. Phil -----Original Message----- From: "Colton Conor" Sent: ‎4/‎8/‎2015 9:58 PM To: "Marian Ďurkovič" Cc: "NANOG" Subject: Re: 100Gb/s TOR switch When will Tomahawk switches be available? On Wed, Apr 8, 2015 at 3:54 PM, Marian Ďurkovič wrote: > Wait for switches with BCM Tomahawk ASICs. > > They'll support exactly what you're looking for. > > M. > > > On Wed, 08 Apr 2015 21:01:59 +0200, Piotr wrote > > Hi, > > > > There is something like this on market ? Looking for standalone switch, > > 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > > > > regards, > > Peter > > From bedard.phil at gmail.com Thu Apr 9 02:33:06 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 8 Apr 2015 22:33:06 -0400 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> Message-ID: <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> Everyone. These should also support 25/50G Ethernet. Phil -----Original Message----- From: "Colton Conor" Sent: ‎4/‎8/‎2015 10:01 PM To: "Furst, John-Nicholas" Cc: "nanog at nanog.org" Subject: Re: 100Gb/s TOR switch >From which vendors? On Wed, Apr 8, 2015 at 2:43 PM, Furst, John-Nicholas wrote: > If you can wait, you will see the market flooded with 32x100G with the > ability to down-clock to 40g / breakout to 4x10g in the Q3/Q4 timeframe ;) > > > John-Nicholas Furst > Hardware Engineer > > > Office: +1.617.274.7212 > Akamai Technologies > 150 Broadway > Cambridge, MA 02142 > > > > > On 4/8/15, 3:37 PM, "Hockett, Roy" wrote: > > >I did see these switches at SC14. > > > >http://www.corsa.com/products/dp6440/ > > > >Thanks, > >-Roy Hockett > > > >Network Architect, > >ITS Communications Systems and Data Centers > >University of Michigan > >Tel: (734) 763-7325 > >Fax: (734) 615-1727 > >email: royboy at umich.edu > > > >On Apr 8, 2015, at 3:01 PM, Piotr wrote: > > > >> Hi, > >> > >> There is something like this on market ? Looking for standalone switch, > >>1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module. > >> > >> regards, > >> Peter > > > > From dave.taht at gmail.com Thu Apr 9 02:42:08 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 8 Apr 2015 19:42:08 -0700 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> Message-ID: On Wed, Apr 8, 2015 at 6:36 PM, Tim Raphael wrote: > Correct. But hopefully not far off now that there are x86 packages for simple MPLS operations. With a bit of luck an RSVP or LDP implementation isn't far behind. Just sitting around whining and waiting for someone else to do the job is nowhere near as effective as chipping in and helping... or funding the efforts that exist. -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU From raphael.timothy at gmail.com Thu Apr 9 09:37:49 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 9 Apr 2015 17:37:49 +0800 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> Message-ID: <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> I find this rather offensive as you clearly have no idea what I have contributed to the OSS community or more specifically to the VyOS project. Among working, studying a masters degree and a little sleep to keep me sane, I already do what I can. Tim > On 9 Apr 2015, at 10:42 am, Dave Taht wrote: > >> On Wed, Apr 8, 2015 at 6:36 PM, Tim Raphael wrote: >> Correct. But hopefully not far off now that there are x86 packages for simple MPLS operations. With a bit of luck an RSVP or LDP implementation isn't far behind. > > Just sitting around whining and waiting for someone else to do the job > is nowhere near as effective as chipping in and helping... or funding > the efforts that exist. > > -- > Dave Täht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU From sbrilus at blueyonder.co.uk Thu Apr 9 10:21:52 2015 From: sbrilus at blueyonder.co.uk (Simon Brilus) Date: Thu, 9 Apr 2015 11:21:52 +0100 Subject: Voip encryption Message-ID: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> Hi - I have a PCIDSs requirement to encrypt VoIP over a 3rd party VPLS network. Has anyone dealt with this. I'd really not use VPN's over the VPLS so am looking at hardware WAN encrypters. Any guidance appreciated. Thanks Simon From frederik at kriewitz.eu Thu Apr 9 11:24:28 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Thu, 9 Apr 2015 13:24:28 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: Message-ID: Thank you very much for all your responses. First of all, the problems we see are really RIB (Processor memory) and CPU related. The TCAM/FIB limits are properly configured. From the FIB capacity view they should last a couple of more years. Software routing doesn't cause the problem. The most extreme case of Cisco 6500/SUP720 abuse I'm aware of is a setup with 4 full table transit connections + 2 RR sessions + ~20 peerings, no downstreams. Besides the IPv4 and IPv6 peerings it's pretty much only handling a small amount of OSPF and MPLS (<5k prefixes ~500 routers). No netflow or any other memory hog. Under normal condition it's running at 20% CPU and 90% processor memory (1G/SUP720 XL). In case a session with a lot of prefixes (e.g. a transit) fails, it takes up to 5 minutes for the BGP Router process to recompute the RIB, etc.. During that time it's running at 100% CPU. Low priority processes are completely ignored (e.g. SNMP based monitoring stops working). Occasionally it even drops OSPF neighbours or other BGP sessions due to expired hold timers causing further havoc. I had a look at David Barroso's SDN Internet Router project. While it's definitely a very interesting project it focuses on FIB limitations, in our case the RIB is the problem. Using netflow and traffic stats as additional metric is something I'm missing from today's routers too (not to work around FIB limits but to allow more intelligent load balancing/avoid congested ports). Applying a /22 filter was suggested. In order to actually safe the RIB memory we would have to disable soft-reconfiguration on the corresponding sessions. I don't like that option for various reasons as it trades less memory usage for longer convergence times and significant bigger impacts on route map updates. Due to the IPv4 exhaustion we expect to see more small prefixes in the future which can't be aggregated (considering the AS path). Simply dropping them would result in less optimal routing. Having a hardware router with just a small subset of routes to handle most of the traffic and send remaining traffic via a default route to a software router with a full table is a different approach to FIB limits. It shares similar problems as mentioned in the original post (how to make two routers appear as one, ...). On the edge towards the end customers we already make heavy use of Linux routers based on standard servers. While we would love to replace all hardware routers with feature rich software routers we still consider them necessary towards the internet facing edge in order to allow us the mitigation certain (D)DoS attacks. Dropping entire ASs is not an option as already discussed here. Another suggestion was to use OpenFlow PacketIn/Out messages to inject/extract the BGP packets. That probably would be a nice way to do it but unfortunately legacy routers typically don't support OpenFlow. The Cisco 6500/SUP720 is no exception. I'll probably will setup a small test environment to see if this actually works as expected. Best Regards, Freddy From colton.conor at gmail.com Thu Apr 9 12:30:20 2015 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 9 Apr 2015 07:30:20 -0500 Subject: 100Gb/s TOR switch In-Reply-To: <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> References: <55257B27.4090300@interia.pl> <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> Message-ID: So are we expecting these new switches to be the same price or cheaper than the current 40G uplinks models? Do you think the vendors will heavily discount the switches with 10G user port and 40G uplinks? On Wed, Apr 8, 2015 at 9:33 PM, Phil Bedard wrote: > Everyone. These should also support 25/50G Ethernet. > > Phil > ------------------------------ > From: Colton Conor > Sent: ‎4/‎8/‎2015 10:01 PM > To: Furst, John-Nicholas > Cc: nanog at nanog.org > Subject: Re: 100Gb/s TOR switch > > From which vendors? > > On Wed, Apr 8, 2015 at 2:43 PM, Furst, John-Nicholas > wrote: > > > If you can wait, you will see the market flooded with 32x100G with the > > ability to down-clock to 40g / breakout to 4x10g in the Q3/Q4 timeframe > ;) > > > > > > John-Nicholas Furst > > Hardware Engineer > > > > > > Office: +1.617.274.7212 > > Akamai Technologies > > 150 Broadway > > Cambridge, MA 02142 > > > > > > > > > > On 4/8/15, 3:37 PM, "Hockett, Roy" wrote: > > > > >I did see these switches at SC14. > > > > > >http://www.corsa.com/products/dp6440/ > > > > > >Thanks, > > >-Roy Hockett > > > > > >Network Architect, > > >ITS Communications Systems and Data Centers > > >University of Michigan > > >Tel: (734) 763-7325 > > >Fax: (734) 615-1727 > > >email: royboy at umich.edu > > > > > >On Apr 8, 2015, at 3:01 PM, Piotr wrote: > > > > > >> Hi, > > >> > > >> There is something like this on market ? Looking for standalone > switch, > > >>1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a > module. > > >> > > >> regards, > > >> Peter > > > > > > > > From nick at foobar.org Thu Apr 9 12:54:49 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 09 Apr 2015 13:54:49 +0100 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> Message-ID: <55267699.3080004@foobar.org> On 09/04/2015 13:30, Colton Conor wrote: > So are we expecting these new switches to be the same price or cheaper than > the current 40G uplinks models? Do you think the vendors will heavily > discount the switches with 10G user port and 40G uplinks? like this? http://whiteboxswitch.com/products/edge-core-as5610-52x BCOM trident 2 chipset - 48x10G + 4x40G, $5095 for one-off purchases. Nick From lukasz at bromirski.net Thu Apr 9 12:56:36 2015 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Thu, 9 Apr 2015 14:56:36 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: References: Message-ID: Hi Frederik, > On 09 Apr 2015, at 13:24, Frederik Kriewitz wrote: > > Thank you very much for all your responses. > > First of all, the problems we see are really RIB (Processor memory) > and CPU related. > The TCAM/FIB limits are properly configured. From the FIB capacity > view they should last a couple of more years. Software routing doesn't > cause the problem. > The most extreme case of Cisco 6500/SUP720 abuse I'm aware of is a > setup with 4 full table transit connections + 2 RR sessions + ~20 > peerings, no downstreams. Besides the IPv4 and IPv6 peerings it's > pretty much only handling a small amount of OSPF and MPLS (<5k > prefixes ~500 routers). No netflow or any other memory hog. Under > normal condition it's running at 20% CPU and 90% processor memory > (1G/SUP720 XL). The main limit here apart from the rather slow CPU for RP is the amount of memory you can have. I’d setup a CSR1000v as RR and offload the 6500 from the control-plane completely. It’s nice box to do very fast hardware forwarding as long as the FIB fits in the TCAMs, which it seems it does in your scenario. > In case a session with a lot of prefixes (e.g. a transit) fails, it > takes up to 5 minutes for the BGP Router process to recompute the RIB, > etc.. During that time it's running at 100% CPU. Low priority > processes are completely ignored (e.g. SNMP based monitoring stops > working). Occasionally it even drops OSPF neighbours or other BGP > sessions due to expired hold timers causing further havoc. You can tune this with process time tweaks. > Applying a /22 filter was suggested. In order to actually safe the RIB > memory we would have to disable soft-reconfiguration on the > corresponding sessions. > I don't like that option for various reasons as it trades less memory > usage for longer convergence times and significant bigger impacts on > route map updates. > Due to the IPv4 exhaustion we expect to see more small prefixes in the > future which can't be aggregated (considering the AS path). Simply > dropping them would result in less optimal routing. If you have to filter somewhere on something, I’d rather try to filter by AS_PATH (neighbors, etc) than prefix lengths. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From eugen at imacandi.net Thu Apr 9 13:36:18 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 9 Apr 2015 16:36:18 +0300 Subject: Voip encryption In-Reply-To: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> References: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> Message-ID: On Thu, Apr 9, 2015 at 1:21 PM, Simon Brilus wrote: > Hi - I have a PCIDSs requirement to encrypt VoIP over a 3rd party VPLS > network. Has anyone dealt with this. I'd really not use VPN's over the VPLS > so am looking at hardware WAN encrypters. > > SafeNet and Thales sell L2 WAN encryptors for sure. There is AEP and SINA which also do hardware WAN encryption, but I do not know if they do Layer2. Eugeniu From dave.taht at gmail.com Thu Apr 9 14:18:56 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 9 Apr 2015 07:18:56 -0700 Subject: Multi-gigabit edge devices as CPE In-Reply-To: <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: On Thu, Apr 9, 2015 at 2:37 AM, Tim Raphael wrote: > I find this rather offensive as you clearly have no idea what I have contributed to the OSS community or more specifically to the VyOS project. > > Among working, studying a masters degree and a little sleep to keep me sane, I already do what I can. My sincere apologies. At the time, that kickstarter was failing, and I was mindblown that nobody had seen the potential of it, and I had spent 3 days, trying to convince more people to throw in, as I had already thrown in all I could. My comment was directed far more at the universe than yourself and was more in the context of my prior bufferbloat-related rant earlier in the day, which I have spent 4 years on, mostly full time, and mostly unpaid. I am still sad that nobody threw in for that get one give one program (who pays for the software engineers?), and that it took events like heartbleed to get the LF´s core infrastructure inititative funded, and, well, frankly, it is a long, long list of things that bug me that have accumulated... that I will try to keep off this list. > Tim > >> On 9 Apr 2015, at 10:42 am, Dave Taht wrote: >> >>> On Wed, Apr 8, 2015 at 6:36 PM, Tim Raphael wrote: >>> Correct. But hopefully not far off now that there are x86 packages for simple MPLS operations. With a bit of luck an RSVP or LDP implementation isn't far behind. So to return this to a more rational basis - why does an edge network need MPLS in the first place? -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU From raphael.timothy at gmail.com Thu Apr 9 14:25:01 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 9 Apr 2015 22:25:01 +0800 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: L3VPN hand off is the only thing I can think of from the top of my head. But then, there would be no need to have a full table unless you had customers requesting a full table. It sounds like the OP is looking for one device to do multiple roles where two/three different device types and/or sizes would fit better. > On 9 Apr 2015, at 10:18 pm, Dave Taht wrote: > > So to return this to a more rational basis - why does an edge network > need MPLS in the first place? From dave.taht at gmail.com Thu Apr 9 14:35:40 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 9 Apr 2015 07:35:40 -0700 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: On Thu, Apr 9, 2015 at 7:25 AM, Tim Raphael wrote: > L3VPN hand off is the only thing I can think of from the top of my head. But > then, there would be no need to have a full table unless you had customers > requesting a full table. Well my interpretation was that IPv4 address space had become so scarce that other methods were becoming more needed even on the high end edge networks. > > It sounds like the OP is looking for one device to do multiple roles where > two/three different device types and/or sizes would fit better. But that seems more plausible. > > > On 9 Apr 2015, at 10:18 pm, Dave Taht wrote: > > So to return this to a more rational basis - why does an edge network > need MPLS in the first place? > > -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/107942175615993706558/posts/N8mZ5F5iSPU From Bob.Watson at wwt.com Thu Apr 9 14:38:46 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Thu, 9 Apr 2015 14:38:46 +0000 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> , Message-ID: <376EC98E-3778-437C-93FF-663BC314C78D@wwt.com> I think e in ren is edu not edge L3vpn or L2vpn for pseudo back haul or l2 extensions State ren I assume to stand for regional education network so likely vrf would be public internet possibly Internet 2 , district traffic, maybe higher Ed access for night class and vice versa. One way to achieve 10g mpls plus full table and stay under 10k you may be better served to break out pre-agg role for mpls and private L3 hand off and for Internet peering step a hop back and peer at agg with a heavy duty juniper or cisco box over a l2vpn extension to the CE Sent from my iPad > On Apr 9, 2015, at 9:26 AM, Tim Raphael wrote: > > L3VPN hand off is the only thing I can think of from the top of my head. But then, there would be no need to have a full table unless you had customers requesting a full table. > > It sounds like the OP is looking for one device to do multiple roles where two/three different device types and/or sizes would fit better. > > >> On 9 Apr 2015, at 10:18 pm, Dave Taht wrote: >> >> So to return this to a more rational basis - why does an edge network >> need MPLS in the first place? > From drohan at gmail.com Thu Apr 9 14:40:48 2015 From: drohan at gmail.com (Daniel Rohan) Date: Thu, 9 Apr 2015 07:40:48 -0700 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: On Thu, Apr 9, 2015 at 7:25 AM, Tim Raphael wrote: > It sounds like the OP is looking for one device to do multiple roles where > two/three different device types and/or sizes would fit better. Yes, correct. And thanks for your work and suggestions. From drohan at gmail.com Thu Apr 9 14:42:41 2015 From: drohan at gmail.com (Daniel Rohan) Date: Thu, 9 Apr 2015 07:42:41 -0700 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: On Thu, Apr 9, 2015 at 7:25 AM, Tim Raphael wrote: > L3VPN hand off is the only thing I can think of from the top of my head. > But then, there would be no need to have a full table unless you had > customers requesting a full table. I have one customer who needs an L3VPN for some shared private routes along with a full table in inet.0. There are ways of accomplishing this creatively but I'm looking for devices that can handle these types of requests that permit us some level of sanity. From raphael.timothy at gmail.com Thu Apr 9 14:50:45 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 9 Apr 2015 22:50:45 +0800 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: You’ll be looking at a Juniper MX or a Cisco ASK9K I think. The MXs are targeted as being full-features edge routers. An MX5 will take a full feed just fine and do all the *VPN you want. If you’re talking about multiple full feeds then you’ll need a MX240 with one of the higher-power REs for a decent reconvergence time. > On 9 Apr 2015, at 10:42 pm, Daniel Rohan wrote: > > > On Thu, Apr 9, 2015 at 7:25 AM, Tim Raphael > wrote: > L3VPN hand off is the only thing I can think of from the top of my head. But then, there would be no need to have a full table unless you had customers requesting a full table. > > > I have one customer who needs an L3VPN for some shared private routes along with a full table in inet.0. There are ways of accomplishing this creatively but I'm looking for devices that can handle these types of requests that permit us some level of sanity. From joshbaird at gmail.com Thu Apr 9 14:56:10 2015 From: joshbaird at gmail.com (Josh Baird) Date: Thu, 9 Apr 2015 10:56:10 -0400 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: You could possibly look at rolling vMX (if it's even available yet) on x86 hardware. It's licensed by throughput and feature set. If you are doing L3VPN, I think you would need the advanced license. This may fit within your budget. On Thu, Apr 9, 2015 at 10:50 AM, Tim Raphael wrote: > You’ll be looking at a Juniper MX or a Cisco ASK9K I think. > > The MXs are targeted as being full-features edge routers. An MX5 will take > a full feed just fine and do all the *VPN you want. > If you’re talking about multiple full feeds then you’ll need a MX240 with > one of the higher-power REs for a decent reconvergence time. > > > > On 9 Apr 2015, at 10:42 pm, Daniel Rohan wrote: > > > > > > On Thu, Apr 9, 2015 at 7:25 AM, Tim Raphael > wrote: > > L3VPN hand off is the only thing I can think of from the top of my head. > But then, there would be no need to have a full table unless you had > customers requesting a full table. > > > > > > I have one customer who needs an L3VPN for some shared private routes > along with a full table in inet.0. There are ways of accomplishing this > creatively but I'm looking for devices that can handle these types of > requests that permit us some level of sanity. > > From morrowc.lists at gmail.com Thu Apr 9 15:04:06 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2015 11:04:06 -0400 Subject: Voip encryption In-Reply-To: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> References: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> Message-ID: On Thu, Apr 9, 2015 at 6:21 AM, Simon Brilus wrote: > Hi - I have a PCIDSs requirement to encrypt VoIP over a 3rd party VPLS > network. Has anyone dealt with this. I'd really not use VPN's over the VPLS > so am looking at hardware WAN encrypters. wait, you don't want to do some VPN thing over the VPLS network links, but you think that hardware wan encrypters are going to work on the VPLS links? Did you plan on installing one of these devices at the carrier facility? and at all the other possible hops along the way? or were you hoping that the encrypter would not muddle with the L2 payload, but leave the L2 headers intact? > Any guidance appreciated. From skhosla at neutraldata.com Thu Apr 9 15:31:29 2015 From: skhosla at neutraldata.com (Sameer Khosla) Date: Thu, 9 Apr 2015 15:31:29 +0000 Subject: Cisco/Level3 takedown Message-ID: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> Was just reading http://blogs.cisco.com/security/talos/sshpsychos then checking my routing tables. Looks like the two /23's they mention are now being advertised as /24's, and I'm also not sure why cisco published the ssh attack dictionary. It seems to me that this is something that if they want to do, they should be working with entire service provider community, not just one provider. Thanks Sameer Khosla Managing Director Neutral Data Centers Corp. Twitter: @skhoslaTO From timrutherford at c4.net Thu Apr 9 15:44:02 2015 From: timrutherford at c4.net (timrutherford at c4.net) Date: Thu, 9 Apr 2015 11:44:02 -0400 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <5525D290.1040506@spitwspots.com> <3DB10747-CFC8-4E58-A9A6-C30D59867356@gmail.com> Message-ID: <008101d072dc$00c00460$02400d20$@c4.net> I didn’t research the full feature list, but you might take a quick look at Mikrotik. www.mikrotik.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tim Raphael Sent: Thursday, April 9, 2015 10:51 AM To: Daniel Rohan Cc: nanog at nanog.org Subject: Re: Multi-gigabit edge devices as CPE You’ll be looking at a Juniper MX or a Cisco ASK9K I think. The MXs are targeted as being full-features edge routers. An MX5 will take a full feed just fine and do all the *VPN you want. If you’re talking about multiple full feeds then you’ll need a MX240 with one of the higher-power REs for a decent reconvergence time. > On 9 Apr 2015, at 10:42 pm, Daniel Rohan wrote: > > > On Thu, Apr 9, 2015 at 7:25 AM, Tim Raphael > wrote: > L3VPN hand off is the only thing I can think of from the top of my head. But then, there would be no need to have a full table unless you had customers requesting a full table. > > > I have one customer who needs an L3VPN for some shared private routes along with a full table in inet.0. There are ways of accomplishing this creatively but I'm looking for devices that can handle these types of requests that permit us some level of sanity. From morrowc.lists at gmail.com Thu Apr 9 15:47:36 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2015 11:47:36 -0400 Subject: Cisco/Level3 takedown In-Reply-To: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> Message-ID: On Thu, Apr 9, 2015 at 11:31 AM, Sameer Khosla wrote: > Was just reading http://blogs.cisco.com/security/talos/sshpsychos then checking my routing tables. > > Looks like the two /23's they mention are now being advertised as /24's, and I'm also not sure why cisco published the ssh attack dictionary. > > It seems to me that this is something that if they want to do, they should be working with entire service provider community, not just one provider. are you sure they aren't engaged with a wider SP community? (the dictionary seems relevant for: "Oh crap, my root account DOES have password123 as the password :(") From rvandolson at esri.com Thu Apr 9 15:50:45 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Thu, 9 Apr 2015 08:50:45 -0700 Subject: Voip encryption In-Reply-To: References: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> Message-ID: <20150409155045.GA18484@esri.com> On Thu, Apr 09, 2015 at 11:04:06AM -0400, Christopher Morrow wrote: > On Thu, Apr 9, 2015 at 6:21 AM, Simon Brilus wrote: > > Hi - I have a PCIDSs requirement to encrypt VoIP over a 3rd party VPLS > > network. Has anyone dealt with this. I'd really not use VPN's over the VPLS > > so am looking at hardware WAN encrypters. > > wait, you don't want to do some VPN thing over the VPLS network links, > but you think that hardware wan encrypters are going to work on the > VPLS links? Did you plan on installing one of these devices at the > carrier facility? and at all the other possible hops along the way? > > or were you hoping that the encrypter would not muddle with the L2 > payload, but leave the L2 headers intact? > > > Any guidance appreciated. > Lost the original post, but why not SIP+TLS & SRTP? Ray From blake at ispn.net Thu Apr 9 15:55:43 2015 From: blake at ispn.net (Blake Hudson) Date: Thu, 09 Apr 2015 10:55:43 -0500 Subject: Cisco/Level3 takedown In-Reply-To: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> Message-ID: <5526A0FF.8030603@ispn.net> Reading the article, I assumed that perhaps Level 3 was an upstream carrier, but RIPE stats shows that the covering prefix (103.41.120.0/22) is announced by AS63509, an Indonesian organization. It looks like they're fighting back by announcing their own /24 now. I love the AS's address: descr:Jl. Marcedes Bens No.258 descr:Gunung Putri, Bogor descr:Jawa Barat 16964 country:ID While a Level 3 /24 announcement will certainly have a world wide impact, I agree that it seems misguided when the originating AS can announce their own /24. It does make one wonder why Cisco or Level 3 is involved, why they feel they have the authority to hijack someone else's IP space, and why they didn't go through law enforcement. This is especially true for the second netblock (43.255.190.0/23), announced by a US company (AS26484). --Blake Sameer Khosla wrote on 4/9/2015 10:31 AM: > Was just reading http://blogs.cisco.com/security/talos/sshpsychos then checking my routing tables. > > Looks like the two /23's they mention are now being advertised as /24's, and I'm also not sure why cisco published the ssh attack dictionary. > > It seems to me that this is something that if they want to do, they should be working with entire service provider community, not just one provider. > > > Thanks > > Sameer Khosla > Managing Director > Neutral Data Centers Corp. > Twitter: @skhoslaTO > > From snoble at sonn.com Thu Apr 9 16:31:33 2015 From: snoble at sonn.com (Steve Noble) Date: Thu, 09 Apr 2015 09:31:33 -0700 Subject: Cisco/Level3 takedown In-Reply-To: <5526A0FF.8030603@ispn.net> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> Message-ID: <5526A965.5040106@sonn.com> I was wondering why a non-allocated AS was being allowed to announce the blocks but it appears that APNIC has revoked the 63854 ASN? http://wq.apnic.net/apnic-bin/whois.pl?searchtext=AS63854&object_type=aut-num Based on google's cache, it was still there late March. BGP routing table entry for 103.41.125.0/24, version 108425142 Paths: (1 available, best #1, table default) Not advertised to any peer 6939 4134 36678 26484 63854 Blake Hudson wrote: > > Reading the article, I assumed that perhaps Level 3 was an upstream > carrier, but RIPE stats shows that the covering prefix > (103.41.120.0/22) is announced by AS63509, an Indonesian organization. > It looks like they're fighting back by announcing their own /24 now. > > I love the AS's address: > descr:Jl. Marcedes Bens No.258 > descr:Gunung Putri, Bogor > descr:Jawa Barat 16964 > country:ID > > While a Level 3 /24 announcement will certainly have a world wide > impact, I agree that it seems misguided when the originating AS can > announce their own /24. It does make one wonder why Cisco or Level 3 > is involved, why they feel they have the authority to hijack someone > else's IP space, and why they didn't go through law enforcement. This > is especially true for the second netblock (43.255.190.0/23), > announced by a US company (AS26484). > > --Blake From bzs at world.std.com Thu Apr 9 17:32:49 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 9 Apr 2015 13:32:49 -0400 Subject: Multi-gigabit edge devices as CPE [TOPIC DRIFT!] In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> Message-ID: <21798.47041.94992.564368@world.std.com> On April 9, 2015 at 09:11 raphael.timothy at gmail.com (Tim Raphael) wrote: > VyOS is a community fork of Vyatta and is still being developed very actively and it pushing ahead with many new features! It's pretty stable too imo. > > http://vyos.net/wiki/Main_Page SPEAKING of OSS routers... Does anyone know of a single OSS project which supports the usual BGP etc kind of things (routing) AND virtual hosting, the terminology is muddled, but one IP in, chooses among one or more IPs for load-balancing (not to be confused with device load-balancing), fail-over, round-robin, other policies? The typical web farm kind of thing, but for other kinds of services also like mail, imap, etc. I know one can piece together more than one project but then one has to get them to play together and learn their quirks and so forth. For example I don't think any Mikrotik (ok not strictly OSS but they seem nice) supports the virtual host stuff unless I'm missing it. I have some very old Alteons that do the virtual host stuff well enough but they are very long in the tooth (no IPv6, BGP is so old it's useless to the point of scary, etc.) P.S. No particular need for fancy WAN interfaces, ethernet presentations are fine. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bblackford at gmail.com Thu Apr 9 18:09:59 2015 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 9 Apr 2015 11:09:59 -0700 Subject: G/L Coding for RIR resources Message-ID: Group. How do your respective bean counting teams code RIR resources, ASN's, Addr allocations, etc.? Software subscription? Licensing? Thank you -- Bill Blackford Logged into reality and abusing my sudo privileges..... From morrowc.lists at gmail.com Thu Apr 9 18:13:02 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2015 14:13:02 -0400 Subject: G/L Coding for RIR resources In-Reply-To: References: Message-ID: On Thu, Apr 9, 2015 at 2:09 PM, Bill Blackford wrote: > Group. How do your respective bean counting teams code RIR resources, > ASN's, Addr allocations, etc.? Software subscription? Licensing? honestly I bet in a lot of places: "Office Supplies" because: 1) no one's finance department accounts for this sort of expense request 2) it ends up on someone's 'corporate card' 3) this is all easier than explaning to 'finance' how an RIR works and why it's important to pay them this year, again... From randy at psg.com Thu Apr 9 18:16:14 2015 From: randy at psg.com (Randy Bush) Date: Fri, 10 Apr 2015 03:16:14 +0900 Subject: Cisco/Level3 takedown In-Reply-To: <5526A0FF.8030603@ispn.net> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> Message-ID: > It does make one wonder why Cisco or Level 3 is involved, why they > feel they have the authority to hijack someone else's IP space, and > why they didn't go through law enforcement. This is especially true > for the second netblock (43.255.190.0/23), announced by a US company > (AS26484). vigilantes always wear white hats. randy From mel at beckman.org Thu Apr 9 18:29:37 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 9 Apr 2015 18:29:37 +0000 Subject: Cisco/Level3 takedown In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net>, Message-ID: <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> Wrong. Batman, for example, wears a black hat. -mel via cell On Apr 9, 2015, at 11:17 AM, "Randy Bush" wrote: >> It does make one wonder why Cisco or Level 3 is involved, why they >> feel they have the authority to hijack someone else's IP space, and >> why they didn't go through law enforcement. This is especially true >> for the second netblock (43.255.190.0/23), announced by a US company >> (AS26484). > > vigilantes always wear white hats. > > randy From randy at psg.com Thu Apr 9 18:35:09 2015 From: randy at psg.com (Randy Bush) Date: Fri, 10 Apr 2015 03:35:09 +0900 Subject: Cisco/Level3 takedown In-Reply-To: <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> Message-ID: > Wrong. Batman, for example, wears a black hat. >> vigilantes always wear white hats. i stand corrected From deleskie at gmail.com Thu Apr 9 18:39:19 2015 From: deleskie at gmail.com (jim deleskie) Date: Thu, 9 Apr 2015 15:39:19 -0300 Subject: Cisco/Level3 takedown In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> Message-ID: Just to add to the noise.... I think batman wears a black mask/helmet, but I've never considered it a mask. I didn't look at the details on this, but did L3 sink the routes at their border or did they expressly announce the route to sink it? -jim On Thu, Apr 9, 2015 at 3:35 PM, Randy Bush wrote: > > Wrong. Batman, for example, wears a black hat. > >> vigilantes always wear white hats. > > i stand corrected > From baldur.norddahl at gmail.com Thu Apr 9 18:50:50 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Apr 2015 20:50:50 +0200 Subject: Multi-gigabit edge devices as CPE [TOPIC DRIFT!] In-Reply-To: <21798.47041.94992.564368@world.std.com> References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <21798.47041.94992.564368@world.std.com> Message-ID: You can do this for free with equal cost multi path routing. You announce the same IP from multiple servers with eg. OSPF. Den 09/04/2015 19.34 skrev "Barry Shein" : > > On April 9, 2015 at 09:11 raphael.timothy at gmail.com (Tim Raphael) wrote: > > VyOS is a community fork of Vyatta and is still being developed very > actively and it pushing ahead with many new features! It's pretty stable > too imo. > > > > http://vyos.net/wiki/Main_Page > > SPEAKING of OSS routers... > > Does anyone know of a single OSS project which supports the usual BGP > etc kind of things (routing) AND virtual hosting, the terminology is > muddled, but one IP in, chooses among one or more IPs for > load-balancing (not to be confused with device load-balancing), > fail-over, round-robin, other policies? The typical web farm kind of > thing, but for other kinds of services also like mail, imap, etc. > > I know one can piece together more than one project but then one has > to get them to play together and learn their quirks and so forth. For > example I don't think any Mikrotik (ok not strictly OSS but they seem > nice) supports the virtual host stuff unless I'm missing it. > > I have some very old Alteons that do the virtual host stuff well > enough but they are very long in the tooth (no IPv6, BGP is so old > it's useless to the point of scary, etc.) > > P.S. No particular need for fancy WAN interfaces, ethernet > presentations are fine. > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From jeffshultz at sctcweb.com Thu Apr 9 18:52:22 2015 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 09 Apr 2015 11:52:22 -0700 Subject: Cisco/Level3 takedown In-Reply-To: <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net>, <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> Message-ID: <5526CA66.3090505@wvi.com> I think that, properly, Batman wears a cowl, not a hat. On 4/9/2015 11:29 AM, Mel Beckman wrote: > Wrong. Batman, for example, wears a black hat. > > -mel via cell > From woody at pch.net Thu Apr 9 18:53:11 2015 From: woody at pch.net (Bill Woodcock) Date: Thu, 9 Apr 2015 11:53:11 -0700 Subject: Cisco/Level3 takedown In-Reply-To: <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <, <>> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> Message-ID: <6B66A5C8-CC05-441A-A47F-8D8A5DE086F0@pch.net> > On Apr 9, 2015, at 11:29 AM, Mel Beckman wrote: > > Wrong. Batman, for example, wears a black hat. Thank you, Mask Man. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From morrowc.lists at gmail.com Thu Apr 9 18:54:08 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2015 14:54:08 -0400 Subject: Cisco/Level3 takedown In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> Message-ID: folk are getting kinda bent out of shape about this, and about L3 doing 'something' but look at: what's 4134 doing there? This one as well: wowsa! howdy 4134, having fun there? On Thu, Apr 9, 2015 at 2:39 PM, jim deleskie wrote: > Just to add to the noise.... I think batman wears a black mask/helmet, but > I've never considered it a mask. I didn't look at the details on this, but > did L3 sink the routes at their border or did they expressly announce the > route to sink it? > > > -jim > > On Thu, Apr 9, 2015 at 3:35 PM, Randy Bush wrote: > >> > Wrong. Batman, for example, wears a black hat. >> >> vigilantes always wear white hats. >> >> i stand corrected >> From morrowc.lists at gmail.com Thu Apr 9 19:01:16 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2015 15:01:16 -0400 Subject: Cisco/Level3 takedown In-Reply-To: <5526CA66.3090505@wvi.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> <5526CA66.3090505@wvi.com> Message-ID: On Thu, Apr 9, 2015 at 2:52 PM, Jeff Shultz wrote: > I think that, properly, Batman wears a cowl, not a hat. > "... the details of his costume from time to time, it is most often depicted as consisting of: matching black (or blue) scalloped cape, bat-like cowl, gloves with a series of scalloped, fin-like protuberances, boots, and outerwear briefs; a yellow utility belt; and, a skintight gray body suit..." > > On 4/9/2015 11:29 AM, Mel Beckman wrote: >> >> Wrong. Batman, for example, wears a black hat. >> >> -mel via cell >> > From Marla.Azinger at FTR.com Thu Apr 9 19:35:07 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Thu, 9 Apr 2015 19:35:07 +0000 Subject: G/L Coding for RIR resources In-Reply-To: References: Message-ID: I don’t use a credit card. I expense through finance RIR fees go under a Maintenance code Database stuff would go under a Contractor code Cheers Marla -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Morrow Sent: Thursday, April 09, 2015 11:13 AM To: Bill Blackford Cc: nanog at nanog.org Subject: Re: G/L Coding for RIR resources On Thu, Apr 9, 2015 at 2:09 PM, Bill Blackford wrote: > Group. How do your respective bean counting teams code RIR resources, > ASN's, Addr allocations, etc.? Software subscription? Licensing? honestly I bet in a lot of places: "Office Supplies" because: 1) no one's finance department accounts for this sort of expense request 2) it ends up on someone's 'corporate card' 3) this is all easier than explaning to 'finance' how an RIR works and why it's important to pay them this year, again... From bzs at world.std.com Thu Apr 9 19:41:29 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 9 Apr 2015 15:41:29 -0400 Subject: Cisco/Level3 takedown In-Reply-To: <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> Message-ID: <21798.54761.332780.317706@world.std.com> Warrior Nun Areala wears a black hat. http://en.wikipedia.org/wiki/Warrior_Nun_Areala -b On April 9, 2015 at 18:29 mel at beckman.org (Mel Beckman) wrote: > Wrong. Batman, for example, wears a black hat. > > -mel via cell > > On Apr 9, 2015, at 11:17 AM, "Randy Bush" wrote: > > >> It does make one wonder why Cisco or Level 3 is involved, why they > >> feel they have the authority to hijack someone else's IP space, and > >> why they didn't go through law enforcement. This is especially true > >> for the second netblock (43.255.190.0/23), announced by a US company > >> (AS26484). > > > > vigilantes always wear white hats. > > > > randy From bzs at world.std.com Thu Apr 9 19:47:51 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 9 Apr 2015 15:47:51 -0400 Subject: Multi-gigabit edge devices as CPE [TOPIC DRIFT!] In-Reply-To: References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <21798.47041.94992.564368@world.std.com> Message-ID: <21798.55143.711992.278799@world.std.com> On April 9, 2015 at 20:50 baldur.norddahl at gmail.com (Baldur Norddahl) wrote: > You can do this for free with equal cost multi path routing. You announce > the same IP from multiple servers with eg. OSPF. True, and thanks, but that's just the beginning of an implementation, you still need all the gunk that detects and reacts to down or overloaded hosts, whether you want to do MAC or IP level redirecting, how data travels back to the remote host (directly or via the box's IP, NAT-like?), priority management, firewall functions, statistics gathering, blame apportionment (if I build it myself who do I get to blame?), etc. -b > Den 09/04/2015 19.34 skrev "Barry Shein" : > > > > > On April 9, 2015 at 09:11 raphael.timothy at gmail.com (Tim Raphael) wrote: > > > VyOS is a community fork of Vyatta and is still being developed very > > actively and it pushing ahead with many new features! It's pretty stable > > too imo. > > > > > > http://vyos.net/wiki/Main_Page > > > > SPEAKING of OSS routers... > > > > Does anyone know of a single OSS project which supports the usual BGP > > etc kind of things (routing) AND virtual hosting, the terminology is > > muddled, but one IP in, chooses among one or more IPs for > > load-balancing (not to be confused with device load-balancing), > > fail-over, round-robin, other policies? The typical web farm kind of > > thing, but for other kinds of services also like mail, imap, etc. > > > > I know one can piece together more than one project but then one has > > to get them to play together and learn their quirks and so forth. For > > example I don't think any Mikrotik (ok not strictly OSS but they seem > > nice) supports the virtual host stuff unless I'm missing it. > > > > I have some very old Alteons that do the virtual host stuff well > > enough but they are very long in the tooth (no IPv6, BGP is so old > > it's useless to the point of scary, etc.) > > > > P.S. No particular need for fancy WAN interfaces, ethernet > > presentations are fine. > > > > -- > > -Barry Shein > > > > The World | bzs at TheWorld.com | > > http://www.TheWorld.com > > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > > Canada > > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > > From edwin.mallette at gmail.com Thu Apr 9 15:28:47 2015 From: edwin.mallette at gmail.com (Edwin Mallette) Date: Thu, 09 Apr 2015 11:28:47 -0400 Subject: Voip encryption In-Reply-To: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> References: <00bd01d072ae$ff269920$fd73cb60$@blueyonder.co.uk> Message-ID: Hi Simon, My understanding is that since your 3rd party VPLS instance is a private ³MPLS² network, there is no requirement for application-level encryption. However if you wanted to encrypt VOIP that carries credit card data, some PBX/handsets offer application-level media encryption if that¹s the problem you want to solve to minimize your PCI scope. Cheers! Ed On 4/9/15, 6:21 AM, "Simon Brilus" wrote: >Hi - I have a PCIDSs requirement to encrypt VoIP over a 3rd party VPLS >network. Has anyone dealt with this. I'd really not use VPN's over the >VPLS >so am looking at hardware WAN encrypters. > > > >Any guidance appreciated. > > > >Thanks > > > >Simon > From Steve.Mikulasik at civeo.com Thu Apr 9 16:06:17 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 9 Apr 2015 16:06:17 +0000 Subject: Cisco/Level3 takedown In-Reply-To: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> Message-ID: Seems like it this is pretty ineffective. The group already moved subnets once, they will likely do this again, all Cisco/L3 have done is slow them down a bit. Stephen Mikulasik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sameer Khosla Sent: Thursday, April 09, 2015 9:31 AM To: nanog at nanog.org Subject: Cisco/Level3 takedown Was just reading http://blogs.cisco.com/security/talos/sshpsychos then checking my routing tables. Looks like the two /23's they mention are now being advertised as /24's, and I'm also not sure why cisco published the ssh attack dictionary. It seems to me that this is something that if they want to do, they should be working with entire service provider community, not just one provider. Thanks Sameer Khosla Managing Director Neutral Data Centers Corp. Twitter: @skhoslaTO From molney at cisco.com Thu Apr 9 20:01:54 2015 From: molney at cisco.com (Matt Olney (molney)) Date: Thu, 9 Apr 2015 20:01:54 +0000 Subject: Cisco/Level3 takedown In-Reply-To: <21798.54761.332780.317706@world.std.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> <21798.54761.332780.317706@world.std.com> Message-ID: In response to Sameer Khosla's comment that we should work with the entire service provider community: Talos is the threat intelligence group within Cisco. We absolutely welcome discussions with any network operator on how we can improve the state of security on the Internet. Please contact me directly via email and we can have a discussion about how we can work together going forward. Thank you in advance, Matthew Olney Manager, Talos Threat Intelligence Analytics Cisco From baldur.norddahl at gmail.com Thu Apr 9 20:27:28 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 9 Apr 2015 22:27:28 +0200 Subject: Multi-gigabit edge devices as CPE [TOPIC DRIFT!] In-Reply-To: <21798.55143.711992.278799@world.std.com> References: <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <21798.47041.94992.564368@world.std.com> <21798.55143.711992.278799@world.std.com> Message-ID: There is no redirecting as all the hosts have the same IP (typically on the loopback interface). Traffic goes back directly. You can even do priority but I would not. You get host down detection as the route will be withdrawn. You do not get server overload. On the other hand I am not sure I want such feature. I would use it to load balance the load balancers / web cache / ssl proxy and it should be quite good for that purpose. Regards Baldur Den 09/04/2015 21.48 skrev "Barry Shein" : > > On April 9, 2015 at 20:50 baldur.norddahl at gmail.com (Baldur Norddahl) > wrote: > > You can do this for free with equal cost multi path routing. You > announce > > the same IP from multiple servers with eg. OSPF. > > True, and thanks, but that's just the beginning of an implementation, > you still need all the gunk that detects and reacts to down or > overloaded hosts, whether you want to do MAC or IP level redirecting, > how data travels back to the remote host (directly or via the box's > IP, NAT-like?), priority management, firewall functions, statistics > gathering, blame apportionment (if I build it myself who do I get to > blame?), etc. > > -b > > > Den 09/04/2015 19.34 skrev "Barry Shein" : > > > > > > > > On April 9, 2015 at 09:11 raphael.timothy at gmail.com (Tim Raphael) > wrote: > > > > VyOS is a community fork of Vyatta and is still being developed > very > > > actively and it pushing ahead with many new features! It's pretty > stable > > > too imo. > > > > > > > > http://vyos.net/wiki/Main_Page > > > > > > SPEAKING of OSS routers... > > > > > > Does anyone know of a single OSS project which supports the usual BGP > > > etc kind of things (routing) AND virtual hosting, the terminology is > > > muddled, but one IP in, chooses among one or more IPs for > > > load-balancing (not to be confused with device load-balancing), > > > fail-over, round-robin, other policies? The typical web farm kind of > > > thing, but for other kinds of services also like mail, imap, etc. > > > > > > I know one can piece together more than one project but then one has > > > to get them to play together and learn their quirks and so forth. For > > > example I don't think any Mikrotik (ok not strictly OSS but they seem > > > nice) supports the virtual host stuff unless I'm missing it. > > > > > > I have some very old Alteons that do the virtual host stuff well > > > enough but they are very long in the tooth (no IPv6, BGP is so old > > > it's useless to the point of scary, etc.) > > > > > > P.S. No particular need for fancy WAN interfaces, ethernet > > > presentations are fine. > > > > > > -- > > > -Barry Shein > > > > > > The World | bzs at TheWorld.com | > > > http://www.TheWorld.com > > > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > > > Canada > > > Software Tool & Die | Public Access Internet | SINCE 1989 > *oo* > > > > From cboyd at gizmopartners.com Thu Apr 9 20:39:59 2015 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 9 Apr 2015 15:39:59 -0500 Subject: Cisco/Level3 takedown In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> <21798.54761.332780.317706@world.std.com> Message-ID: <2E72A97E-8C1D-4CF9-9634-102313FB2108@gizmopartners.com> > On Apr 9, 2015, at 3:01 PM, Matt Olney (molney) wrote: > > In response to Sameer Khosla's comment that we should work with the entire > service provider community: > > Talos is the threat intelligence group within Cisco. We absolutely > welcome discussions with any network operator on how we can improve the > state of security on the Internet. Please contact me directly via email > and we can have a discussion about how we can work together going forward. While I agree that the (at least temporary) mitigation of the threat was overall a good thing, I'm not really happy with the method used. Decisions to drop/block/filter traffic should be done locally. I would have appreciated Talos coming to the various *nog lists and saying something like "Hey, there's some really bad guys here. Here's the evidence of their bad behavior, you really should block them." That probably would have had a wider reach than just going to Level3. --Chris From morrowc.lists at gmail.com Thu Apr 9 20:54:28 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 9 Apr 2015 16:54:28 -0400 Subject: 100Gb/s TOR switch In-Reply-To: <55267699.3080004@foobar.org> References: <55257B27.4090300@interia.pl> <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> <55267699.3080004@foobar.org> Message-ID: On Thu, Apr 9, 2015 at 8:54 AM, Nick Hilliard wrote: > http://whiteboxswitch.com/products/edge-core-as5610-52x the math on their page is 'interesting'... 1.28tbps throughput (which is .08 or so tbps better than 64 10g ports equivalent) 960mbps forwarding err... so for just plain switching line-rate 64 10gbps ports. For forwarding traffic (being a router) ~1gbps. ouch, don't route. From surfer at mauigateway.com Thu Apr 9 20:55:04 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 9 Apr 2015 13:55:04 -0700 Subject: Cisco/Level3 takedown Message-ID: <20150409135504.39E57A59@m0048136.ppops.net> --- skhosla at neutraldata.com wrote: From: Sameer Khosla Was just reading http://blogs.cisco.com/security/talos/sshpsychos then checking my routing tables. Looks like the two /23's they mention are now being advertised as /24's, and I'm also not sure why cisco published the ssh attack dictionary. --------------------------------------------------- The authors lost some of their credibility when they wrote "Since then two class C networks have been..." At least they used slash notation for the rest of the article. If cisco won't stop using this terminology how will we get others to stop? Should I point them to https://en.wikipedia.org/wiki/Classful_network where they can see when a Class C (when it was a valid term) is all addresses that start with 110 in their leading bits and are in this range: 192.0.0.0 - 223.255.255.255. The addresses mentioned are from the historical Class A range even! Grrrr, a pet peeve of mine. Someone here says Class C and I ask them how a Class C is defined and then launch into the whole story. The short of it is they never use that phrase around me again. >;-) Last "Gone are the days when detectors and protectors can sit on the Internet’s sidelines when a group is brazenly attacking a wide range of systems around the world. [...] Cisco and Level 3 Communications agreed that it was time to step in and make it stop. " Declaration of war? I'm getting my popcorn ready. http://i294.photobucket.com/albums/mm86/JohnLeland1789/Funny/PopcornHugeBags.jpg scott From contact at nullivex.com Thu Apr 9 20:59:26 2015 From: contact at nullivex.com (Bryan Tong) Date: Thu, 9 Apr 2015 14:59:26 -0600 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> <55267699.3080004@foobar.org> Message-ID: Fairly certain thats a typo and supposed to be 960M pps :) On Thu, Apr 9, 2015 at 2:54 PM, Christopher Morrow wrote: > On Thu, Apr 9, 2015 at 8:54 AM, Nick Hilliard wrote: > > > http://whiteboxswitch.com/products/edge-core-as5610-52x > > the math on their page is 'interesting'... > > 1.28tbps throughput (which is .08 or so tbps better than 64 10g ports > equivalent) > 960mbps forwarding > > err... so for just plain switching line-rate 64 10gbps ports. For > forwarding traffic (being a router) ~1gbps. > > ouch, don't route. > -- eSited LLC (701) 390-9638 From nick at foobar.org Thu Apr 9 21:01:16 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 09 Apr 2015 22:01:16 +0100 Subject: 100Gb/s TOR switch In-Reply-To: References: <55257B27.4090300@interia.pl> <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> <55267699.3080004@foobar.org> Message-ID: <5526E89C.7040601@foobar.org> On 09/04/2015 21:54, Christopher Morrow wrote: > the math on their page is 'interesting'... it's a t2 chipset. should be all forwarded at asic level, i.e. at line rate per port. Nick From dsinn at dsinn.com Thu Apr 9 21:55:03 2015 From: dsinn at dsinn.com (David Sinn) Date: Thu, 9 Apr 2015 14:55:03 -0700 Subject: 100Gb/s TOR switch In-Reply-To: <5526E89C.7040601@foobar.org> References: <55257B27.4090300@interia.pl> <5525e501.876bb60a.1cc6.ffff93af@mx.google.com> <55267699.3080004@foobar.org> <5526E89C.7040601@foobar.org> Message-ID: <43C9182B-3C81-4919-BD56-E2F22A45ACBB@dsinn.com> The platform in question is Trident+ based and the official spec sheet from Edge Core is at: http://www.edge-core.com/ProdDtl.asp?sno=436&AS5610-52X Edge Core has other platforms that have the Trident2 ASIC in them. Regardless it should be "pps" not "mbps". Forwarding (at least with Cumulus Linux*) is done on the ASIC, so is line rate for L2/L3. Will reach out to get the page updated. David * Full disclosure: My day job is at Cumulus. On Apr 9, 2015, at 2:01 PM, Nick Hilliard wrote: > On 09/04/2015 21:54, Christopher Morrow wrote: >> the math on their page is 'interesting'... > > it's a t2 chipset. should be all forwarded at asic level, i.e. at line > rate per port. > > Nick > From edouard.chamillard at ablogix.fr Thu Apr 9 21:12:09 2015 From: edouard.chamillard at ablogix.fr (Edouard Chamillard) Date: Thu, 09 Apr 2015 23:12:09 +0200 Subject: Cisco/Level3 takedown In-Reply-To: <2E72A97E-8C1D-4CF9-9634-102313FB2108@gizmopartners.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <89066770-545F-4FDC-8689-6CAB678F4093@beckman.org> <21798.54761.332780.317706@world.std.com> <2E72A97E-8C1D-4CF9-9634-102313FB2108@gizmopartners.com> Message-ID: <5526EB29.5000109@ablogix.fr> Le 09/04/2015 22:39, Chris Boyd a écrit : >> On Apr 9, 2015, at 3:01 PM, Matt Olney (molney) wrote: >> >> In response to Sameer Khosla's comment that we should work with the entire >> service provider community: >> >> Talos is the threat intelligence group within Cisco. We absolutely >> welcome discussions with any network operator on how we can improve the >> state of security on the Internet. Please contact me directly via email >> and we can have a discussion about how we can work together going forward. > While I agree that the (at least temporary) mitigation of the threat was overall a good thing, I'm not really happy with the method used. Decisions to drop/block/filter traffic should be done locally. I would have appreciated Talos coming to the various *nog lists and saying something like "Hey, there's some really bad guys here. Here's the evidence of their bad behavior, you really should block them." That probably would have had a wider reach than just going to Level3. > > --Chris > Seconded this kind of decision should be left to the various providers, and be taken openly. while i am sure the decision has been taken with the best intention, i'd prefer not seeing this kind of power wielded in a discretionary fashion. 'tis a road that can lead to places i'm pretty sure nobody wants to go. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From SNaslund at medline.com Thu Apr 9 23:53:44 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 9 Apr 2015 23:53:44 +0000 Subject: Cisco/Level3 takedown In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401BFB0BCE5@MUNPRDMBXA1.medline.com> Can anyone else get to http://blogs.cisco.com ? I can't seem to reach it and was wondering if there was a counterattack of some type. Traceroute takes me to Rackspace in Dallas but the web site is not up. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Morrow Sent: Thursday, April 09, 2015 10:48 AM To: Sameer Khosla Cc: nanog at nanog.org Subject: Re: Cisco/Level3 takedown On Thu, Apr 9, 2015 at 11:31 AM, Sameer Khosla wrote: > Was just reading http://blogs.cisco.com/security/talos/sshpsychos then checking my routing tables. > > Looks like the two /23's they mention are now being advertised as /24's, and I'm also not sure why cisco published the ssh attack dictionary. > > It seems to me that this is something that if they want to do, they should be working with entire service provider community, not just one provider. are you sure they aren't engaged with a wider SP community? (the dictionary seems relevant for: "Oh crap, my root account DOES have password123 as the password :(") From josh at imaginenetworksllc.com Thu Apr 9 23:56:26 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 9 Apr 2015 19:56:26 -0400 Subject: Cisco/Level3 takedown In-Reply-To: <9578293AE169674F9A048B2BC9A081B401BFB0BCE5@MUNPRDMBXA1.medline.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <9578293AE169674F9A048B2BC9A081B401BFB0BCE5@MUNPRDMBXA1.medline.com> Message-ID: Websites up for me. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Apr 9, 2015 7:55 PM, "Naslund, Steve" wrote: > Can anyone else get to http://blogs.cisco.com ? I can't seem to reach > it and was wondering if there was a counterattack of some type. Traceroute > takes me to Rackspace in Dallas but the web site is not up. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher > Morrow > Sent: Thursday, April 09, 2015 10:48 AM > To: Sameer Khosla > Cc: nanog at nanog.org > Subject: Re: Cisco/Level3 takedown > > On Thu, Apr 9, 2015 at 11:31 AM, Sameer Khosla > wrote: > > Was just reading http://blogs.cisco.com/security/talos/sshpsychos then > checking my routing tables. > > > > Looks like the two /23's they mention are now being advertised as /24's, > and I'm also not sure why cisco published the ssh attack dictionary. > > > > It seems to me that this is something that if they want to do, they > should be working with entire service provider community, not just one > provider. > > are you sure they aren't engaged with a wider SP community? > (the dictionary seems relevant for: "Oh crap, my root account DOES have > password123 as the password :(") > From SNaslund at medline.com Fri Apr 10 00:13:44 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 10 Apr 2015 00:13:44 +0000 Subject: Cisco/Level3 takedown In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <9578293AE169674F9A048B2BC9A081B401BFB0BCE5@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401BFB0C001@MUNPRDMBXA1.medline.com> Sorry, I’m getting it now too. False alarm. Steve From: Josh Luthman [mailto:josh at imaginenetworksllc.com] Sent: Thursday, April 09, 2015 6:56 PM To: Naslund, Steve Cc: NANOG list Subject: RE: Cisco/Level3 takedown Websites up for me. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Apr 9, 2015 7:55 PM, "Naslund, Steve" > wrote: Can anyone else get to http://blogs.cisco.com ? I can't seem to reach it and was wondering if there was a counterattack of some type. Traceroute takes me to Rackspace in Dallas but the web site is not up. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Morrow Sent: Thursday, April 09, 2015 10:48 AM To: Sameer Khosla Cc: nanog at nanog.org Subject: Re: Cisco/Level3 takedown On Thu, Apr 9, 2015 at 11:31 AM, Sameer Khosla > wrote: > Was just reading http://blogs.cisco.com/security/talos/sshpsychos then checking my routing tables. > > Looks like the two /23's they mention are now being advertised as /24's, and I'm also not sure why cisco published the ssh attack dictionary. > > It seems to me that this is something that if they want to do, they should be working with entire service provider community, not just one provider. are you sure they aren't engaged with a wider SP community? (the dictionary seems relevant for: "Oh crap, my root account DOES have password123 as the password :(") From thomas.king at de-cix.net Fri Apr 10 12:56:25 2015 From: thomas.king at de-cix.net (Thomas King) Date: Fri, 10 Apr 2015 12:56:25 +0000 Subject: Optics and Fibres Supplier in the US Message-ID: Hi Nanog list, I am looking for a reliable supplier for optics and fibres in the US. A supplier close to NYC is preferable but optional. The concrete urgent needs are: * SFP+ DWDM optics ** 1x CH44, 1x CH45, compatible with DELL F10 ** 1x CH44, 1x CH45, compatible with Alcatel-Lucent * LC-LC patch cable ** 2x 2m ** 2x 3m ** 2x 5m Any suggestions are highly appreciated. Best regards, Thomas -- Dr. Thomas King Manager Research & Development DE-CIX Management GmbH | Lindleystraße 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net | Phone +49 69 1730902 87 | Mobile +49 175 1161428 | Fax +49 69 4056 2716 | thomas.king at de-cix.net | Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3201 bytes Desc: not available URL: From florian.hibler at kaiaglobal.com Fri Apr 10 13:11:25 2015 From: florian.hibler at kaiaglobal.com (Hibler, Florian) Date: Fri, 10 Apr 2015 14:11:25 +0100 Subject: Optics and Fibres Supplier in the US In-Reply-To: References: Message-ID: Hi Thomas, just go with Flexoptix next day delivery ;) Otherwise I can recommend Jeary from Myriad Supply. He is based in NYC. Phone 866-725-1025 Best regards, Florian On Fri, Apr 10, 2015 at 1:56 PM, Thomas King wrote: > Hi Nanog list, > > I am looking for a reliable supplier for optics and fibres in the US. A supplier close to NYC is preferable but optional. > > The concrete urgent needs are: > * SFP+ DWDM optics > ** 1x CH44, 1x CH45, compatible with DELL F10 > ** 1x CH44, 1x CH45, compatible with Alcatel-Lucent > > * LC-LC patch cable > ** 2x 2m > ** 2x 3m > ** 2x 5m > > Any suggestions are highly appreciated. > > Best regards, > Thomas > > -- > Dr. Thomas King > Manager Research & Development > > DE-CIX Management GmbH | Lindleystraße 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net | > Phone +49 69 1730902 87 | Mobile +49 175 1161428 | Fax +49 69 4056 2716 | thomas.king at de-cix.net | > Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 > -- Florian Hibler Chief Technical Officer eMail: florian.hibler at kaiaglobal.com Kaia Global Networks Limited Internet: http://www.kaiaglobal.com Company No. 08257877 Registered Office: 3rd floor, 12 Corporation Street, High Wycombe, HP13 6TQ, UK Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. From matthew at corp.crocker.com Fri Apr 10 14:14:34 2015 From: matthew at corp.crocker.com (Matthew Crocker) Date: Fri, 10 Apr 2015 10:14:34 -0400 Subject: Optics and Fibres Supplier in the US In-Reply-To: References: Message-ID: <117CDD37-A998-406C-9071-C66AC6FA4598@corp.crocker.com> +1 Flexoptics, Next day deliver, USB programmer makes the SFP any vendor you want. Graybar for fiber jumpers, next day counter pick up if they don’t have them in stock. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com > On Apr 10, 2015, at 8:56 AM, Thomas King wrote: > > Hi Nanog list, > > I am looking for a reliable supplier for optics and fibres in the US. A supplier close to NYC is preferable but optional. > > The concrete urgent needs are: > * SFP+ DWDM optics > ** 1x CH44, 1x CH45, compatible with DELL F10 > ** 1x CH44, 1x CH45, compatible with Alcatel-Lucent > > * LC-LC patch cable > ** 2x 2m > ** 2x 3m > ** 2x 5m > > Any suggestions are highly appreciated. > > Best regards, > Thomas > > -- > Dr. Thomas King > Manager Research & Development > > DE-CIX Management GmbH | Lindleystraße 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net | > Phone +49 69 1730902 87 | Mobile +49 175 1161428 | Fax +49 69 4056 2716 | thomas.king at de-cix.net | > Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 > From pkranz at unwiredltd.com Fri Apr 10 15:24:45 2015 From: pkranz at unwiredltd.com (Peter Kranz) Date: Fri, 10 Apr 2015 08:24:45 -0700 Subject: Open source alternatives to UNINETT Stager for visual netflow peering analysis Message-ID: <0b0601d073a2$79e2b060$6da81120$@unwiredltd.com> We've really enjoyed the open source Stager platform for netflow analysis, however the code has not seen updates in recent years. Looking for alternative open source netflow analysis platforms with a web interface. There are quite a few netflow tools around these days, and we are looking for something that performs the steps needed to showing us traffic volumes to particular AS#'s and their downstream customers for peering analysis decisions. I can get coarse answers from nfdump, but would like something more elegant for the NOC to use. Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From contact at winterei.se Fri Apr 10 15:29:02 2015 From: contact at winterei.se (Paul S.) Date: Sat, 11 Apr 2015 00:29:02 +0900 Subject: Open source alternatives to UNINETT Stager for visual netflow peering analysis In-Reply-To: <0b0601d073a2$79e2b060$6da81120$@unwiredltd.com> References: <0b0601d073a2$79e2b060$6da81120$@unwiredltd.com> Message-ID: <5527EC3E.8010509@winterei.se> https://github.com/manuelkasper/AS-Stats does that precise job (and nothing else) On 4/11/2015 午前 12:24, Peter Kranz wrote: > We've really enjoyed the open source Stager platform for netflow analysis, > however the code has not seen updates in recent years. Looking for > alternative open source netflow analysis platforms with a web interface. > There are quite a few netflow tools around these days, and we are looking > for something that performs the steps needed to showing us traffic volumes > to particular AS#'s and their downstream customers for peering analysis > decisions. I can get coarse answers from nfdump, but would like something > more elegant for the NOC to use. > > > > Peter Kranz > www.UnwiredLtd.com > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > pkranz at unwiredltd.com > > > From morrowc.lists at gmail.com Fri Apr 10 16:44:30 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Apr 2015 12:44:30 -0400 Subject: Open source alternatives to UNINETT Stager for visual netflow peering analysis In-Reply-To: <5527EC3E.8010509@winterei.se> References: <0b0601d073a2$79e2b060$6da81120$@unwiredltd.com> <5527EC3E.8010509@winterei.se> Message-ID: There's also nfsen to go on top of nfdump ... which can let you create views of the data showing per-as traffic stats. On Fri, Apr 10, 2015 at 11:29 AM, Paul S. wrote: > https://github.com/manuelkasper/AS-Stats does that precise job (and nothing > else) > > > On 4/11/2015 午前 12:24, Peter Kranz wrote: >> >> We've really enjoyed the open source Stager platform for netflow analysis, >> however the code has not seen updates in recent years. Looking for >> alternative open source netflow analysis platforms with a web interface. >> There are quite a few netflow tools around these days, and we are looking >> for something that performs the steps needed to showing us traffic volumes >> to particular AS#'s and their downstream customers for peering analysis >> decisions. I can get coarse answers from nfdump, but would like something >> more elegant for the NOC to use. >> >> >> Peter Kranz >> www.UnwiredLtd.com >> Desk: 510-868-1614 x100 >> Mobile: 510-207-0000 >> pkranz at unwiredltd.com >> >> > > From cscora at apnic.net Fri Apr 10 18:12:17 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Apr 2015 04:12:17 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201504101812.t3AICHGU017979@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 11 Apr, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 539454 Prefixes after maximum aggregation (per Origin AS): 206144 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 262960 Total ASes present in the Internet Routing Table: 49958 Prefixes per ASN: 10.80 Origin-only ASes present in the Internet Routing Table: 36555 Origin ASes announcing only one prefix: 16293 Transit ASes present in the Internet Routing Table: 6314 Transit-only ASes present in the Internet Routing Table: 179 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 45 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1353 Unregistered ASNs in the Routing Table: 417 Number of 32-bit ASNs allocated by the RIRs: 9117 Number of 32-bit ASNs visible in the Routing Table: 7089 Prefixes from 32-bit ASNs in the Routing Table: 25587 Number of bogon 32-bit ASNs visible in the Routing Table: 105 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 390 Number of addresses announced to Internet: 2740902052 Equivalent to 163 /8s, 94 /16s and 216 /24s Percentage of available address space announced: 74.0 Percentage of allocated address space announced: 74.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 181799 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133070 Total APNIC prefixes after maximum aggregation: 38773 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 138798 Unique aggregates announced from the APNIC address blocks: 56343 APNIC Region origin ASes present in the Internet Routing Table: 5036 APNIC Prefixes per ASN: 27.56 APNIC Region origin ASes announcing only one prefix: 1209 APNIC Region transit ASes present in the Internet Routing Table: 878 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 45 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1377 Number of APNIC addresses announced to Internet: 747573760 Equivalent to 44 /8s, 143 /16s and 18 /24s Percentage of available APNIC address space announced: 87.4 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, 131072-135580 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: 178026 Total ARIN prefixes after maximum aggregation: 87781 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 180419 Unique aggregates announced from the ARIN address blocks: 84337 ARIN Region origin ASes present in the Internet Routing Table: 16534 ARIN Prefixes per ASN: 10.91 ARIN Region origin ASes announcing only one prefix: 6092 ARIN Region transit ASes present in the Internet Routing Table: 1719 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 397 Number of ARIN addresses announced to Internet: 1065408288 Equivalent to 63 /8s, 128 /16s and 215 /24s Percentage of available ARIN address space announced: 56.4 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, 393216-394239 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: 130827 Total RIPE prefixes after maximum aggregation: 65369 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 137031 Unique aggregates announced from the RIPE address blocks: 84585 RIPE Region origin ASes present in the Internet Routing Table: 17930 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 8169 RIPE Region transit ASes present in the Internet Routing Table: 2980 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3590 Number of RIPE addresses announced to Internet: 694648964 Equivalent to 41 /8s, 103 /16s and 128 /24s Percentage of available RIPE address space announced: 101.0 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, 196608-202239 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: 59121 Total LACNIC prefixes after maximum aggregation: 11162 LACNIC Deaggregation factor: 5.30 Prefixes being announced from the LACNIC address blocks: 68994 Unique aggregates announced from the LACNIC address blocks: 32241 LACNIC Region origin ASes present in the Internet Routing Table: 2425 LACNIC Prefixes per ASN: 28.45 LACNIC Region origin ASes announcing only one prefix: 626 LACNIC Region transit ASes present in the Internet Routing Table: 494 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1618 Number of LACNIC addresses announced to Internet: 168052992 Equivalent to 10 /8s, 4 /16s and 73 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12658 Total AfriNIC prefixes after maximum aggregation: 3015 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 13822 Unique aggregates announced from the AfriNIC address blocks: 5100 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.81 AfriNIC Region origin ASes announcing only one prefix: 197 AfriNIC Region transit ASes present in the Internet Routing Table: 161 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 107 Number of AfriNIC addresses announced to Internet: 64668160 Equivalent to 3 /8s, 218 /16s and 194 /24s Percentage of available AfriNIC address space announced: 64.2 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 4766 2916 11557 912 Korea Telecom 17974 2796 904 78 PT Telekomunikasi Indonesia 7545 2534 336 127 TPG Telecom Limited 4755 2002 422 212 TATA Communications formerly 4538 1759 4190 71 China Education and Research 9829 1670 1326 39 National Internet Backbone 9808 1553 8717 28 Guangdong Mobile Communicatio 4808 1454 2259 450 CNCGROUP IP network China169 9583 1404 116 573 Sify Limited 9498 1314 334 94 BHARTI Airtel Ltd. 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 3019 2956 143 Cox Communications Inc. 6389 2881 3688 51 BellSouth.net Inc. 3356 2549 10683 483 Level 3 Communications, Inc. 18566 2040 379 183 MegaPath Corporation 20115 1854 1833 428 Charter Communications 6983 1753 866 245 EarthLink, Inc. 4323 1616 1020 407 tw telecom holdings, inc. 30036 1500 308 517 Mediacom Communications Corp 701 1411 11277 695 MCI Communications Services, 22561 1337 412 242 CenturyTel Internet Holdings, 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 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1980 304 356 TELLCOM ILETISIM HIZMETLERI A 20940 1763 689 1297 Akamai International B.V. 6849 1212 356 24 JSC "Ukrtelecom" 8402 1168 544 15 OJSC "Vimpelcom" 31148 1046 45 21 Freenet Ltd. 13188 1030 96 71 TOV "Bank-Inform" 12479 901 801 79 France Telecom Espana SA 8551 885 373 48 Bezeq International-Ltd 6830 851 2341 451 Liberty Global Operations B.V 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 3180 518 199 Telmex Colombia S.A. 28573 2329 2175 118 NET Servi�os de Comunica��o S 7303 1709 1102 243 Telecom Argentina S.A. 6147 1602 374 30 Telefonica del Peru S.A.A. 8151 1575 3173 458 Uninet S.A. de C.V. 6503 1217 421 57 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 980 2325 35 Tim Celular S.A. 3816 921 418 154 COLOMBIA TELECOMUNICACIONES S 18881 867 1036 22 Global Village Telecom 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 8452 1705 958 13 TE-AS 24863 965 284 27 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 417 1229 32 ETISALAT MISR 24835 300 144 9 Vodafone Data 3741 249 857 208 Internet Solutions 29571 231 21 12 Cote d'Ivoire Telecom 36947 198 807 13 Telecom Algeria 37492 177 127 67 Orange Tunisie 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3180 518 199 Telmex Colombia S.A. 22773 3019 2956 143 Cox Communications Inc. 4766 2916 11557 912 Korea Telecom 6389 2881 3688 51 BellSouth.net Inc. 17974 2796 904 78 PT Telekomunikasi Indonesia 3356 2549 10683 483 Level 3 Communications, Inc. 7545 2534 336 127 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2329 2175 118 NET Servi�os de Comunica��o S 18566 2040 379 183 MegaPath Corporation 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 3019 2876 Cox Communications Inc. 6389 2881 2830 BellSouth.net Inc. 17974 2796 2718 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2534 2407 TPG Telecom Limited 28573 2329 2211 NET Servi�os de Comunica��o S 3356 2549 2066 Level 3 Communications, Inc. 4766 2916 2004 Korea Telecom 18566 2040 1857 MegaPath Corporation 4755 2002 1790 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 36270 UNALLOCATED 8.24.66.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 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:12 /10:34 /11:93 /12:262 /13:509 /14:999 /15:1719 /16:12947 /17:7202 /18:12225 /19:25320 /20:35869 /21:38548 /22:58609 /23:51179 /24:290956 /25:1124 /26:1124 /27:661 /28:14 /29:11 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2228 3019 Cox Communications Inc. 18566 1995 2040 MegaPath Corporation 6389 1671 2881 BellSouth.net Inc. 6983 1400 1753 EarthLink, Inc. 30036 1346 1500 Mediacom Communications Corp 34984 1287 1980 TELLCOM ILETISIM HIZMETLERI A 6147 1149 1602 Telefonica del Peru S.A.A. 10620 1123 3180 Telmex Colombia S.A. 11492 1103 1168 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1480 2:653 4:93 5:1751 6:23 8:1413 12:1827 13:9 14:1304 15:17 16:2 17:44 18:21 20:48 23:1201 24:1708 27:1853 31:1521 32:38 33:2 34:5 35:3 36:116 37:1896 38:1012 39:9 40:246 41:2981 42:262 43:1239 44:26 45:377 46:2116 47:38 49:847 50:794 52:12 54:72 55:4 56:8 57:36 58:1216 59:682 60:467 61:1749 62:1338 63:1908 64:4458 65:2257 66:4129 67:2062 68:1074 69:3265 70:961 71:441 72:1959 74:2648 75:321 76:406 77:1455 78:1204 79:798 80:1315 81:1355 82:820 83:686 84:678 85:1374 86:376 87:1072 88:511 89:1808 90:151 91:6001 92:825 93:2189 94:1970 95:2083 96:430 97:349 98:1065 99:47 100:67 101:819 103:7140 104:1497 105:61 106:226 107:929 108:620 109:2020 110:1079 111:1489 112:773 113:1067 114:809 115:1260 116:1353 117:1002 118:1721 119:1447 120:448 121:1036 122:2192 123:1736 124:1498 125:1585 128:566 129:380 130:387 131:1174 132:492 133:173 134:419 135:109 136:304 137:314 138:596 139:161 140:240 141:415 142:669 143:503 144:569 145:108 146:715 147:590 148:1111 149:431 150:552 151:604 152:492 153:240 154:444 155:745 156:407 157:335 158:319 159:979 160:373 161:642 162:1956 163:424 164:664 165:687 166:287 167:806 168:1279 169:161 170:1450 171:241 172:41 173:1548 174:696 175:664 176:1369 177:3773 178:2068 179:893 180:1931 181:1653 182:1729 183:618 184:738 185:3243 186:2643 187:1797 188:2017 189:1570 190:7628 191:920 192:8242 193:5592 194:4114 195:3668 196:1705 197:1093 198:5527 199:5525 200:6522 201:3016 202:9464 203:9078 204:4691 205:2834 206:3089 207:3010 208:3942 209:3975 210:3516 211:1863 212:2466 213:2287 214:855 215:71 216:5600 217:1800 218:675 219:453 220:1436 221:788 222:464 223:659 End of report From admin at coldnorthadmin.com Fri Apr 10 19:56:00 2015 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Fri, 10 Apr 2015 15:56:00 -0400 Subject: Open source alternatives to UNINETT Stager for visual netflow peering analysis In-Reply-To: References: <0b0601d073a2$79e2b060$6da81120$@unwiredltd.com> <5527EC3E.8010509@winterei.se> Message-ID: <55282AD0.6090105@coldnorthadmin.com> Nfsen is not a very "elegant" tool. It's very powerful, but it does require a fair amount of fiddling in order to get what you want out of it. On 4/10/2015 12:44 PM, Christopher Morrow wrote: > There's also nfsen to go on top of nfdump ... which can let you create > views of the data showing per-as traffic stats. > > > > On Fri, Apr 10, 2015 at 11:29 AM, Paul S. wrote: >> https://github.com/manuelkasper/AS-Stats does that precise job (and nothing >> else) >> >> >> On 4/11/2015 午前 12:24, Peter Kranz wrote: >>> We've really enjoyed the open source Stager platform for netflow analysis, >>> however the code has not seen updates in recent years. Looking for >>> alternative open source netflow analysis platforms with a web interface. >>> There are quite a few netflow tools around these days, and we are looking >>> for something that performs the steps needed to showing us traffic volumes >>> to particular AS#'s and their downstream customers for peering analysis >>> decisions. I can get coarse answers from nfdump, but would like something >>> more elegant for the NOC to use. >>> >>> >>> Peter Kranz >>> www.UnwiredLtd.com >>> Desk: 510-868-1614 x100 >>> Mobile: 510-207-0000 >>> pkranz at unwiredltd.com >>> >>> >> -- Laurent Dumont coldnorthadmin.com From nanog at ics-il.net Fri Apr 10 20:49:19 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 10 Apr 2015 15:49:19 -0500 (CDT) Subject: Open source alternatives to UNINETT Stager for visual netflow peering analysis In-Reply-To: <5527EC3E.8010509@winterei.se> Message-ID: <54711.4366.1428698967341.JavaMail.mhammett@ThunderFuck> I got the impression that Peter was looking for it to also do downstream ASes. I don't get that impression from the AS-Stats page. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul S." To: nanog at nanog.org Sent: Friday, April 10, 2015 10:29:02 AM Subject: Re: Open source alternatives to UNINETT Stager for visual netflow peering analysis https://github.com/manuelkasper/AS-Stats does that precise job (and nothing else) On 4/11/2015 午前 12:24, Peter Kranz wrote: > We've really enjoyed the open source Stager platform for netflow analysis, > however the code has not seen updates in recent years. Looking for > alternative open source netflow analysis platforms with a web interface. > There are quite a few netflow tools around these days, and we are looking > for something that performs the steps needed to showing us traffic volumes > to particular AS#'s and their downstream customers for peering analysis > decisions. I can get coarse answers from nfdump, but would like something > more elegant for the NOC to use. > > > > Peter Kranz > www.UnwiredLtd.com > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > pkranz at unwiredltd.com > > > From jloiacon at csc.com Fri Apr 10 21:06:50 2015 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 10 Apr 2015 17:06:50 -0400 Subject: Open source alternatives to UNINETT Stager for visual netflow peering analysis In-Reply-To: <0b0601d073a2$79e2b060$6da81120$@unwiredltd.com> References: <0b0601d073a2$79e2b060$6da81120$@unwiredltd.com> Message-ID: You could use FlowViewer with the flow-tools underlying collector option if you're collecting v5 netflow. This will permit you to keep long-term graphs (ala MRTG - Last 24 hours, Last 7 days, etc.) for each AS peer with 5-minute granularity You can also graph specified time intervals at much smaller time-bucket sizes. FlowViewer has an IPFIX (e.g., v9, FNF, etc.) underlying collector also; SiLK. However, last I checked, SiLK is not collecting AS information. https://sourceforge.net/projects/flowviewer Regards, Joe From: "Peter Kranz" To: Date: 04/10/2015 11:26 AM Subject: Open source alternatives to UNINETT Stager for visual netflow peering analysis Sent by: "NANOG" We've really enjoyed the open source Stager platform for netflow analysis, however the code has not seen updates in recent years. Looking for alternative open source netflow analysis platforms with a web interface. There are quite a few netflow tools around these days, and we are looking for something that performs the steps needed to showing us traffic volumes to particular AS#'s and their downstream customers for peering analysis decisions. I can get coarse answers from nfdump, but would like something more elegant for the NOC to use. Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From cidr-report at potaroo.net Fri Apr 10 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Apr 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201504102200.t3AM00n0001113@wattle.apnic.net> This report has been generated at Fri Apr 10 21:14:35 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-04-15 546119 299432 04-04-15 546337 299359 05-04-15 546063 299448 06-04-15 546237 299694 07-04-15 546379 299131 08-04-15 546653 299930 09-04-15 546540 300390 10-04-15 546760 300226 AS Summary 50225 Number of ASes in routing system 20056 Number of ASes announcing only one prefix 3180 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120958464 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 10Apr15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 546653 300156 246497 45.1% All ASes AS22773 3020 172 2848 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2880 83 2797 97.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2796 78 2718 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 20 2453 99.2% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2314 285 2029 87.7% NET Servi�os de Comunica��o S.A.,BR AS3356 2552 757 1795 70.3% LEVEL3 - Level 3 Communications, Inc.,US AS4755 2000 381 1619 80.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2918 1337 1581 54.2% KIXS-AS-KR Korea Telecom,KR AS6983 1752 248 1504 85.8% ITCDELTA - Earthlink, Inc.,US AS9808 1556 67 1489 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6147 1602 159 1443 90.1% Telefonica del Peru S.A.A.,PE AS7303 1709 293 1416 82.9% Telecom Argentina S.A.,AR AS20115 1854 492 1362 73.5% CHARTER-NET-HKY-NC - Charter Communications,US AS10620 3180 1819 1361 42.8% Telmex Colombia S.A.,CO AS7545 2588 1363 1225 47.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1622 408 1214 74.8% TWTC - tw telecom holdings, inc.,US AS9498 1314 110 1204 91.6% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2039 869 1170 57.4% MEGAPATH5-US - MegaPath Corporation,US AS8402 1154 24 1130 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS7552 1163 58 1105 95.0% VIETEL-AS-AP Viettel Corporation,VN AS22561 1337 256 1081 80.9% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS6849 1209 172 1037 85.8% UKRTELNET JSC UKRTELECOM,UA AS8151 1579 654 925 58.6% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS8452 1874 997 877 46.8% TE-AS TE-AS,EG AS38285 983 114 869 88.4% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4780 1083 256 827 76.4% SEEDNET Digital United Inc.,TW AS4538 1778 956 822 46.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 965 158 807 83.6% Tim Celular S.A.,BR AS24560 1232 464 768 62.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 55525 13133 42392 76.3% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 45.114.232.0/22 AS59347 AALOKITLIMITED-BD Aalok IT Limited,BD 45.114.232.0/24 AS59347 AALOKITLIMITED-BD Aalok IT Limited,BD 45.114.233.0/24 AS59347 AALOKITLIMITED-BD Aalok IT Limited,BD 45.114.234.0/24 AS59347 AALOKITLIMITED-BD Aalok IT Limited,BD 45.114.235.0/24 AS59347 AALOKITLIMITED-BD Aalok IT Limited,BD 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.41.124.0/24 AS63854 103.41.125.0/24 AS63854 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.225.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 138.12.0.0/16 AS1757 -Reserved AS-,ZZ 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.116.0/22 AS54632 -Reserved AS-,ZZ 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.96.0/21 AS54632 -Reserved AS-,ZZ 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.73.216.0/24 AS1757 -Reserved AS-,ZZ 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.232.0/23 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 193.93.234.0/23 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.114.136.0/22 AS33866 -Reserved AS-,ZZ 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.187.36.0/22 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.184.90.0/23 AS19738 TISA-SOFT-AS OOO "Tisa-Soft",RU 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.90.128.0/18 AS20135 FILMATA "FILMATA" LTD,BG 196.90.192.0/18 AS20135 FILMATA "FILMATA" LTD,BG 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.185.17.0/24 AS1757 -Reserved AS-,ZZ 198.185.18.0/24 AS1757 -Reserved AS-,ZZ 198.185.19.0/24 AS1757 -Reserved AS-,ZZ 198.185.21.0/24 AS1757 -Reserved AS-,ZZ 198.185.22.0/24 AS1757 -Reserved AS-,ZZ 198.185.23.0/24 AS1757 -Reserved AS-,ZZ 198.185.24.0/24 AS32472 -Reserved AS-,ZZ 198.185.25.0/24 AS1757 -Reserved AS-,ZZ 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.126.72.0/21 AS23175 POGOZONE - PogoZone,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.83.88.0/22 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.90.0/23 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.91.0/24 AS12910 -Reserved AS-,ZZ 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 10 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Apr 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201504102200.t3AM016n001127@wattle.apnic.net> BGP Update Report Interval: 02-Apr-15 -to- 09-Apr-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 261532 5.9% 3189.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS10029 235469 5.3% 516.4 -- CITYCOMNETWORKS-AS CITYCOM NETWORKS PVT LTD,IN 3 - AS61894 173372 3.9% 43343.0 -- FreeBSD Brasil LTDA,BR 4 - AS9829 173306 3.9% 129.5 -- BSNL-NIB National Internet Backbone,IN 5 - AS22059 111920 2.5% 55960.0 -- APVIO-1 - Apvio, Inc.,US 6 - AS36947 82214 1.8% 464.5 -- ALGTEL-AS,DZ 7 - AS28573 78974 1.8% 23.0 -- NET Servi�os de Comunica��o S.A.,BR 8 - AS21669 76722 1.7% 19180.5 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 9 - AS3709 75043 1.7% 2779.4 -- NET-CITY-SA - City of San Antonio,US 10 - AS53563 48173 1.1% 48173.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 11 - AS33529 42180 0.9% 7030.0 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 12 - AS36903 41807 0.9% 102.7 -- MT-MPLS,MA 13 - AS28661 41058 0.9% 651.7 -- HOTLINK INTERNET LTDA,BR 14 - AS7303 34218 0.8% 36.8 -- Telecom Argentina S.A.,AR 15 - AS8402 30100 0.7% 44.5 -- CORBINA-AS OJSC "Vimpelcom",RU 16 - AS25563 28028 0.6% 9342.7 -- WEBLAND-AS Webland AG, Autonomous System,CH 17 - AS7713 26716 0.6% 3339.5 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 18 - AS46230 26596 0.6% 1266.5 -- DUDROP - Dignitas Technology Inc,US 19 - AS39891 20395 0.5% 10.3 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 20 - AS197914 19528 0.4% 19528.0 -- STOCKHO-AS Stockho Hosting SARL,FR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22059 111920 2.5% 55960.0 -- APVIO-1 - Apvio, Inc.,US 2 - AS53563 48173 1.1% 48173.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 3 - AS61894 173372 3.9% 43343.0 -- FreeBSD Brasil LTDA,BR 4 - AS197914 19528 0.4% 19528.0 -- STOCKHO-AS Stockho Hosting SARL,FR 5 - AS21669 76722 1.7% 19180.5 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 6 - AS18135 9965 0.2% 9965.0 -- BTV BTV Cable television,JP 7 - AS393588 9523 0.2% 9523.0 -- MUBEA-FLO - Mubea,US 8 - AS201576 9399 0.2% 9399.0 -- TCBANK-AS Tver City Bank, Joint Stock Company,RU 9 - AS25563 28028 0.6% 9342.7 -- WEBLAND-AS Webland AG, Autonomous System,CH 10 - AS46336 8960 0.2% 8960.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 11 - AS199121 8008 0.2% 8008.0 -- FLEXOPTIX Flexoptix GmbH,DE 12 - AS44951 7437 0.2% 7437.0 -- EFONDS-AS eFonds Solutions AG,DE 13 - AS33529 42180 0.9% 7030.0 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 14 - AS60673 5374 0.1% 5374.0 -- ACTIVCOM Activcom Kft,HU 15 - AS61294 5370 0.1% 5370.0 -- STIHLHU-AS Andreas Stihl Kereskedelmi Kft,HU 16 - AS61570 18888 0.4% 4722.0 -- ENTERIW PROVEDOR DE INTERNET LTDA,BR 17 - AS20386 3360 0.1% 3360.0 -- MOVE-VAN - Move Sales, Inc.,US 18 - AS7713 26716 0.6% 3339.5 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 19 - AS23752 261532 5.9% 3189.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 20 - AS33440 12190 0.3% 3047.5 -- WEBRULON-NETWORK - webRulon, LLC,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 173355 3.7% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 130756 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 130078 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 105.96.0.0/22 79375 1.7% AS36947 -- ALGTEL-AS,DZ 5 - 209.212.8.0/24 76674 1.6% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 6 - 76.191.107.0/24 55992 1.2% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 64.34.125.0/24 55928 1.2% AS22059 -- APVIO-1 - Apvio, Inc.,US 8 - 199.38.164.0/23 48173 1.0% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 9 - 69.194.4.0/24 42167 0.9% AS33529 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 10 - 118.98.88.0/24 26724 0.6% AS64567 -- -Private Use AS-,ZZ AS7713 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 11 - 130.0.192.0/21 19528 0.4% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 12 - 177.128.221.0/24 18759 0.4% AS61570 -- ENTERIW PROVEDOR DE INTERNET LTDA,BR 13 - 91.193.202.0/24 15126 0.3% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 14 - 192.58.232.0/24 10115 0.2% AS6629 -- NOAA-AS - NOAA,US 15 - 134.162.82.0/24 10056 0.2% AS7303 -- Telecom Argentina S.A.,AR 16 - 134.162.83.0/24 10013 0.2% AS7303 -- Telecom Argentina S.A.,AR 17 - 134.162.84.0/24 9974 0.2% AS7303 -- Telecom Argentina S.A.,AR 18 - 42.83.48.0/20 9965 0.2% AS18135 -- BTV BTV Cable television,JP 19 - 92.43.216.0/21 9592 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 20 - 192.58.137.0/24 9523 0.2% AS393588 -- MUBEA-FLO - Mubea,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From srihari at cse.sc.edu Fri Apr 10 22:27:02 2015 From: srihari at cse.sc.edu (Srihari Nelakuditi) Date: Fri, 10 Apr 2015 18:27:02 -0400 Subject: CFP: IEEE International Conference on Network Protocols (ICNP) Message-ID: <55284E36.1060705@cse.sc.edu> Call for Papers IEEE ICNP 2015 http://icnp15.cs.ucr.edu/ ICNP, the IEEE International Conference on Network Protocols, is the premier conference on network protocols, covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. Sponsored by the IEEE, ICNP 2015 is the 23rd edition of the conference, to be held in San Francisco, CA, USA from Nov. 10-13, 2015. ====================================================================== Important dates Paper Submission May 8, 2015, 7:59 PM EST (FIRM) Acceptance Notification June 30, 2015 Camera Ready Version Aug 15, 2015 ====================================================================== We invite papers with significant, original research contributions to the field of network protocols for submission. Topics of interest include, but are not limited to: * All aspects of network protocol research including design, specification, verification, implementation, measurement, testing, and analysis * Domain-specific solutions, including protocols for network security, Internet of Things, routing, user privacy, network management, and data centers * Application-layer protocols for peer-to-peer systems, social networks, and emerging systems * Contributions to network architecture, e.g., specific algorithms and protocols for software defined networks, network virtualization, or future Internet architectures ICNP 2015 will select an accepted full paper for the best paper award. Up to two of the best papers from ICNP will be fast-tracked in the IEEE/ACM Transactions on Networking, with a streamlined journal review process. Acceptance of fast-tracked papers in ToN is not guaranteed, but is more likely than a regular submission. Submission Guidelines * All papers should adhere to the IEEE Computer conference paper formatting requirements (IEEEtran.cls) and should not exceed 10 pages with font size no smaller than 10 pt (details can be found on the submission guidelines and formatting page). * ICNP uses a double-blind review process. The identity of authors and referees will not be revealed to each other. To ensure double-blind reviewing, author names and affiliations should not appear in the paper; bibliographic references should be made in such a way as to preserve author anonymity; acknowledgement with identifiable names and funding sources should be removed. Note that own work should be cited as a third person. Papers violating this double-blind review policy will be rejected without review. * Authors need to indicate on their paper’s submission page all TPC members with whom they have conflicts of interest. * Every paper MUST be presented by an author at the conference. The author list MUST remain the same as when the paper was submitted for review, and any changes in the author list or title is forbidden without prior written permission from the TPC Co-Chairs. At least one author of an accepted paper is expected to register at the full rate of the conference and to present the paper at the conference, in order for the paper to appear in the conference proceedings and be submitted to the IEEE digital library. Papers not presented by an author at the conference will not be published in the proceedings or submitted for inclusion in the IEEE digital library. Integrity Policy Submitted papers should not be previously published nor under review by another conference or journal. In some cases, the ICNP chairs may share information about submitted papers with other conference chairs and journal editors to ensure the integrity of papers under consideration. Authors are prohibited from informing any TPC member of any identifiable information (such as titles) of their submissions. Also, papers containing plagiarized material will be subject to the IEEE plagiarism policy and will be rejected without review. Organizing Committee General Co-Chairs: Srikanth V. Krishnamurthy, University of California, Riverside Prasant Mohapatra, University of California, Davis TPC Co-Chairs: Aditya Akella, University of Wisconsin, Madison Vishal Misra, Columbia University Steering Committee: Kevin Almeroth, University of California, Santa Barbara Ken Calvert, University of Kentucky Sonia Fahmy, Purdue University Mohamed Gouda, University of Texas, Austin Timothy G. Griffin, University of Cambridge Teruo Higashino, Osaka University David Lee, HP Labs K.K. Ramakrishnan (Chair), University of California, Riverside Krishan Sabnani, Bell Laboratories ====================================================================== From mike at mikejones.in Sat Apr 11 07:37:07 2015 From: mike at mikejones.in (Mike Jones) Date: Sat, 11 Apr 2015 08:37:07 +0100 Subject: Cisco/Level3 takedown In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> Message-ID: On 9 April 2015 at 19:16, Randy Bush wrote: >> It does make one wonder why Cisco or Level 3 is involved, why they >> feel they have the authority to hijack someone else's IP space, and >> why they didn't go through law enforcement. This is especially true >> for the second netblock (43.255.190.0/23), announced by a US company >> (AS26484). > > vigilantes always wear white hats. > > randy It seems to me from reading the article that the "defence" to this is to set up a legitimate hosting company in the same IP space, even if it only has 1 customer. Then if you get blocked you turn around and shout and scream that level3 are abusing their market dominance to prevent a rival firms customers (this legitimate hosting company) being able to use the Internet. How screwed would they be in in court? I suspect it won't be a US court that gets to side with a US company and ignore everyone else, I suspect it would be an EU court case where there are actual consequences to a company trying to abuse their market dominance to force others to do what they want. This specific group might not have the balls to try sueing level3, but if they make a habit of blocking peoples access to the internet then ambulance chasing lawyers will likely try to trick them in to screwing up and blocking their clients. - Mike From rekordmeister at gmail.com Sat Apr 11 07:55:38 2015 From: rekordmeister at gmail.com (MKS) Date: Sat, 11 Apr 2015 07:55:38 +0000 Subject: Netflix guessing game Message-ID: Being a network operator in a region where Netflix doesn't operate, we are still seeing significant Netflix traffic on our network. Our magic 8-ball sees about 1000 concurrent users/streams @peak hour. Does someone have an educated guess (or a more accurate answer;) how many actual subscribers we have on our network, 10k, 15k or 20k subscribers? Offline answers are also fine Regards MKS From nanog at ics-il.net Sat Apr 11 12:44:31 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 11 Apr 2015 07:44:31 -0500 (CDT) Subject: Cisco/Level3 takedown In-Reply-To: Message-ID: <14024650.5196.1428756251369.JavaMail.mhammett@ThunderFuck> Oh well. Don't do business with dirtbags. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Jones" To: "Randy Bush" Cc: nanog at nanog.org Sent: Saturday, April 11, 2015 2:37:07 AM Subject: Re: Cisco/Level3 takedown On 9 April 2015 at 19:16, Randy Bush wrote: >> It does make one wonder why Cisco or Level 3 is involved, why they >> feel they have the authority to hijack someone else's IP space, and >> why they didn't go through law enforcement. This is especially true >> for the second netblock (43.255.190.0/23), announced by a US company >> (AS26484). > > vigilantes always wear white hats. > > randy It seems to me from reading the article that the "defence" to this is to set up a legitimate hosting company in the same IP space, even if it only has 1 customer. Then if you get blocked you turn around and shout and scream that level3 are abusing their market dominance to prevent a rival firms customers (this legitimate hosting company) being able to use the Internet. How screwed would they be in in court? I suspect it won't be a US court that gets to side with a US company and ignore everyone else, I suspect it would be an EU court case where there are actual consequences to a company trying to abuse their market dominance to force others to do what they want. This specific group might not have the balls to try sueing level3, but if they make a habit of blocking peoples access to the internet then ambulance chasing lawyers will likely try to trick them in to screwing up and blocking their clients. - Mike From jeremy at eff.org Sat Apr 11 04:22:43 2015 From: jeremy at eff.org (Jeremy Gillula) Date: Fri, 10 Apr 2015 21:22:43 -0700 Subject: Open Letter RE:Cyber Threat Info Sharing Bills Message-ID: <5528A193.2060403@eff.org> Dear colleagues, As many of you know, the US Congress is currently considering various bills which some of its members think will help fight Internet security threats via increased information sharing between companies and the government. Unfortunately, not only are these new information sharing powers unnecessary, the bills' broad immunity clauses for companies , vague definitions , and aggressive spying powers essentially make them secret surveillance bills--and more government surveillance of the Internet is the last thing we need right now. I'm writing you today to ask you to sign on to an open letter to Congress, which explains the fallacy of these bills to politicians who probably don't understand the intricacies of the network security world. This is the fifth time in as many years that Congress has tried to pass "cybersecurity" legislation. Fortunately (with the help of many of you on this list) we've been successful in preventing such misguided legislation in the past./*If you're willing to sign on and help today, please email me directly (off list) */and I will be happy to share a copy of the letter for you to review before you agree to sign on. The more signatures we can get, the more likely Congress is to listen. All it takes is an email. Please help us make sure politicians get the message: we don't need new legal authorities to share information that will help keep the systems and people we protect safe from future attacks. Thank you for your support, -- | Jeremy Gillula, Ph.D. | Staff Technologist | Electronic Frontier Foundation | (415) 436-9333 x158 | jeremy at eff.org | @the_zeroth_law | GPG Key Fingerprint: | 4DCF A726 7C7D E327 7DD6 | 863E A25B 3CE6 2CAC 7BE9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mark.tinka at seacom.mu Sun Apr 12 14:52:22 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 12 Apr 2015 16:52:22 +0200 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: Message-ID: <552A86A6.2020803@seacom.mu> On 9/Apr/15 01:26, Hamish McGlinn wrote: > > As Tim said above, I too was thinking about the Juniper ACX. The 5048/5096 > model could suit your needs. They are primarily designed as layer 1(TDM)/2 > backhaul devices and i'm not sure they can do a full table. They do have > full JunOS MPLS features. Could be a way to use MPLS-TE to move the layer 2 > back to a core location and terminate later 3 there. Would give you some > flexibility over just doing ethernet stuff as I mentioned in the first > paragraph. The ACX5000 series are Ethernet-only switches. They hold about 120,000 entries in FIB, and as of today despite all the RAM, are only sold with support for 300,000 entries in RIB. The chipset is not Juniper in-house, though; so make sure all your features work. Mark. From mark.tinka at seacom.mu Sun Apr 12 14:53:27 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 12 Apr 2015 16:53:27 +0200 Subject: Multi-gigabit edge devices as CPE In-Reply-To: <25140EAF-A075-4A51-A4CF-D826715513F9@wwt.com> References: , <266666556.1733414.1428538473215.JavaMail.zimbra@snappytelecom.net> <25140EAF-A075-4A51-A4CF-D826715513F9@wwt.com> Message-ID: <552A86E7.8070809@seacom.mu> On 9/Apr/15 03:01, Watson, Bob wrote: > Dan, The new asr920 by cisco would fit 4x10g SFP+ and 24 ports SFP or copper 1g line rate about 6 k list without license . You can leverage netconf yang model as its cisco edge or other flavor choice > > You can unicast if you want more data as we've done EFI and evaluated them in our labs But it only holds 20,000 IPv4 entries in FIB - quite paltry if he wants a full table. Then again, BGP-SD + selective routing into FIB could fix that. Mark. From hmcglinn at gmail.com Sun Apr 12 22:15:11 2015 From: hmcglinn at gmail.com (Hamish McGlinn) Date: Mon, 13 Apr 2015 10:15:11 +1200 Subject: Multi-gigabit edge devices as CPE In-Reply-To: <552A86A6.2020803@seacom.mu> References: <552A86A6.2020803@seacom.mu> Message-ID: > > The ACX5000 series are Ethernet-only switches. > > They hold about 120,000 entries in FIB, and as of today despite all the > RAM, are only sold with support for 300,000 entries in RIB. > > The chipset is not Juniper in-house, though; so make sure all your > features work. > The ACX series is more of a hybrid. They are probably more likened to Layer 2 routers than switches. They are primarily designed as Mobile backhaul devices where integration into existing IP MPLS infrastructure would be a cost saving and design advantage. You can see this with the other models that have the TDM (E1/T1) interfaces. Those models use SAToP and CESoPSN to move TDM based circuits over an MPLS network. It's all rather clever really. The Ethernet ports on those models as well as the ethernet only models are an extension of that. They provide layer 2 interfaces where you don't really require layer 3 services (such as ethernet based mobile backhaul). So they are a switch, yes, but more than that. They utilise MPLS L2VPN/L2Circuits to move ethernet over the MPLS infrastructure. Hence why I thought it could be an alternative to terminating the layer 3 at the edge. Hamish From mark.tinka at seacom.mu Sun Apr 12 22:23:12 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 13 Apr 2015 00:23:12 +0200 Subject: Multi-gigabit edge devices as CPE In-Reply-To: References: <552A86A6.2020803@seacom.mu> Message-ID: <552AF050.4080809@seacom.mu> On 13/Apr/15 00:15, Hamish McGlinn wrote: > > The ACX series is more of a hybrid. They are probably more likened to > Layer 2 routers than switches. They are primarily designed as Mobile > backhaul devices where integration into existing IP MPLS > infrastructure would be a cost saving and design advantage. You can > see this with the other models that have the TDM (E1/T1) interfaces. > Those models use SAToP and CESoPSN to move TDM based circuits over an > MPLS network. It's all rather clever really. The Ethernet ports on > those models as well as the ethernet only models are an extension of > that. They provide layer 2 interfaces where you don't really require > layer 3 services (such as ethernet based mobile backhaul). So they are > a switch, yes, but more than that. They utilise MPLS L2VPN/L2Circuits > to move ethernet over the MPLS infrastructure. Hence why I thought it > could be an alternative to terminating the layer 3 at the edge. What you're referring to are the ACX500 through to the ACX4000 units. The ACX5000 (5048 and 5096, respectively) are Metro-E switches (IP/MPLS routers, really). Unlike the other ACX models, they do not come with any non-Ethernet ports. Mark. From goemon at anime.net Mon Apr 13 20:36:07 2015 From: goemon at anime.net (goemon at anime.net) Date: Mon, 13 Apr 2015 13:36:07 -0700 (PDT) Subject: reclaiming arin IP allocations? Message-ID: web.com/netsol is disavowing ownership of 209.17.115.109. NetRange: 209.17.112.0 - 209.17.127.255 CIDR: 209.17.112.0/20 NetName: WEB-COM-BLK3 NetHandle: NET-209-17-112-0-1 Parent: NET209 (NET-209-0-0-0-0) What is the process to get this netblock reclaimed? -Dan From mel at beckman.org Mon Apr 13 20:40:32 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Apr 2015 20:40:32 +0000 Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: What makes you think they are disavowing ownership? Did they state that to you personally, or are you inferring that from other information? -mel beckman > On Apr 13, 2015, at 1:36 PM, "goemon at anime.net" wrote: > > web.com/netsol is disavowing ownership of 209.17.115.109. > > NetRange: 209.17.112.0 - 209.17.127.255 > CIDR: 209.17.112.0/20 > NetName: WEB-COM-BLK3 > NetHandle: NET-209-17-112-0-1 > Parent: NET209 (NET-209-0-0-0-0) > > What is the process to get this netblock reclaimed? > > -Dan From morrowc.lists at gmail.com Mon Apr 13 20:43:55 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Apr 2015 16:43:55 -0400 Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: kinda looks like their routers still ask it to be routed to them: 19871 | 209.17.112.0 | NETWORK-SOLUTIONS-HOSTING - Network Solutions, LLC,US and stat.ripe.net: the 2 /21's are 19871 originated, with the last /24 from 36476 (web.com's as) On Mon, Apr 13, 2015 at 4:40 PM, Mel Beckman wrote: > What makes you think they are disavowing ownership? Did they state that to you personally, or are you inferring that from other information? > > -mel beckman > >> On Apr 13, 2015, at 1:36 PM, "goemon at anime.net" wrote: >> >> web.com/netsol is disavowing ownership of 209.17.115.109. >> >> NetRange: 209.17.112.0 - 209.17.127.255 >> CIDR: 209.17.112.0/20 >> NetName: WEB-COM-BLK3 >> NetHandle: NET-209-17-112-0-1 >> Parent: NET209 (NET-209-0-0-0-0) >> >> What is the process to get this netblock reclaimed? >> >> -Dan From goemon at anime.net Mon Apr 13 20:53:06 2015 From: goemon at anime.net (goemon at anime.net) Date: Mon, 13 Apr 2015 13:53:06 -0700 (PDT) Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: i reported abuse to them that was originating directly from 209.17.115.109, they responded stating they have no control over the origin IP and that i should look up the IP in arin to get the owner. -Dan On Mon, 13 Apr 2015, Mel Beckman wrote: > What makes you think they are disavowing ownership? Did they state that to you personally, or are you inferring that from other information? > > -mel beckman > >> On Apr 13, 2015, at 1:36 PM, "goemon at anime.net" wrote: >> >> web.com/netsol is disavowing ownership of 209.17.115.109. >> >> NetRange: 209.17.112.0 - 209.17.127.255 >> CIDR: 209.17.112.0/20 >> NetName: WEB-COM-BLK3 >> NetHandle: NET-209-17-112-0-1 >> Parent: NET209 (NET-209-0-0-0-0) >> >> What is the process to get this netblock reclaimed? >> >> -Dan > From woody at pch.net Mon Apr 13 20:57:32 2015 From: woody at pch.net (Bill Woodcock) Date: Mon, 13 Apr 2015 13:57:32 -0700 Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: > On Apr 13, 2015, at 1:53 PM, goemon at anime.net wrote: > > i reported abuse to them that was originating directly from > 209.17.115.109, they responded stating they have no control over the origin IP and that i should look up the IP in arin to get the owner. > > -Dan > > On Mon, 13 Apr 2015, Mel Beckman wrote: > >> What makes you think they are disavowing ownership? Did they state that to you personally, or are you inferring that from other information? >> >> -mel beckman >> >>> On Apr 13, 2015, at 1:36 PM, "goemon at anime.net" wrote: >>> >>> web.com/netsol is disavowing ownership of 209.17.115.109. >>> >>> NetRange: 209.17.112.0 - 209.17.127.255 >>> CIDR: 209.17.112.0/20 >>> NetName: WEB-COM-BLK3 >>> NetHandle: NET-209-17-112-0-1 >>> Parent: NET209 (NET-209-0-0-0-0) >>> >>> What is the process to get this netblock reclaimed? >>> >>> -Dan >> A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Speaking individually, not with my ARIN board hat on: If you’d like to report the address to abuse at arin.net, an ARIN postmaster can contact the web.com POC, and get an authoritative answer. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From morrowc.lists at gmail.com Mon Apr 13 21:02:46 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Apr 2015 17:02:46 -0400 Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 4:53 PM, wrote: > i reported abuse to them that was originating directly from > 209.17.115.109, they responded stating they have no control over the origin > IP and that i should look up the IP in arin to get the owner. it kind of sounds like they are confused and maybe asking them: "Are you sure because the call is coming from inside your house" is in order. From mel at beckman.org Mon Apr 13 21:03:11 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Apr 2015 21:03:11 +0000 Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: <7594D3BD-A65F-4AA0-AB17-F2CCD81E49C7@beckman.org> Show them the Whois info and that might change their mind. Asking to reclaim the space is silly. -mel > On Apr 13, 2015, at 1:53 PM, goemon at anime.net wrote: > > i reported abuse to them that was originating directly from > 209.17.115.109, they responded stating they have no control over the origin IP and that i should look up the IP in arin to get the owner. > > -Dan > > On Mon, 13 Apr 2015, Mel Beckman wrote: > >> What makes you think they are disavowing ownership? Did they state that to you personally, or are you inferring that from other information? >> >> -mel beckman >> >>> On Apr 13, 2015, at 1:36 PM, "goemon at anime.net" wrote: >>> >>> web.com/netsol is disavowing ownership of 209.17.115.109. >>> >>> NetRange: 209.17.112.0 - 209.17.127.255 >>> CIDR: 209.17.112.0/20 >>> NetName: WEB-COM-BLK3 >>> NetHandle: NET-209-17-112-0-1 >>> Parent: NET209 (NET-209-0-0-0-0) >>> >>> What is the process to get this netblock reclaimed? >>> >>> -Dan >> From contact at nullivex.com Mon Apr 13 21:10:35 2015 From: contact at nullivex.com (Bryan Tong) Date: Mon, 13 Apr 2015 15:10:35 -0600 Subject: reclaiming arin IP allocations? In-Reply-To: <7594D3BD-A65F-4AA0-AB17-F2CCD81E49C7@beckman.org> References: <7594D3BD-A65F-4AA0-AB17-F2CCD81E49C7@beckman.org> Message-ID: This is just a typical "Drop the bomb, and soften the blow" technique. On Mon, Apr 13, 2015 at 3:03 PM, Mel Beckman wrote: > Show them the Whois info and that might change their mind. Asking to > reclaim the space is silly. > > -mel > > > On Apr 13, 2015, at 1:53 PM, goemon at anime.net wrote: > > > > i reported abuse to them that was originating directly from > > 209.17.115.109, they responded stating they have no control over the > origin IP and that i should look up the IP in arin to get the owner. > > > > -Dan > > > > On Mon, 13 Apr 2015, Mel Beckman wrote: > > > >> What makes you think they are disavowing ownership? Did they state that > to you personally, or are you inferring that from other information? > >> > >> -mel beckman > >> > >>> On Apr 13, 2015, at 1:36 PM, "goemon at anime.net" > wrote: > >>> > >>> web.com/netsol is disavowing ownership of 209.17.115.109. > >>> > >>> NetRange: 209.17.112.0 - 209.17.127.255 > >>> CIDR: 209.17.112.0/20 > >>> NetName: WEB-COM-BLK3 > >>> NetHandle: NET-209-17-112-0-1 > >>> Parent: NET209 (NET-209-0-0-0-0) > >>> > >>> What is the process to get this netblock reclaimed? > >>> > >>> -Dan > >> > > -- eSited LLC (701) 390-9638 From cb.list6 at gmail.com Mon Apr 13 21:20:13 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 13 Apr 2015 14:20:13 -0700 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers Message-ID: Good news (that i have not personally verified) ! Verizon, T-Mobile, Sprint, and AT&T all launched the Samsung Galaxy S6 with IPv6 on by default. Given the growth and importance of mobile to Internet, it is great to see this progress from the mobile carriers. Just for those keeping score, of the top 10 Alexa website for the USA, these major websites prefer IPv6 or prefer NAT44 / NAT64 from the mobile networks 1. Google -- prefers IPv6 2. Facebook -- prefers IPv6 3. Youtube -- prefers IPv6 4. Amazon -- prefers NAT -- :( 5. Yahoo! -- prefers IPv6 6. Wikipedia -- prefers IPv6 7. Twitter -- prefers NAT -- :( 8. Ebay -- prefers NAT -- :( 9. Linkedin -- prefers IPv6 10. Reddit -- prefers NAT -- :( Dear Amazon, Twitter, Ebay, and Reddit -- please consider this your personal invitation to introduce IPv6 to your service. From morrowc.lists at gmail.com Mon Apr 13 21:22:58 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Apr 2015 17:22:58 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 5:20 PM, Ca By wrote: > Dear Amazon, Twitter, Ebay, and Reddit -- please consider this your > personal invitation to introduce IPv6 to your service. good news! it's only really 3 places that need update, since reddit is (still?) an amazon aws customer. From owen at delong.com Mon Apr 13 21:23:09 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Apr 2015 14:23:09 -0700 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: Message-ID: <78703D1D-582C-4EEF-82D6-A1EDEA001444@delong.com> Now if only T-Mobile would launch IPv6 for I-Devices!! No, blaming Apple for not implementing your chosen transition mechanism is not a valid excuse. Owen > On Apr 13, 2015, at 2:20 PM, Ca By wrote: > > Good news (that i have not personally verified) ! > > Verizon, T-Mobile, Sprint, and AT&T all launched the Samsung Galaxy S6 with > IPv6 on by default. > > Given the growth and importance of mobile to Internet, it is great to see > this progress from the mobile carriers. > > Just for those keeping score, of the top 10 Alexa website for the USA, > these major websites prefer IPv6 or prefer NAT44 / NAT64 from the mobile > networks > > 1. Google -- prefers IPv6 > 2. Facebook -- prefers IPv6 > 3. Youtube -- prefers IPv6 > 4. Amazon -- prefers NAT -- :( > 5. Yahoo! -- prefers IPv6 > 6. Wikipedia -- prefers IPv6 > 7. Twitter -- prefers NAT -- :( > 8. Ebay -- prefers NAT -- :( > 9. Linkedin -- prefers IPv6 > 10. Reddit -- prefers NAT -- :( > > Dear Amazon, Twitter, Ebay, and Reddit -- please consider this your > personal invitation to introduce IPv6 to your service. From rali.ahmed at gmail.com Mon Apr 13 21:29:25 2015 From: rali.ahmed at gmail.com (Rashed Alwarrag) Date: Tue, 14 Apr 2015 00:29:25 +0300 Subject: Cisco Routers Vulnerability Message-ID: Hi Today we have a lot of customers report that their Cisco routers got a root access and the IOS got erased , is there any known vulnerability in cisco products thats they report in their Security alerts about this recently ? is there any one face the same issue ? Regards From egon at egon.cc Mon Apr 13 21:31:04 2015 From: egon at egon.cc (James Downs) Date: Mon, 13 Apr 2015 14:31:04 -0700 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: Message-ID: <5A124B1C-982A-40C9-8091-E50946CA39BA@egon.cc> > On Apr 13, 2015, at 14:20, Ca By wrote: > Dear Amazon, Twitter, Ebay, and Reddit -- please consider this your > personal invitation to introduce IPv6 to your service. Skype doesn’t appear to have any IPv6 infrastructure. -j From jimpop at gmail.com Mon Apr 13 21:32:42 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 13 Apr 2015 17:32:42 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: Message-ID: On Mon, Apr 13, 2015 at 5:20 PM, Ca By wrote: > Good news (that i have not personally verified) ! > > Verizon This is not new for VZW, they've been defaulting to IPv6 since my first Galaxy Nexus (2011). -Jim P. From morrowc.lists at gmail.com Mon Apr 13 21:32:49 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Apr 2015 17:32:49 -0400 Subject: Cisco Routers Vulnerability In-Reply-To: References: Message-ID: http://tools.cisco.com/security/center/publicationListing.x On Mon, Apr 13, 2015 at 5:29 PM, Rashed Alwarrag wrote: > Hi > Today we have a lot of customers report that their Cisco routers got a root > access and the IOS got erased , is there any known vulnerability in cisco > products thats they report in their Security alerts about this recently ? > is there any one face the same issue ? > > Regards From jschiel at flowtools.net Mon Apr 13 21:39:45 2015 From: jschiel at flowtools.net (John Schiel) Date: Mon, 13 Apr 2015 15:39:45 -0600 Subject: Cisco Routers Vulnerability In-Reply-To: References: Message-ID: <552C37A1.5030807@flowtools.net> On 04/13/2015 03:29 PM, Rashed Alwarrag wrote: > Hi > Today we have a lot of customers report that their Cisco routers got a root > access and the IOS got erased , is there any known vulnerability in cisco > products thats they report in their Security alerts about this recently ? > is there any one face the same issue ? It would help if you could share the router type, IOS version, etc. --John > > Regards From nick at foobar.org Mon Apr 13 21:44:57 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 13 Apr 2015 23:44:57 +0200 Subject: Cisco Routers Vulnerability In-Reply-To: References: Message-ID: <552C38D9.3030506@foobar.org> On 13/04/2015 23:29, Rashed Alwarrag wrote: > Today we have a lot of customers report that their Cisco routers got a root > access and the IOS got erased , is there any known vulnerability in cisco > products thats they report in their Security alerts about this recently ? > is there any one face the same issue ? "show tech-support" might give you a list of the last commands issued on the devices. It's more likely to be a password compromise than a remote vuln. Nick From danny at danysek.cz Mon Apr 13 21:48:03 2015 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 13 Apr 2015 23:48:03 +0200 Subject: Cisco Routers Vulnerability In-Reply-To: References: Message-ID: <552C3993.3050005@danysek.cz> Hello, ask your customers, if they had VTY access secured properly. Brute-force password attacks against management interface (telnet, SSH) aren't rare these days and once you have management access, you can do anything independently on known code vulnerabilies. With regards, Daniel On 13.4.2015 23:29, Rashed Alwarrag wrote: > Hi > Today we have a lot of customers report that their Cisco routers got a root > access and the IOS got erased , is there any known vulnerability in cisco > products thats they report in their Security alerts about this recently ? > is there any one face the same issue ? > > Regards > From rali.ahmed at gmail.com Mon Apr 13 21:48:39 2015 From: rali.ahmed at gmail.com (Rashed Alwarrag) Date: Tue, 14 Apr 2015 00:48:39 +0300 Subject: Cisco Routers Vulnerability In-Reply-To: <552C38D9.3030506@foobar.org> References: <552C38D9.3030506@foobar.org> Message-ID: It's reported by different customers in different locations so I don't think it's password compromised Regards On Tuesday, April 14, 2015, Nick Hilliard wrote: > On 13/04/2015 23:29, Rashed Alwarrag wrote: > > Today we have a lot of customers report that their Cisco routers got a > root > > access and the IOS got erased , is there any known vulnerability in cisco > > products thats they report in their Security alerts about this recently > ? > > is there any one face the same issue ? > > "show tech-support" might give you a list of the last commands issued on > the devices. It's more likely to be a password compromise than a remote > vuln. > > Nick > > -- *Rashed Alwarrag * From rali.ahmed at gmail.com Mon Apr 13 21:49:17 2015 From: rali.ahmed at gmail.com (Rashed Alwarrag) Date: Tue, 14 Apr 2015 00:49:17 +0300 Subject: Cisco Routers Vulnerability In-Reply-To: <552C37A1.5030807@flowtools.net> References: <552C37A1.5030807@flowtools.net> Message-ID: I will try to get those informations Thanks On Tuesday, April 14, 2015, John Schiel wrote: > > > On 04/13/2015 03:29 PM, Rashed Alwarrag wrote: > >> Hi >> Today we have a lot of customers report that their Cisco routers got a >> root >> access and the IOS got erased , is there any known vulnerability in cisco >> products thats they report in their Security alerts about this recently ? >> is there any one face the same issue ? >> > > It would help if you could share the router type, IOS version, etc. > > --John > > >> Regards >> > > -- *Rashed Alwarrag * From jschiel at flowtools.net Mon Apr 13 21:51:31 2015 From: jschiel at flowtools.net (John Schiel) Date: Mon, 13 Apr 2015 15:51:31 -0600 Subject: Cisco Routers Vulnerability In-Reply-To: References: <552C37A1.5030807@flowtools.net> Message-ID: <552C3A63.203@flowtools.net> On 04/13/2015 03:49 PM, Rashed Alwarrag wrote: > I will try to get those informations If you follow Chris's suggestion, you might get faster resolution. http://tools.cisco.com/security/center/publicationListing.x --John > > Thanks > > On Tuesday, April 14, 2015, John Schiel > wrote: > > > > On 04/13/2015 03:29 PM, Rashed Alwarrag wrote: > > Hi > Today we have a lot of customers report that their Cisco > routers got a root > access and the IOS got erased , is there any known > vulnerability in cisco > products thats they report in their Security alerts about this > recently ? > is there any one face the same issue ? > > > It would help if you could share the router type, IOS version, etc. > > --John > > > Regards > > > > > -- > > *Rashed Alwarrag * > > From nick at foobar.org Mon Apr 13 21:55:23 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 13 Apr 2015 23:55:23 +0200 Subject: Cisco Routers Vulnerability In-Reply-To: References: <552C38D9.3030506@foobar.org> Message-ID: <552C3B4B.9010804@foobar.org> On 13/04/2015 23:48, Rashed Alwarrag wrote: > It's reported by different customers in different locations so I don't > think it's password compromised Have you checked? If the routers had vty access open (ssh or telnet) and the passwords were easy to guess, then it's more likely that this was a password compromise. You can test this out by getting a copy of one of the configs and decrypting the access password. Or by asking your customers whether their passwords were dictionary or simple words. It's possible that there was a remotely accessible vulnerability, but ios isn't known for this. Nick From rali.ahmed at gmail.com Mon Apr 13 21:59:33 2015 From: rali.ahmed at gmail.com (Rashed Alwarrag) Date: Tue, 14 Apr 2015 00:59:33 +0300 Subject: Cisco Routers Vulnerability In-Reply-To: <552C3B4B.9010804@foobar.org> References: <552C38D9.3030506@foobar.org> <552C3B4B.9010804@foobar.org> Message-ID: Still I don't have full information from them as it has been reported by different customers and all almost in the same time , I am trying to get some information about , I was just checking if there is known vulnerability has been announced recently regarding this Thanks you guys On Tuesday, April 14, 2015, Nick Hilliard wrote: > On 13/04/2015 23:48, Rashed Alwarrag wrote: > > It's reported by different customers in different locations so I don't > > think it's password compromised > > Have you checked? If the routers had vty access open (ssh or telnet) and > the passwords were easy to guess, then it's more likely that this was a > password compromise. You can test this out by getting a copy of one of the > configs and decrypting the access password. Or by asking your customers > whether their passwords were dictionary or simple words. > > It's possible that there was a remotely accessible vulnerability, but ios > isn't known for this. > > Nick > > > -- *Rashed Alwarrag * From goemon at anime.net Mon Apr 13 22:02:08 2015 From: goemon at anime.net (goemon at anime.net) Date: Mon, 13 Apr 2015 15:02:08 -0700 (PDT) Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: On Mon, 13 Apr 2015, Bill Woodcock wrote: > Speaking individually, not with my ARIN board hat on: > > If you’d like to report the address to abuse at arin.net, an ARIN postmaster can contact the web.com POC, and get an authoritative answer. Very interesting: http://whois.arin.net/rest/net/NET-209-17-112-0-1/pft "Note ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2013-11-06" So if the owner does not care to respond to ARIN, what now? -Dan From george.herbert at gmail.com Mon Apr 13 22:09:20 2015 From: george.herbert at gmail.com (George Herbert) Date: Mon, 13 Apr 2015 15:09:20 -0700 Subject: Cisco Routers Vulnerability In-Reply-To: References: <552C38D9.3030506@foobar.org> <552C3B4B.9010804@foobar.org> Message-ID: A whole pile of new vulnerabilities including remote code exploit were revealed against specific models about 3 weeks ago; I had not heard of any exploits, but, ... Which is why the models and IOS versions would be very useful. On Mon, Apr 13, 2015 at 2:59 PM, Rashed Alwarrag wrote: > Still I don't have full information from them as it has been reported by > different customers and all almost in the same time , I am trying to get > some information about , I was just checking if there is known > vulnerability has been announced recently regarding this > > Thanks you guys > > > On Tuesday, April 14, 2015, Nick Hilliard wrote: > > > On 13/04/2015 23:48, Rashed Alwarrag wrote: > > > It's reported by different customers in different locations so I don't > > > think it's password compromised > > > > Have you checked? If the routers had vty access open (ssh or telnet) and > > the passwords were easy to guess, then it's more likely that this was a > > password compromise. You can test this out by getting a copy of one of > the > > configs and decrypting the access password. Or by asking your customers > > whether their passwords were dictionary or simple words. > > > > It's possible that there was a remotely accessible vulnerability, but ios > > isn't known for this. > > > > Nick > > > > > > > > -- > > *Rashed Alwarrag * > -- -george william herbert george.herbert at gmail.com From mgalgoci at redhat.com Mon Apr 13 22:39:24 2015 From: mgalgoci at redhat.com (Matthew Galgoci) Date: Mon, 13 Apr 2015 22:39:24 +0000 (UTC) Subject: Cisco Routers Vulnerability In-Reply-To: References: Message-ID: Thus said Rashed Alwarrag on Tue, 14 Apr 2015: > Date: Tue, 14 Apr 2015 00:29:25 +0300 > From: Rashed Alwarrag > To: nanog at nanog.org > Subject: Cisco Routers Vulnerability > > Hi > Today we have a lot of customers report that their Cisco routers got a root > access and the IOS got erased , is there any known vulnerability in cisco > products thats they report in their Security alerts about this recently ? > is there any one face the same issue ? Another strong possibility is a disgruntled former employee or former contractor. -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 ------------------------------ “Whatever you do will be insignificant, but it is very important that you do it.” -- Mahatma Gandhi From cscora at apnic.net Fri Apr 10 18:12:17 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Apr 2015 04:12:17 +1000 (AEST) Subject: **SPAM** [afnog] Weekly Routing Table Report Message-ID: <201504101812.t3AICHGU017979@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 11 Apr, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 539454 Prefixes after maximum aggregation (per Origin AS): 206144 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 262960 Total ASes present in the Internet Routing Table: 49958 Prefixes per ASN: 10.80 Origin-only ASes present in the Internet Routing Table: 36555 Origin ASes announcing only one prefix: 16293 Transit ASes present in the Internet Routing Table: 6314 Transit-only ASes present in the Internet Routing Table: 179 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 45 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1353 Unregistered ASNs in the Routing Table: 417 Number of 32-bit ASNs allocated by the RIRs: 9117 Number of 32-bit ASNs visible in the Routing Table: 7089 Prefixes from 32-bit ASNs in the Routing Table: 25587 Number of bogon 32-bit ASNs visible in the Routing Table: 105 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 390 Number of addresses announced to Internet: 2740902052 Equivalent to 163 /8s, 94 /16s and 216 /24s Percentage of available address space announced: 74.0 Percentage of allocated address space announced: 74.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 181799 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133070 Total APNIC prefixes after maximum aggregation: 38773 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 138798 Unique aggregates announced from the APNIC address blocks: 56343 APNIC Region origin ASes present in the Internet Routing Table: 5036 APNIC Prefixes per ASN: 27.56 APNIC Region origin ASes announcing only one prefix: 1209 APNIC Region transit ASes present in the Internet Routing Table: 878 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 45 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1377 Number of APNIC addresses announced to Internet: 747573760 Equivalent to 44 /8s, 143 /16s and 18 /24s Percentage of available APNIC address space announced: 87.4 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, 131072-135580 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: 178026 Total ARIN prefixes after maximum aggregation: 87781 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 180419 Unique aggregates announced from the ARIN address blocks: 84337 ARIN Region origin ASes present in the Internet Routing Table: 16534 ARIN Prefixes per ASN: 10.91 ARIN Region origin ASes announcing only one prefix: 6092 ARIN Region transit ASes present in the Internet Routing Table: 1719 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 397 Number of ARIN addresses announced to Internet: 1065408288 Equivalent to 63 /8s, 128 /16s and 215 /24s Percentage of available ARIN address space announced: 56.4 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, 393216-394239 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: 130827 Total RIPE prefixes after maximum aggregation: 65369 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 137031 Unique aggregates announced from the RIPE address blocks: 84585 RIPE Region origin ASes present in the Internet Routing Table: 17930 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 8169 RIPE Region transit ASes present in the Internet Routing Table: 2980 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3590 Number of RIPE addresses announced to Internet: 694648964 Equivalent to 41 /8s, 103 /16s and 128 /24s Percentage of available RIPE address space announced: 101.0 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, 196608-202239 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: 59121 Total LACNIC prefixes after maximum aggregation: 11162 LACNIC Deaggregation factor: 5.30 Prefixes being announced from the LACNIC address blocks: 68994 Unique aggregates announced from the LACNIC address blocks: 32241 LACNIC Region origin ASes present in the Internet Routing Table: 2425 LACNIC Prefixes per ASN: 28.45 LACNIC Region origin ASes announcing only one prefix: 626 LACNIC Region transit ASes present in the Internet Routing Table: 494 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1618 Number of LACNIC addresses announced to Internet: 168052992 Equivalent to 10 /8s, 4 /16s and 73 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12658 Total AfriNIC prefixes after maximum aggregation: 3015 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 13822 Unique aggregates announced from the AfriNIC address blocks: 5100 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.81 AfriNIC Region origin ASes announcing only one prefix: 197 AfriNIC Region transit ASes present in the Internet Routing Table: 161 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 107 Number of AfriNIC addresses announced to Internet: 64668160 Equivalent to 3 /8s, 218 /16s and 194 /24s Percentage of available AfriNIC address space announced: 64.2 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 4766 2916 11557 912 Korea Telecom 17974 2796 904 78 PT Telekomunikasi Indonesia 7545 2534 336 127 TPG Telecom Limited 4755 2002 422 212 TATA Communications formerly 4538 1759 4190 71 China Education and Research 9829 1670 1326 39 National Internet Backbone 9808 1553 8717 28 Guangdong Mobile Communicatio 4808 1454 2259 450 CNCGROUP IP network China169 9583 1404 116 573 Sify Limited 9498 1314 334 94 BHARTI Airtel Ltd. 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 3019 2956 143 Cox Communications Inc. 6389 2881 3688 51 BellSouth.net Inc. 3356 2549 10683 483 Level 3 Communications, Inc. 18566 2040 379 183 MegaPath Corporation 20115 1854 1833 428 Charter Communications 6983 1753 866 245 EarthLink, Inc. 4323 1616 1020 407 tw telecom holdings, inc. 30036 1500 308 517 Mediacom Communications Corp 701 1411 11277 695 MCI Communications Services, 22561 1337 412 242 CenturyTel Internet Holdings, 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 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1980 304 356 TELLCOM ILETISIM HIZMETLERI A 20940 1763 689 1297 Akamai International B.V. 6849 1212 356 24 JSC "Ukrtelecom" 8402 1168 544 15 OJSC "Vimpelcom" 31148 1046 45 21 Freenet Ltd. 13188 1030 96 71 TOV "Bank-Inform" 12479 901 801 79 France Telecom Espana SA 8551 885 373 48 Bezeq International-Ltd 6830 851 2341 451 Liberty Global Operations B.V 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 3180 518 199 Telmex Colombia S.A. 28573 2329 2175 118 NET Servi�os de Comunica��o S 7303 1709 1102 243 Telecom Argentina S.A. 6147 1602 374 30 Telefonica del Peru S.A.A. 8151 1575 3173 458 Uninet S.A. de C.V. 6503 1217 421 57 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 980 2325 35 Tim Celular S.A. 3816 921 418 154 COLOMBIA TELECOMUNICACIONES S 18881 867 1036 22 Global Village Telecom 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 8452 1705 958 13 TE-AS 24863 965 284 27 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 417 1229 32 ETISALAT MISR 24835 300 144 9 Vodafone Data 3741 249 857 208 Internet Solutions 29571 231 21 12 Cote d'Ivoire Telecom 36947 198 807 13 Telecom Algeria 37492 177 127 67 Orange Tunisie 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3180 518 199 Telmex Colombia S.A. 22773 3019 2956 143 Cox Communications Inc. 4766 2916 11557 912 Korea Telecom 6389 2881 3688 51 BellSouth.net Inc. 17974 2796 904 78 PT Telekomunikasi Indonesia 3356 2549 10683 483 Level 3 Communications, Inc. 7545 2534 336 127 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2329 2175 118 NET Servi�os de Comunica��o S 18566 2040 379 183 MegaPath Corporation 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 3019 2876 Cox Communications Inc. 6389 2881 2830 BellSouth.net Inc. 17974 2796 2718 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2534 2407 TPG Telecom Limited 28573 2329 2211 NET Servi�os de Comunica��o S 3356 2549 2066 Level 3 Communications, Inc. 4766 2916 2004 Korea Telecom 18566 2040 1857 MegaPath Corporation 4755 2002 1790 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 36270 UNALLOCATED 8.24.66.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 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:12 /10:34 /11:93 /12:262 /13:509 /14:999 /15:1719 /16:12947 /17:7202 /18:12225 /19:25320 /20:35869 /21:38548 /22:58609 /23:51179 /24:290956 /25:1124 /26:1124 /27:661 /28:14 /29:11 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2228 3019 Cox Communications Inc. 18566 1995 2040 MegaPath Corporation 6389 1671 2881 BellSouth.net Inc. 6983 1400 1753 EarthLink, Inc. 30036 1346 1500 Mediacom Communications Corp 34984 1287 1980 TELLCOM ILETISIM HIZMETLERI A 6147 1149 1602 Telefonica del Peru S.A.A. 10620 1123 3180 Telmex Colombia S.A. 11492 1103 1168 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1480 2:653 4:93 5:1751 6:23 8:1413 12:1827 13:9 14:1304 15:17 16:2 17:44 18:21 20:48 23:1201 24:1708 27:1853 31:1521 32:38 33:2 34:5 35:3 36:116 37:1896 38:1012 39:9 40:246 41:2981 42:262 43:1239 44:26 45:377 46:2116 47:38 49:847 50:794 52:12 54:72 55:4 56:8 57:36 58:1216 59:682 60:467 61:1749 62:1338 63:1908 64:4458 65:2257 66:4129 67:2062 68:1074 69:3265 70:961 71:441 72:1959 74:2648 75:321 76:406 77:1455 78:1204 79:798 80:1315 81:1355 82:820 83:686 84:678 85:1374 86:376 87:1072 88:511 89:1808 90:151 91:6001 92:825 93:2189 94:1970 95:2083 96:430 97:349 98:1065 99:47 100:67 101:819 103:7140 104:1497 105:61 106:226 107:929 108:620 109:2020 110:1079 111:1489 112:773 113:1067 114:809 115:1260 116:1353 117:1002 118:1721 119:1447 120:448 121:1036 122:2192 123:1736 124:1498 125:1585 128:566 129:380 130:387 131:1174 132:492 133:173 134:419 135:109 136:304 137:314 138:596 139:161 140:240 141:415 142:669 143:503 144:569 145:108 146:715 147:590 148:1111 149:431 150:552 151:604 152:492 153:240 154:444 155:745 156:407 157:335 158:319 159:979 160:373 161:642 162:1956 163:424 164:664 165:687 166:287 167:806 168:1279 169:161 170:1450 171:241 172:41 173:1548 174:696 175:664 176:1369 177:3773 178:2068 179:893 180:1931 181:1653 182:1729 183:618 184:738 185:3243 186:2643 187:1797 188:2017 189:1570 190:7628 191:920 192:8242 193:5592 194:4114 195:3668 196:1705 197:1093 198:5527 199:5525 200:6522 201:3016 202:9464 203:9078 204:4691 205:2834 206:3089 207:3010 208:3942 209:3975 210:3516 211:1863 212:2466 213:2287 214:855 215:71 216:5600 217:1800 218:675 219:453 220:1436 221:788 222:464 223:659 End of report -------------- next part -------------- _______________________________________________ afnog mailing list https://www.afnog.org/mailman/listinfo/afnog From Steve.Mikulasik at civeo.com Mon Apr 13 21:51:13 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Mon, 13 Apr 2015 21:51:13 +0000 Subject: Cisco Routers Vulnerability In-Reply-To: References: Message-ID: They may want to check if some network engineer got fired recently. Usually these sorts of things relate to a human problem rather than a technical attack. Stephen Mikulasik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rashed Alwarrag Sent: Monday, April 13, 2015 3:29 PM To: nanog at nanog.org Subject: Cisco Routers Vulnerability Hi Today we have a lot of customers report that their Cisco routers got a root access and the IOS got erased , is there any known vulnerability in cisco products thats they report in their Security alerts about this recently ? is there any one face the same issue ? Regards From dciccaro at cisco.com Mon Apr 13 22:42:01 2015 From: dciccaro at cisco.com (Dario Ciccarone) Date: Mon, 13 Apr 2015 18:42:01 -0400 Subject: About the thread "Cisco Routers Vulnerability" Message-ID: <552C4639.1080403@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rashed, NANOG members: Hi there. My name is Dario Ciccarone and I work as an Incident Manager on the Cisco PSIRT - the Product Security Incident Response Team. We saw your email to the NANOG list, with the subject "Cisco Routers Vulnerability". At this time, we're not aware of any attempts to exploit either a known or previously unknown vulnerability on any Cisco devices running Cisco IOS, Cisco IOS XE, Cisco IOS XR, Cisco NX-OS or any other Cisco operating systems. We invite you to follow-up with us directly by emailing the PSIRT alias, or by using any of the mechanisms listed at the following URL: http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html#roosfassv Thanks, Dario Dario Ciccarone Incident Manager - CCIE #10395 Product Security Incident Response Team (PSIRT) Cisco Systems, Inc. PGP Key ID: 0xBA1AE0F0 http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUsRjcACgkQjJUYH7oa4PD5WwCcCk0l6bxnLEuBu4q0rwb7CLMU jXQAnjgvDscnF8hHBhRWB5o8iHALDmsu =dg/d -----END PGP SIGNATURE----- From kmedcalf at dessus.com Mon Apr 13 23:03:02 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 13 Apr 2015 17:03:02 -0600 Subject: Cisco Routers Vulnerability In-Reply-To: <552C3B4B.9010804@foobar.org> Message-ID: <2e048634d4280f40836c95f1aa842903@mail.dessus.com> >> It's reported by different customers in different locations so I don't >> think it's password compromised >Have you checked? If the routers had vty access open (ssh or telnet) and >the passwords were easy to guess, then it's more likely that this was a >password compromise. You can test this out by getting a copy of one of >the configs and decrypting the access password. Or by asking your customers >whether their passwords were dictionary or simple words. or if mayhaps the passwords were listed on the list of passwords discussed a few days ago: 353040 sshpsycho_passwords.txt http://blogs.cisco.com/security/talos/sshpsychos Once a password list gets published the scripties will update their list of password to brute force with all the other password lists they can find. Hence lists that exceed 353,000 passwords and growing .. From will at willscorner.net Mon Apr 13 23:30:44 2015 From: will at willscorner.net (Will Dean) Date: Mon, 13 Apr 2015 19:30:44 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: Message-ID: <552C51A4.1080200@willscorner.net> Reddit started using CloudFlare late last year, so they should able to serve content up over v6. http://www.reddit.com/r/blog/comments/2ftv08/hell_its_about_time_reddit_now_supports_fullsite/ckcoww2 (http://www.redditblog.com/2014/09/hell-its-about-time-reddit-now-supports.html) > Christopher Morrow > April 13, 2015 at 5:22 PM > > good news! it's only really 3 places that need update, since reddit is > (still?) an amazon aws customer. > Ca By > April 13, 2015 at 5:20 PM > Good news (that i have not personally verified) ! > > Verizon, T-Mobile, Sprint, and AT&T all launched the Samsung Galaxy S6 > with > IPv6 on by default. > > Given the growth and importance of mobile to Internet, it is great to see > this progress from the mobile carriers. > > Just for those keeping score, of the top 10 Alexa website for the USA, > these major websites prefer IPv6 or prefer NAT44 / NAT64 from the mobile > networks > > 1. Google -- prefers IPv6 > 2. Facebook -- prefers IPv6 > 3. Youtube -- prefers IPv6 > 4. Amazon -- prefers NAT -- :( > 5. Yahoo! -- prefers IPv6 > 6. Wikipedia -- prefers IPv6 > 7. Twitter -- prefers NAT -- :( > 8. Ebay -- prefers NAT -- :( > 9. Linkedin -- prefers IPv6 > 10. Reddit -- prefers NAT -- :( > > Dear Amazon, Twitter, Ebay, and Reddit -- please consider this your > personal invitation to introduce IPv6 to your service. From ljb at merit.edu Tue Apr 14 00:07:44 2015 From: ljb at merit.edu (Larry J. Blunk) Date: Mon, 13 Apr 2015 20:07:44 -0400 (EDT) Subject: NANOG Mailman upgrade - Saturday, April 18th In-Reply-To: <401576844.4194541.1428969531098.JavaMail.zimbra@merit.edu> Message-ID: <1331816712.4194739.1428970064195.JavaMail.zimbra@merit.edu> The NANOG Mailman version will be upgraded on Saturday, April 18th at 7:00AM EDT. The new version supports wrapping emails which have strict DMARC enforcement set in order to prevent the emails from bouncing and causing members to be unsubscribed. We anticipate the upgrade to take no more than 15 minutes, during which time the NANOG mail server will not accept new messages. Any messages sent at this time should be queued and delivered after the server upgrade. Regards, Larry Blunk NANOG Communications Committee From morrowc.lists at gmail.com Tue Apr 14 01:02:40 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Apr 2015 21:02:40 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <552C51A4.1080200@willscorner.net> References: <552C51A4.1080200@willscorner.net> Message-ID: On Mon, Apr 13, 2015 at 7:30 PM, Will Dean wrote: > Reddit started using CloudFlare late last year, so they should able to > serve content up over v6. > nice! From jared at puck.nether.net Tue Apr 14 01:42:07 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 13 Apr 2015 21:42:07 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> Message-ID: > On Apr 13, 2015, at 9:02 PM, Christopher Morrow wrote: > > On Mon, Apr 13, 2015 at 7:30 PM, Will Dean wrote: > >> Reddit started using CloudFlare late last year, so they should able to >> serve content up over v6. >> > > nice! Sorry to rain on your parade: dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. www.reddit.com has no AAAA record From morrowc.lists at gmail.com Tue Apr 14 01:48:58 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Apr 2015 21:48:58 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> Message-ID: On Mon, Apr 13, 2015 at 9:42 PM, Jared Mauch wrote: > >> On Apr 13, 2015, at 9:02 PM, Christopher Morrow wrote: >> >> On Mon, Apr 13, 2015 at 7:30 PM, Will Dean wrote: >> >>> Reddit started using CloudFlare late last year, so they should able to >>> serve content up over v6. >>> >> >> nice! > > Sorry to rain on your parade: > > dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. > www.reddit.com has no AAAA record I think will meant that because: ;; QUESTION SECTION: ;www.reddit.com. IN A ;; ANSWER SECTION: www.reddit.com. 300 IN A 198.41.208.142 www.reddit.com. 300 IN A 198.41.208.143 ...lots more records... and: NetRange: 198.41.128.0 - 198.41.255.255 CIDR: 198.41.128.0/17 NetName: CLOUDFLARENET that 'clearly' reddit could have cloudflare serve the endpoint from an ipv6 address, and thus populate a AAAA in reddit.com's domain. maybe it's not that simple. From finn at finn.io Tue Apr 14 01:45:39 2015 From: finn at finn.io (Finn Herzfeld) Date: Mon, 13 Apr 2015 18:45:39 -0700 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> Message-ID: <552C7143.30404@finn.io> A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Tue Apr 14 01:59:44 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 13 Apr 2015 21:59:44 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> Message-ID: > On Apr 13, 2015, at 9:48 PM, Christopher Morrow wrote: > > that 'clearly' reddit could have cloudflare serve the endpoint from an > ipv6 address, and thus populate a AAAA in reddit.com's domain. > > maybe it's not that simple. Well, it usually really is but just like automation, ipv6 isn’t something that many people have broad experiences with, and don’t cut+paste quite as well as one would hope. There are also *Way* too many people who memorize IP addresses out there that have a harder time trying to store 128-bits in their memory vs 32-bits. They also don’t want to lose track of where that IPv4 packet came from, so don’t want a reverse proxy doing protocol tcp6 -> tcp4 mucking for them. eg: ATT wireless/mobility could have their proxy connect() to an ipv6 address vs ipv4 which my phone transits when on their network and the qname returns AAAA. This was my favorite thing when running a transparent proxy on my home network, it could turn all the traffic from hosts that might not naturally think of doing modprobe ipv6 and turned them into IPv6 requests. For those wondering, nearly 62% of VZ Wireless traffic is IPv6. http://www.worldipv6launch.org/measurements/ - Jared From sfrost at snowman.net Tue Apr 14 02:04:13 2015 From: sfrost at snowman.net (Stephen Frost) Date: Mon, 13 Apr 2015 22:04:13 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> Message-ID: <20150414020413.GS3663@tamriel.snowman.net> * Jared Mauch (jared at puck.nether.net) wrote: > For those wondering, nearly 62% of VZ Wireless traffic is IPv6. > > http://www.worldipv6launch.org/measurements/ I'm still wondering when they're going to teach the Verizon FIOS people about the IPv6 goodness... Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From morrowc.lists at gmail.com Tue Apr 14 02:10:01 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Apr 2015 22:10:01 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <20150414020413.GS3663@tamriel.snowman.net> References: <552C51A4.1080200@willscorner.net> <20150414020413.GS3663@tamriel.snowman.net> Message-ID: On Mon, Apr 13, 2015 at 10:04 PM, Stephen Frost wrote: > > I'm still wondering when they're going to teach the Verizon FIOS people > about the IPv6 goodness... probably never as they are different operating companies with different networks and network admins and monetary goals. From mpalmer at hezmatt.org Tue Apr 14 02:25:45 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 14 Apr 2015 12:25:45 +1000 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> Message-ID: <20150414022545.GF17406@hezmatt.org> On Mon, Apr 13, 2015 at 09:42:07PM -0400, Jared Mauch wrote: > > On Apr 13, 2015, at 9:02 PM, Christopher Morrow wrote: > > On Mon, Apr 13, 2015 at 7:30 PM, Will Dean wrote: > >> Reddit started using CloudFlare late last year, so they should able to > >> serve content up over v6. > > > > nice! > > Sorry to rain on your parade: > > dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. > www.reddit.com has no AAAA record "should be able to serve" != "are serving". - Matt -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From ryan at finnesey.com Tue Apr 14 03:10:51 2015 From: ryan at finnesey.com (Ryan Finnesey) Date: Tue, 14 Apr 2015 03:10:51 +0000 Subject: Nonprofits - Office 365 Message-ID: I apologize for the somewhat off topic post but I would assume some of you might get asked for tech advice from your favorite nonprofits or charity's. I am looking for nonprofits that would be able to make use of free Office 365 licenses and discounted Office 365 Pro Plus licenses at $2 each. This donation would also come with free consulting services to setup Office 365 and migrate any data. Cheers Ryan From jsklein at gmail.com Tue Apr 14 03:17:56 2015 From: jsklein at gmail.com (Joe Klein) Date: Mon, 13 Apr 2015 23:17:56 -0400 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <20150414022545.GF17406@hezmatt.org> References: <552C51A4.1080200@willscorner.net> <20150414022545.GF17406@hezmatt.org> Message-ID: Was in a meeting over 4 years ago, where the people from Verizon were claiming they would be rolling out IPv6 for FIOS in the following years. Still waiting. Can anyone confirm or deny that Verizon FIOS requires an upgrade to the ONT and router for its "FiOS Quantum" service in order to get IPv6? Joe Klein "Inveniam viam aut faciam" On Mon, Apr 13, 2015 at 10:25 PM, Matt Palmer wrote: > On Mon, Apr 13, 2015 at 09:42:07PM -0400, Jared Mauch wrote: > > > On Apr 13, 2015, at 9:02 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > > > On Mon, Apr 13, 2015 at 7:30 PM, Will Dean > wrote: > > >> Reddit started using CloudFlare late last year, so they should able to > > >> serve content up over v6. > > > > > > nice! > > > > Sorry to rain on your parade: > > > > dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. > > www.reddit.com has no AAAA record > > "should be able to serve" != "are serving". > > - Matt > > -- > If you are a trauma surgeon and someone dies on your table, [...] everyone > would know you "did your best". When someone does something truly stupid > with their system and it dies and you can't resuscitate it, you must be > incompetent or an idiot. -- Julian Macassey, in the Monastery > > From nanog at shankland.org Tue Apr 14 03:32:06 2015 From: nanog at shankland.org (Jim Shankland) Date: Mon, 13 Apr 2015 20:32:06 -0700 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> <20150414022545.GF17406@hezmatt.org> Message-ID: <552C8A36.8070509@shankland.org> On 4/13/15 8:17 PM, Joe Klein wrote: > Was in a meeting over 4 years ago, where the people from Verizon were > claiming they would be rolling out IPv6 for FIOS in the following years. > Still waiting. > > C For those of us of a certain age, I'm wondering: what was the year when you first heard that the entire Internet was going to be switching over to IPv6 Real Soon Now? I distinctly remember my first time (who ever forgets?). I'm a little hazy on the exact year, but I know it started with a "1". Jim From streiner at cluebyfour.org Tue Apr 14 03:39:55 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 13 Apr 2015 23:39:55 -0400 (EDT) Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <20150414020413.GS3663@tamriel.snowman.net> References: <552C51A4.1080200@willscorner.net> <20150414020413.GS3663@tamriel.snowman.net> Message-ID: On Mon, 13 Apr 2015, Stephen Frost wrote: > I'm still wondering when they're going to teach the Verizon FIOS people > about the IPv6 goodness... I've been barking up that three for nearly the past three years. No definite answers thus far, other than the ONTs deployed in many customer locations might make IPv6 deployment a bit of a PITA, regardless of which model router you have on site. Trying to get good answers on this from VZ sales/marketing contacts through $dayjob has not gotten much in the way of good answers either. I have a v6 tunnel through Hurricane Electric that works very well, but it would be nice to go native. jms From bzeeb-lists at lists.zabbadoz.net Tue Apr 14 07:42:30 2015 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue, 14 Apr 2015 07:42:30 +0000 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> Message-ID: <1FC6D8D7-36C6-4A6E-ABD3-2C725D443FC3@lists.zabbadoz.net> > On 14 Apr 2015, at 01:59 , Jared Mauch wrote: > > For those wondering, nearly 62% of VZ Wireless traffic is IPv6. to a few select websites (not in term of overall traffic). > http://www.worldipv6launch.org/measurements/ From colinj at gt86car.org.uk Tue Apr 14 12:36:11 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 14 Apr 2015 13:36:11 +0100 Subject: macomnet weird dns record In-Reply-To: <5526A965.5040106@sonn.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> Message-ID: never saw hex in host dns records before. host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net range is blocked non the less since bad traffic from Russia network ranges. Colin From shopik at inblock.ru Tue Apr 14 13:09:42 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 16:09:42 +0300 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> Message-ID: <552D1196.2000408@inblock.ru> How its weird? All these chars allowed in DNS records. On 14/04/15 15:36, Colin Johnston wrote: > never saw hex in host dns records before. > host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net > > range is blocked non the less since bad traffic from Russia network ranges. > > Colin > From ahebert at pubnix.net Tue Apr 14 13:11:43 2015 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 14 Apr 2015 09:11:43 -0400 Subject: Cisco Routers Vulnerability In-Reply-To: References: Message-ID: <552D120F.1060200@pubnix.net> Well, Its not like peoples are still using telnet/ssh/web with a password/enable on the net... anymore. We do PCI and it took the better part of 6 month for a Customer Network Engineer to get it right. ( The annoying part is that we cannot do the work for them, we can only hope they get a paper cut every time we sent out a report about that security risk ) But I'm still curious what was the attack vector... As for my ~20ish Cisco device in the wild, they're all pretty healthy. ----- 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/15 17:51, Steve Mikulasik wrote: > They may want to check if some network engineer got fired recently. Usually these sorts of things relate to a human problem rather than a technical attack. > > Stephen Mikulasik > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rashed Alwarrag > Sent: Monday, April 13, 2015 3:29 PM > To: nanog at nanog.org > Subject: Cisco Routers Vulnerability > > Hi > Today we have a lot of customers report that their Cisco routers got a root access and the IOS got erased , is there any known vulnerability in cisco products thats they report in their Security alerts about this recently ? > is there any one face the same issue ? > > Regards > From bortzmeyer at nic.fr Tue Apr 14 13:19:55 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 14 Apr 2015 15:19:55 +0200 Subject: macomnet weird dns record In-Reply-To: <552D1196.2000408@inblock.ru> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: <20150414131954.GA20725@nic.fr> On Tue, Apr 14, 2015 at 04:09:42PM +0300, Nikolay Shopik wrote a message of 10 lines which said: > How its weird? All these chars allowed in DNS records. And they probably encode the netmask, which may be useful. From colinj at gt86car.org.uk Tue Apr 14 13:26:48 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 14 Apr 2015 14:26:48 +0100 Subject: macomnet weird dns record In-Reply-To: <552D1196.2000408@inblock.ru> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: Because looks strange especially if the traffic is 100% bad Best practice says avoid such info in records as does not aid debug since mix of dec and hex Colin > On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: > > How its weird? All these chars allowed in DNS records. > > On 14/04/15 15:36, Colin Johnston wrote: >> never saw hex in host dns records before. >> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >> >> range is blocked non the less since bad traffic from Russia network ranges. >> >> Colin >> From bortzmeyer at nic.fr Tue Apr 14 13:44:09 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 14 Apr 2015 15:44:09 +0200 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: <20150414134409.GA26101@nic.fr> On Tue, Apr 14, 2015 at 02:26:48PM +0100, Colin Johnston wrote a message of 19 lines which said: > Best practice says avoid such info in records as does not aid debug > since mix of dec and hex No. Pure imagination on your side. There is no such "best practice". And it's not hex or dec, it is letters and digits. From chuckchurch at gmail.com Tue Apr 14 13:45:00 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 14 Apr 2015 09:45:00 -0400 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: <002601d076b9$35c40310$a14c0930$@gmail.com> Comic Book Guy would probably declare: "Worst Naming Convention Ever" Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston Sent: Tuesday, April 14, 2015 9:27 AM To: Nikolay Shopik Cc: Subject: Re: macomnet weird dns record Because looks strange especially if the traffic is 100% bad Best practice says avoid such info in records as does not aid debug since mix of dec and hex Colin > On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: > > How its weird? All these chars allowed in DNS records. > > On 14/04/15 15:36, Colin Johnston wrote: >> never saw hex in host dns records before. >> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >> >> range is blocked non the less since bad traffic from Russia network ranges. >> >> Colin >> From shopik at inblock.ru Tue Apr 14 13:48:56 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 16:48:56 +0300 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: <552D1AC8.7010108@inblock.ru> Then best practice, that naming should be helpful for owners of network in first place and only afterwards everyone else. On 14/04/15 16:26, Colin Johnston wrote: > Because looks strange especially if the traffic is 100% bad > Best practice says avoid such info in records as does not aid debug since mix of dec and hex > > Colin > >> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >> >> How its weird? All these chars allowed in DNS records. >> >> On 14/04/15 15:36, Colin Johnston wrote: >>> never saw hex in host dns records before. >>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>> >>> range is blocked non the less since bad traffic from Russia network ranges. >>> >>> Colin >>> > From colinj at gt86car.org.uk Tue Apr 14 13:51:24 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 14 Apr 2015 14:51:24 +0100 Subject: macomnet weird dns record In-Reply-To: <552D1AC8.7010108@inblock.ru> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <552D1AC8.7010108@inblock.ru> Message-ID: Get real, why make is hard for others to debug abuse issues, another reason why blocks in place as no technical cooperation. Colin > On 14 Apr 2015, at 14:48, Nikolay Shopik wrote: > > Then best practice, that naming should be helpful for owners of network > in first place and only afterwards everyone else. > > On 14/04/15 16:26, Colin Johnston wrote: >> Because looks strange especially if the traffic is 100% bad >> Best practice says avoid such info in records as does not aid debug since mix of dec and hex >> >> Colin >> >>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>> >>> How its weird? All these chars allowed in DNS records. >>> >>> On 14/04/15 15:36, Colin Johnston wrote: >>>> never saw hex in host dns records before. >>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>> >>>> range is blocked non the less since bad traffic from Russia network ranges. >>>> >>>> Colin >>>> >> From shopik at inblock.ru Tue Apr 14 13:54:23 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 16:54:23 +0300 Subject: macomnet weird dns record In-Reply-To: <002601d076b9$35c40310$a14c0930$@gmail.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> Message-ID: <552D1C0F.9010701@inblock.ru> Are Roman numerals allowed in DNS? Because I know some people also do them. dig -x 217.199.208.190 On 14/04/15 16:45, Chuck Church wrote: > Comic Book Guy would probably declare: > > "Worst Naming Convention Ever" > > Chuck > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston > Sent: Tuesday, April 14, 2015 9:27 AM > To: Nikolay Shopik > Cc: > Subject: Re: macomnet weird dns record > > Because looks strange especially if the traffic is 100% bad Best practice > says avoid such info in records as does not aid debug since mix of dec and > hex > > Colin > >> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >> >> How its weird? All these chars allowed in DNS records. >> >> On 14/04/15 15:36, Colin Johnston wrote: >>> never saw hex in host dns records before. >>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>> >>> range is blocked non the less since bad traffic from Russia network > ranges. >>> >>> Colin >>> > From pavel.odintsov at gmail.com Tue Apr 14 14:00:25 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 14 Apr 2015 17:00:25 +0300 Subject: macomnet weird dns record In-Reply-To: <552D1C0F.9010701@inblock.ru> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> Message-ID: Hello! What about IDN encoded PTR records? I sure it's nice idea and I will implement they in my network shortly. On Tue, Apr 14, 2015 at 4:54 PM, Nikolay Shopik wrote: > Are Roman numerals allowed in DNS? Because I know some people also do them. > > dig -x 217.199.208.190 > > > On 14/04/15 16:45, Chuck Church wrote: >> Comic Book Guy would probably declare: >> >> "Worst Naming Convention Ever" >> >> Chuck >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston >> Sent: Tuesday, April 14, 2015 9:27 AM >> To: Nikolay Shopik >> Cc: >> Subject: Re: macomnet weird dns record >> >> Because looks strange especially if the traffic is 100% bad Best practice >> says avoid such info in records as does not aid debug since mix of dec and >> hex >> >> Colin >> >>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>> >>> How its weird? All these chars allowed in DNS records. >>> >>> On 14/04/15 15:36, Colin Johnston wrote: >>>> never saw hex in host dns records before. >>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>> >>>> range is blocked non the less since bad traffic from Russia network >> ranges. >>>> >>>> Colin >>>> >> -- Sincerely yours, Pavel Odintsov From colinj at gt86car.org.uk Tue Apr 14 14:00:26 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 14 Apr 2015 15:00:26 +0100 Subject: macomnet weird dns record In-Reply-To: <552D1C0F.9010701@inblock.ru> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> Message-ID: <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry. At least there is communication on some level, Chinese colleagues would not even bother to respond to aid debug. Be that as it may, why not use either normal decimal numbers or normal characters to show what a normal person would understand instead of having to convert the shown output ? Colin > On 14 Apr 2015, at 14:54, Nikolay Shopik wrote: > > Are Roman numerals allowed in DNS? Because I know some people also do them. > > dig -x 217.199.208.190 > > > On 14/04/15 16:45, Chuck Church wrote: >> Comic Book Guy would probably declare: >> >> "Worst Naming Convention Ever" >> >> Chuck >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston >> Sent: Tuesday, April 14, 2015 9:27 AM >> To: Nikolay Shopik >> Cc: >> Subject: Re: macomnet weird dns record >> >> Because looks strange especially if the traffic is 100% bad Best practice >> says avoid such info in records as does not aid debug since mix of dec and >> hex >> >> Colin >> >>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>> >>> How its weird? All these chars allowed in DNS records. >>> >>> On 14/04/15 15:36, Colin Johnston wrote: >>>> never saw hex in host dns records before. >>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>> >>>> range is blocked non the less since bad traffic from Russia network >> ranges. >>>> >>>> Colin >>>> >> From niels=nanog at bakker.net Tue Apr 14 14:08:05 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 14 Apr 2015 16:08:05 +0200 Subject: macomnet weird dns record In-Reply-To: <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Message-ID: <20150414140805.GA3166@excession.tpb.net> * colinj at gt86car.org.uk (Colin Johnston) [Tue 14 Apr 2015, 16:05 CEST]: >Be that as it may, why not use either normal decimal numbers or >normal characters to show what a normal person would understand >instead of having to convert the shown output ? I actually thought it was quite clever and the implied meaning was pretty clear to me (with the caveat that I'm probably not the intended audience, which would be their own NOC during troubleshooting). -- Niels. From pavel.odintsov at gmail.com Tue Apr 14 14:09:48 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 14 Apr 2015 17:09:48 +0300 Subject: macomnet weird dns record In-Reply-To: <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Message-ID: Hello, Colin! We use hexademical numbers in PTR for VPS/Servers because PTR's like "host-87.118.199.240.domain.ru" so often banned by weird antispam systems by mask \d+\.\d+\.\d+\d+ as home ISP subnets which produce bunch of spam. On Tue, Apr 14, 2015 at 5:00 PM, Colin Johnston wrote: > Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry. > At least there is communication on some level, Chinese colleagues would not even bother to respond to aid debug. > > Be that as it may, why not use either normal decimal numbers or normal characters to show what a normal person would understand instead of having to convert the shown output ? > > Colin > > >> On 14 Apr 2015, at 14:54, Nikolay Shopik wrote: >> >> Are Roman numerals allowed in DNS? Because I know some people also do them. >> >> dig -x 217.199.208.190 >> >> >> On 14/04/15 16:45, Chuck Church wrote: >>> Comic Book Guy would probably declare: >>> >>> "Worst Naming Convention Ever" >>> >>> Chuck >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston >>> Sent: Tuesday, April 14, 2015 9:27 AM >>> To: Nikolay Shopik >>> Cc: >>> Subject: Re: macomnet weird dns record >>> >>> Because looks strange especially if the traffic is 100% bad Best practice >>> says avoid such info in records as does not aid debug since mix of dec and >>> hex >>> >>> Colin >>> >>>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>>> >>>> How its weird? All these chars allowed in DNS records. >>>> >>>> On 14/04/15 15:36, Colin Johnston wrote: >>>>> never saw hex in host dns records before. >>>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>>> >>>>> range is blocked non the less since bad traffic from Russia network >>> ranges. >>>>> >>>>> Colin >>>>> >>> > -- Sincerely yours, Pavel Odintsov From shopik at inblock.ru Tue Apr 14 14:10:33 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 17:10:33 +0300 Subject: macomnet weird dns record In-Reply-To: <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Message-ID: <552D1FD9.2030206@inblock.ru> Hi Colin, Well some people get creative when creating PTR records. Maybe they really want encode something like netmask as Stephane said to provide some additional info for their own helpdek? Chinese don't bother for multiply reasons, same probably apply to Russian part net, cheap Internet access. So when you asking them to fix bad traffic coming from home user they don't bother do anything with it as it cost money for them. On 14/04/15 17:00, Colin Johnston wrote: > Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry. > At least there is communication on some level, Chinese colleagues would not even bother to respond to aid debug. > > Be that as it may, why not use either normal decimal numbers or normal characters to show what a normal person would understand instead of having to convert the shown output ? > > Colin > > >> On 14 Apr 2015, at 14:54, Nikolay Shopik wrote: >> >> Are Roman numerals allowed in DNS? Because I know some people also do them. >> >> dig -x 217.199.208.190 >> >> >> On 14/04/15 16:45, Chuck Church wrote: >>> Comic Book Guy would probably declare: >>> >>> "Worst Naming Convention Ever" >>> >>> Chuck >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston >>> Sent: Tuesday, April 14, 2015 9:27 AM >>> To: Nikolay Shopik >>> Cc: >>> Subject: Re: macomnet weird dns record >>> >>> Because looks strange especially if the traffic is 100% bad Best practice >>> says avoid such info in records as does not aid debug since mix of dec and >>> hex >>> >>> Colin >>> >>>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>>> >>>> How its weird? All these chars allowed in DNS records. >>>> >>>> On 14/04/15 15:36, Colin Johnston wrote: >>>>> never saw hex in host dns records before. >>>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>>> >>>>> range is blocked non the less since bad traffic from Russia network >>> ranges. >>>>> >>>>> Colin >>>>> >>> > From shopik at inblock.ru Tue Apr 14 14:17:05 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 17:17:05 +0300 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> Message-ID: <552D2161.9060305@inblock.ru> This is probably worse then hexadecimal PTR records :). No traceroute actually convert punycode, so why bother? As it usually intended audience already know how to read English letters. On 14/04/15 17:00, Pavel Odintsov wrote: > What about IDN encoded PTR records? I sure it's nice idea and I will > implement they in my network shortly. From wwaites at tardis.ed.ac.uk Tue Apr 14 14:21:22 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Tue, 14 Apr 2015 15:21:22 +0100 (BST) Subject: macomnet weird dns record In-Reply-To: <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> References: <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Message-ID: <20150414.152122.1067354933566848004.wwaites@tardis.ed.ac.uk> Colin, I understand that you would like everyone on the Internet to behave in a way that you consider normal and tailor their reverse DNS so as not to offend your aesthetic sense. It is frustrating when other people do things differently, my deepest sympathies. Also if you have ever used a BSD system you will know that writing netmasks in hex is prefectly normal. -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh http://www.hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From colinj at gt86car.org.uk Tue Apr 14 14:34:15 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 14 Apr 2015 15:34:15 +0100 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Message-ID: so fix the spam hosts, don’t mask the problem and make more complicated for folks trying their best to solve Colin > On 14 Apr 2015, at 15:09, Pavel Odintsov wrote: > > Hello, Colin! > > We use hexademical numbers in PTR for VPS/Servers because PTR's like > "host-87.118.199.240.domain.ru" so often banned by weird antispam > systems by mask \d+\.\d+\.\d+\d+ as home ISP subnets which produce > bunch of spam. > > > > On Tue, Apr 14, 2015 at 5:00 PM, Colin Johnston wrote: >> Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry. >> At least there is communication on some level, Chinese colleagues would not even bother to respond to aid debug. >> >> Be that as it may, why not use either normal decimal numbers or normal characters to show what a normal person would understand instead of having to convert the shown output ? >> >> Colin >> >> >>> On 14 Apr 2015, at 14:54, Nikolay Shopik wrote: >>> >>> Are Roman numerals allowed in DNS? Because I know some people also do them. >>> >>> dig -x 217.199.208.190 >>> >>> >>> On 14/04/15 16:45, Chuck Church wrote: >>>> Comic Book Guy would probably declare: >>>> >>>> "Worst Naming Convention Ever" >>>> >>>> Chuck >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston >>>> Sent: Tuesday, April 14, 2015 9:27 AM >>>> To: Nikolay Shopik >>>> Cc: >>>> Subject: Re: macomnet weird dns record >>>> >>>> Because looks strange especially if the traffic is 100% bad Best practice >>>> says avoid such info in records as does not aid debug since mix of dec and >>>> hex >>>> >>>> Colin >>>> >>>>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>>>> >>>>> How its weird? All these chars allowed in DNS records. >>>>> >>>>> On 14/04/15 15:36, Colin Johnston wrote: >>>>>> never saw hex in host dns records before. >>>>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>>>> >>>>>> range is blocked non the less since bad traffic from Russia network >>>> ranges. >>>>>> >>>>>> Colin >>>>>> >>>> >> > > > > -- > Sincerely yours, Pavel Odintsov From pavel.odintsov at gmail.com Tue Apr 14 14:35:33 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 14 Apr 2015 17:35:33 +0300 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Message-ID: But I'm not a spam source. I banned for netmask which similar to ISP subnet. On Tue, Apr 14, 2015 at 5:34 PM, Colin Johnston wrote: > so fix the spam hosts, don’t mask the problem and make more complicated for folks trying their best to solve > > Colin > >> On 14 Apr 2015, at 15:09, Pavel Odintsov wrote: >> >> Hello, Colin! >> >> We use hexademical numbers in PTR for VPS/Servers because PTR's like >> "host-87.118.199.240.domain.ru" so often banned by weird antispam >> systems by mask \d+\.\d+\.\d+\d+ as home ISP subnets which produce >> bunch of spam. >> >> >> >> On Tue, Apr 14, 2015 at 5:00 PM, Colin Johnston wrote: >>> Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry. >>> At least there is communication on some level, Chinese colleagues would not even bother to respond to aid debug. >>> >>> Be that as it may, why not use either normal decimal numbers or normal characters to show what a normal person would understand instead of having to convert the shown output ? >>> >>> Colin >>> >>> >>>> On 14 Apr 2015, at 14:54, Nikolay Shopik wrote: >>>> >>>> Are Roman numerals allowed in DNS? Because I know some people also do them. >>>> >>>> dig -x 217.199.208.190 >>>> >>>> >>>> On 14/04/15 16:45, Chuck Church wrote: >>>>> Comic Book Guy would probably declare: >>>>> >>>>> "Worst Naming Convention Ever" >>>>> >>>>> Chuck >>>>> >>>>> -----Original Message----- >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston >>>>> Sent: Tuesday, April 14, 2015 9:27 AM >>>>> To: Nikolay Shopik >>>>> Cc: >>>>> Subject: Re: macomnet weird dns record >>>>> >>>>> Because looks strange especially if the traffic is 100% bad Best practice >>>>> says avoid such info in records as does not aid debug since mix of dec and >>>>> hex >>>>> >>>>> Colin >>>>> >>>>>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>>>>> >>>>>> How its weird? All these chars allowed in DNS records. >>>>>> >>>>>> On 14/04/15 15:36, Colin Johnston wrote: >>>>>>> never saw hex in host dns records before. >>>>>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>>>>> >>>>>>> range is blocked non the less since bad traffic from Russia network >>>>> ranges. >>>>>>> >>>>>>> Colin >>>>>>> >>>>> >>> >> >> >> >> -- >> Sincerely yours, Pavel Odintsov > -- Sincerely yours, Pavel Odintsov From colinj at gt86car.org.uk Tue Apr 14 14:37:23 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 14 Apr 2015 15:37:23 +0100 Subject: macomnet weird dns record In-Reply-To: <552D1FD9.2030206@inblock.ru> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> <552D1FD9.2030206@inblock.ru> Message-ID: <85A80A03-0861-4D2E-BE8F-85BA7C9FB648@gt86car.org.uk> costs more money in long term not fixing the bad traffic as have to spend more for transit doing the bother and fixing the problem is best practice Colin > Chinese don't bother for multiply reasons, same probably apply to > Russian part net, cheap Internet access. So when you asking them to fix > bad traffic coming from home user they don't bother do anything with it > as it cost money for them. > > On 14/04/15 17:00, Colin Johnston wrote: >> Hi Nikolay, I have obvious hit a cultural nerve here, if so I am sorry. >> At least there is communication on some level, Chinese colleagues would not even bother to respond to aid debug. >> >> Be that as it may, why not use either normal decimal numbers or normal characters to show what a normal person would understand instead of having to convert the shown output ? >> >> Colin >> >> >>> On 14 Apr 2015, at 14:54, Nikolay Shopik wrote: >>> >>> Are Roman numerals allowed in DNS? Because I know some people also do them. >>> >>> dig -x 217.199.208.190 >>> >>> >>> On 14/04/15 16:45, Chuck Church wrote: >>>> Comic Book Guy would probably declare: >>>> >>>> "Worst Naming Convention Ever" >>>> >>>> Chuck >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston >>>> Sent: Tuesday, April 14, 2015 9:27 AM >>>> To: Nikolay Shopik >>>> Cc: >>>> Subject: Re: macomnet weird dns record >>>> >>>> Because looks strange especially if the traffic is 100% bad Best practice >>>> says avoid such info in records as does not aid debug since mix of dec and >>>> hex >>>> >>>> Colin >>>> >>>>> On 14 Apr 2015, at 14:09, Nikolay Shopik wrote: >>>>> >>>>> How its weird? All these chars allowed in DNS records. >>>>> >>>>> On 14/04/15 15:36, Colin Johnston wrote: >>>>>> never saw hex in host dns records before. >>>>>> host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net >>>>>> >>>>>> range is blocked non the less since bad traffic from Russia network >>>> ranges. >>>>>> >>>>>> Colin >>>>>> >>>> >> From jesler at cisco.com Tue Apr 14 11:16:42 2015 From: jesler at cisco.com (Joel Esler (jesler)) Date: Tue, 14 Apr 2015 11:16:42 +0000 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> <20150414022545.GF17406@hezmatt.org>, Message-ID: <565F426F-3786-43FF-A9C8-16BC0EC3D54E@cisco.com> I don't believe Quantum has any changes relative to the external of the house. Fios has been capable of pushing those speeds with the "old" modem for years. The difference between the old modem and the new one is that the wireless is 802.11n whereas the old one was only capable of g. -- Joel Esler Sent from my iPhone On Apr 13, 2015, at 11:20 PM, Joe Klein > wrote: Was in a meeting over 4 years ago, where the people from Verizon were claiming they would be rolling out IPv6 for FIOS in the following years. Still waiting. Can anyone confirm or deny that Verizon FIOS requires an upgrade to the ONT and router for its "FiOS Quantum" service in order to get IPv6? Joe Klein "Inveniam viam aut faciam" On Mon, Apr 13, 2015 at 10:25 PM, Matt Palmer > wrote: On Mon, Apr 13, 2015 at 09:42:07PM -0400, Jared Mauch wrote: On Apr 13, 2015, at 9:02 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: On Mon, Apr 13, 2015 at 7:30 PM, Will Dean > wrote: Reddit started using CloudFlare late last year, so they should able to serve content up over v6. nice! Sorry to rain on your parade: dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. www.reddit.com has no AAAA record "should be able to serve" != "are serving". - Matt -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From shopik at inblock.ru Tue Apr 14 14:47:43 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 17:47:43 +0300 Subject: macomnet weird dns record In-Reply-To: <85A80A03-0861-4D2E-BE8F-85BA7C9FB648@gt86car.org.uk> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> <552D1FD9.2030206@inblock.ru> <85A80A03-0861-4D2E-BE8F-85BA7C9FB648@gt86car.org.uk> Message-ID: <552D288F.80302@inblock.ru> Transit traffic isn't issue, as upload/download ratio usually 1:2 or more. As I said before when you already on edge of your profits, you don't bother fixing these clients. Its not about best practice which I agree, but business you are running, which is suppose to be profitable. And fixing these bad machines doesn't give you any profits. On 14/04/15 17:37, Colin Johnston wrote: > costs more money in long term not fixing the bad traffic as have to spend more for transit > > doing the bother and fixing the problem is best practice > > Colin From colinj at gt86car.org.uk Tue Apr 14 14:58:33 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 14 Apr 2015 15:58:33 +0100 Subject: macomnet weird dns record In-Reply-To: <552D288F.80302@inblock.ru> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> <552D1FD9.2030206@inblock.ru> <85A80A03-0861-4D2E-BE8F-85BA7C9FB648@gt86car.org.uk> <552D288F.80302@inblock.ru> Message-ID: <5B9D1935-E5C1-466B-9351-D78AA92F68B4@gt86car.org.uk> There becomes a point though that doing nothing allows larger problems which could have been nipped in the bud if sorted when issue was a smaller magnitude. Profit when there is known bad traffic as a percentage and you known ignore it is bad profit and does not help the greater good. most folks would welcome help if they know network would be more reliable and faster without the bad traffic always being present. Colin > On 14 Apr 2015, at 15:47, Nikolay Shopik wrote: > > Transit traffic isn't issue, as upload/download ratio usually 1:2 or more. > > As I said before when you already on edge of your profits, you don't > bother fixing these clients. Its not about best practice which I agree, > but business you are running, which is suppose to be profitable. And > fixing these bad machines doesn't give you any profits. > > On 14/04/15 17:37, Colin Johnston wrote: >> costs more money in long term not fixing the bad traffic as have to spend more for transit >> >> doing the bother and fixing the problem is best practice >> >> Colin From Rod.Beck at hibernianetworks.com Tue Apr 14 15:05:32 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Tue, 14 Apr 2015 15:05:32 +0000 Subject: macomnet weird dns record In-Reply-To: <5B9D1935-E5C1-466B-9351-D78AA92F68B4@gt86car.org.uk> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> <552D1FD9.2030206@inblock.ru> <85A80A03-0861-4D2E-BE8F-85BA7C9FB648@gt86car.org.uk> <552D288F.80302@inblock.ru>, <5B9D1935-E5C1-466B-9351-D78AA92F68B4@gt86car.org.uk> Message-ID: <1429020326192.58235@hibernianetworks.com> Sounds like a textbook economics case of a network externality. The benefit to the provider is far less than the benefit to the entire affected community. Private benefit is less than social (sum of private benefits across all affected parties) benefit. Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.beck at hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From shopik at inblock.ru Tue Apr 14 15:08:48 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 18:08:48 +0300 Subject: macomnet weird dns record In-Reply-To: <5B9D1935-E5C1-466B-9351-D78AA92F68B4@gt86car.org.uk> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> <552D1FD9.2030206@inblock.ru> <85A80A03-0861-4D2E-BE8F-85BA7C9FB648@gt86car.org.uk> <552D288F.80302@inblock.ru> <5B9D1935-E5C1-466B-9351-D78AA92F68B4@gt86car.org.uk> Message-ID: <552D2D80.3030900@inblock.ru> User complain that his network slow and reliable. Check if its saturated his link and tell him buy additional 10mbps/s, here is your profit. If you really want fight bots, you need to track down and fight C&C in first place. Otherwise you are fighting windmills. http://arstechnica.com/tech-policy/2011/05/a-way-to-take-out-spammers-3-banks-process-95-of-spam-transactions/ On 14/04/15 17:58, Colin Johnston wrote: > most folks would welcome help if they know network would be more reliable and faster without the bad traffic always being present. From mhuff at ox.com Tue Apr 14 15:11:19 2015 From: mhuff at ox.com (Matthew Huff) Date: Tue, 14 Apr 2015 15:11:19 +0000 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <565F426F-3786-43FF-A9C8-16BC0EC3D54E@cisco.com> References: <552C51A4.1080200@willscorner.net> <20150414022545.GF17406@hezmatt.org>, <565F426F-3786-43FF-A9C8-16BC0EC3D54E@cisco.com> Message-ID: <595edf8298914d349501eee874559a40@pur-vm-exch13n1.ox.com> The earlier generation of ONT has 100MB Ethernet and MOCA. If you upgrade to Quantum and order speeds > 100MB you'll need an ONT with gig-E and switch from MOCA to wired Ethernet. The MOCA standard specifies up to 175MB, but I don't think MOCA vendors have made any adapters > 100MB. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joel Esler (jesler) Sent: Tuesday, April 14, 2015 7:17 AM To: Joe Klein Cc: nanog at nanog.org Subject: Re: Galaxy S6 is IPv6 on all US National Mobile carriers I don't believe Quantum has any changes relative to the external of the house. Fios has been capable of pushing those speeds with the "old" modem for years. The difference between the old modem and the new one is that the wireless is 802.11n whereas the old one was only capable of g. -- Joel Esler Sent from my iPhone On Apr 13, 2015, at 11:20 PM, Joe Klein > wrote: Was in a meeting over 4 years ago, where the people from Verizon were claiming they would be rolling out IPv6 for FIOS in the following years. Still waiting. Can anyone confirm or deny that Verizon FIOS requires an upgrade to the ONT and router for its "FiOS Quantum" service in order to get IPv6? Joe Klein "Inveniam viam aut faciam" On Mon, Apr 13, 2015 at 10:25 PM, Matt Palmer > wrote: On Mon, Apr 13, 2015 at 09:42:07PM -0400, Jared Mauch wrote: On Apr 13, 2015, at 9:02 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: On Mon, Apr 13, 2015 at 7:30 PM, Will Dean > wrote: Reddit started using CloudFlare late last year, so they should able to serve content up over v6. nice! Sorry to rain on your parade: dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. www.reddit.com has no AAAA record "should be able to serve" != "are serving". - Matt -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From shopik at inblock.ru Tue Apr 14 15:12:47 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 14 Apr 2015 18:12:47 +0300 Subject: macomnet weird dns record In-Reply-To: <1429020326192.58235@hibernianetworks.com> References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> <552D1FD9.2030206@inblock.ru> <85A80A03-0861-4D2E-BE8F-85BA7C9FB648@gt86car.org.uk> <552D288F.80302@inblock.ru>, <5B9D1935-E5C1-466B-9351-D78AA92F68B4@gt86car.org.uk> <1429020326192.58235@hibernianetworks.com> Message-ID: <552D2E6F.30506@inblock.ru> Yep, last time I've checked and internet isn't running on communism. On 14/04/15 18:05, Rod Beck wrote: > Private benefit is less than social (sum of private benefits across all affected parties) benefit. From jesler at cisco.com Tue Apr 14 15:38:27 2015 From: jesler at cisco.com (Joel Esler (jesler)) Date: Tue, 14 Apr 2015 15:38:27 +0000 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <595edf8298914d349501eee874559a40@pur-vm-exch13n1.ox.com> References: <552C51A4.1080200@willscorner.net> <20150414022545.GF17406@hezmatt.org> <565F426F-3786-43FF-A9C8-16BC0EC3D54E@cisco.com> <595edf8298914d349501eee874559a40@pur-vm-exch13n1.ox.com> Message-ID: <078B9C88-9207-4909-99D3-439E9672C9B6@cisco.com> So am I correct in assuming that unless you go >100Mb, and other than the N router to replace the G router, there isn’t anything beneficial? -- Joel Esler Open Source Manager Threat Intelligence Team Lead Talos Group On Apr 14, 2015, at 11:11 AM, Matthew Huff > wrote: The earlier generation of ONT has 100MB Ethernet and MOCA. If you upgrade to Quantum and order speeds > 100MB you'll need an ONT with gig-E and switch from MOCA to wired Ethernet. The MOCA standard specifies up to 175MB, but I don't think MOCA vendors have made any adapters > 100MB. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joel Esler (jesler) Sent: Tuesday, April 14, 2015 7:17 AM To: Joe Klein Cc: nanog at nanog.org Subject: Re: Galaxy S6 is IPv6 on all US National Mobile carriers I don't believe Quantum has any changes relative to the external of the house. Fios has been capable of pushing those speeds with the "old" modem for years. The difference between the old modem and the new one is that the wireless is 802.11n whereas the old one was only capable of g. -- Joel Esler Sent from my iPhone On Apr 13, 2015, at 11:20 PM, Joe Klein > wrote: Was in a meeting over 4 years ago, where the people from Verizon were claiming they would be rolling out IPv6 for FIOS in the following years. Still waiting. Can anyone confirm or deny that Verizon FIOS requires an upgrade to the ONT and router for its "FiOS Quantum" service in order to get IPv6? Joe Klein "Inveniam viam aut faciam" On Mon, Apr 13, 2015 at 10:25 PM, Matt Palmer > wrote: On Mon, Apr 13, 2015 at 09:42:07PM -0400, Jared Mauch wrote: On Apr 13, 2015, at 9:02 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: On Mon, Apr 13, 2015 at 7:30 PM, Will Dean > wrote: Reddit started using CloudFlare late last year, so they should able to serve content up over v6. nice! Sorry to rain on your parade: dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. www.reddit.com has no AAAA record "should be able to serve" != "are serving". - Matt -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From mhuff at ox.com Tue Apr 14 15:45:34 2015 From: mhuff at ox.com (Matthew Huff) Date: Tue, 14 Apr 2015 15:45:34 +0000 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <078B9C88-9207-4909-99D3-439E9672C9B6@cisco.com> References: <552C51A4.1080200@willscorner.net> <20150414022545.GF17406@hezmatt.org> <565F426F-3786-43FF-A9C8-16BC0EC3D54E@cisco.com> <595edf8298914d349501eee874559a40@pur-vm-exch13n1.ox.com> <078B9C88-9207-4909-99D3-439E9672C9B6@cisco.com> Message-ID: <846dadd1fb5b457f81c0231c4e128e09@pur-vm-exch13n1.ox.com> It's much smaller J Other than that, I don't know of anything else. I don't use their router anyway. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 From: Joel Esler (jesler) [mailto:jesler at cisco.com] Sent: Tuesday, April 14, 2015 11:38 AM To: Matthew Huff Cc: Joe Klein; nanog at nanog.org Subject: Re: Galaxy S6 is IPv6 on all US National Mobile carriers So am I correct in assuming that unless you go >100Mb, and other than the N router to replace the G router, there isn't anything beneficial? -- Joel Esler Open Source Manager Threat Intelligence Team Lead Talos Group On Apr 14, 2015, at 11:11 AM, Matthew Huff > wrote: The earlier generation of ONT has 100MB Ethernet and MOCA. If you upgrade to Quantum and order speeds > 100MB you'll need an ONT with gig-E and switch from MOCA to wired Ethernet. The MOCA standard specifies up to 175MB, but I don't think MOCA vendors have made any adapters > 100MB. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joel Esler (jesler) Sent: Tuesday, April 14, 2015 7:17 AM To: Joe Klein Cc: nanog at nanog.org Subject: Re: Galaxy S6 is IPv6 on all US National Mobile carriers I don't believe Quantum has any changes relative to the external of the house. Fios has been capable of pushing those speeds with the "old" modem for years. The difference between the old modem and the new one is that the wireless is 802.11n whereas the old one was only capable of g. -- Joel Esler Sent from my iPhone On Apr 13, 2015, at 11:20 PM, Joe Klein > wrote: Was in a meeting over 4 years ago, where the people from Verizon were claiming they would be rolling out IPv6 for FIOS in the following years. Still waiting. Can anyone confirm or deny that Verizon FIOS requires an upgrade to the ONT and router for its "FiOS Quantum" service in order to get IPv6? Joe Klein "Inveniam viam aut faciam" On Mon, Apr 13, 2015 at 10:25 PM, Matt Palmer > wrote: On Mon, Apr 13, 2015 at 09:42:07PM -0400, Jared Mauch wrote: On Apr 13, 2015, at 9:02 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: On Mon, Apr 13, 2015 at 7:30 PM, Will Dean > wrote: Reddit started using CloudFlare late last year, so they should able to serve content up over v6. nice! Sorry to rain on your parade: dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. www.reddit.com has no AAAA record "should be able to serve" != "are serving". - Matt -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From Valdis.Kletnieks at vt.edu Tue Apr 14 15:57:12 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Apr 2015 11:57:12 -0400 Subject: macomnet weird dns record In-Reply-To: Your message of "Tue, 14 Apr 2015 14:26:48 +0100." References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: <4216.1429027032@turing-police.cc.vt.edu> On Tue, 14 Apr 2015 14:26:48 +0100, Colin Johnston said: > Best practice says avoid such info in records as does not aid debug since mix > of dec and hex Odd. All the hex and decimal have proper indicators (initial 1-9 or 0x), and should be easily understood by anybody who actually knows their number systems. Be glad they didn't throw in octal without a leading 0. :) Would host-242.strgz.87.118.199.240.slash28.macomnet.net have confused you less? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bmanning at isi.edu Tue Apr 14 17:03:07 2015 From: bmanning at isi.edu (manning bill) Date: Tue, 14 Apr 2015 10:03:07 -0700 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> Message-ID: <715F4CE3-B87B-419D-BBB7-C49B0CF7012E@isi.edu> perfectly legal… the octal records confuse me more than the hex. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 14April2015Tuesday, at 5:36, Colin Johnston wrote: > never saw hex in host dns records before. > host-242.strgz.87.118.199.240.0xfffffff0.macomnet.net > > range is blocked non the less since bad traffic from Russia network ranges. > > Colin > From bill at herrin.us Tue Apr 14 17:23:49 2015 From: bill at herrin.us (William Herrin) Date: Tue, 14 Apr 2015 13:23:49 -0400 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <002601d076b9$35c40310$a14c0930$@gmail.com> <552D1C0F.9010701@inblock.ru> <0A153EBC-11FB-46E1-8FB7-3A16490FFC3E@gt86car.org.uk> Message-ID: On Tue, Apr 14, 2015 at 10:09 AM, Pavel Odintsov wrote: > We use hexademical numbers in PTR for VPS/Servers because PTR's like > "host-87.118.199.240.domain.ru" so often banned by weird antispam > systems by mask \d+\.\d+\.\d+\d+ as home ISP subnets which produce > bunch of spam. Hi Pavel, Actually, the anti-spammers figure that only local (authenticated) computers and other mail servers should talk to their mail servers. The IP form of RDNS is recognized as a declaration by the service owner that the computer at that address is not intended to host Internet services including email. The hex form is viewed the same and yes, there are antispam products that look for that and a few other naming structures that imply dynamic IPs are in use. If you want to run an email server, assign it a name. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From nharland at gmail.com Tue Apr 14 18:54:42 2015 From: nharland at gmail.com (Nicholas Harland) Date: Tue, 14 Apr 2015 11:54:42 -0700 Subject: Nonprofits - Office 365 In-Reply-To: References: Message-ID: Hi, While I'm sure Ryan's intentions are good, I would like to point out that this is a standard offer available directly from Microsoft. http://www.microsoft.com/about/corporatecitizenship/en-us/office365-for-nonprofits/ Nick Harland On Mon, Apr 13, 2015 at 8:10 PM, Ryan Finnesey wrote: > I apologize for the somewhat off topic post but I would assume some of you > might get asked for tech advice from your favorite nonprofits or > charity's. I am looking for nonprofits that would be able to make use of > free Office 365 licenses and discounted Office 365 Pro Plus licenses at $2 > each. This donation would also come with free consulting services to setup > Office 365 and migrate any data. > > Cheers > Ryan > From ryan at finnesey.com Tue Apr 14 19:02:10 2015 From: ryan at finnesey.com (Ryan Finnesey) Date: Tue, 14 Apr 2015 19:02:10 +0000 Subject: Nonprofits - Office 365 In-Reply-To: References: Message-ID: Hi Nick The free licenses are a standard offer from Microsoft but what is not available is the onboarding and consulting services to migrate data and help the origination get started with Office 365 this is the value- add . Cheers Ryan From: Nicholas Harland [mailto:nharland at gmail.com] Sent: Tuesday, April 14, 2015 2:55 PM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: Nonprofits - Office 365 Hi, While I'm sure Ryan's intentions are good, I would like to point out that this is a standard offer available directly from Microsoft. http://www.microsoft.com/about/corporatecitizenship/en-us/office365-for-nonprofits/ Nick Harland On Mon, Apr 13, 2015 at 8:10 PM, Ryan Finnesey > wrote: I apologize for the somewhat off topic post but I would assume some of you might get asked for tech advice from your favorite nonprofits or charity's. I am looking for nonprofits that would be able to make use of free Office 365 licenses and discounted Office 365 Pro Plus licenses at $2 each. This donation would also come with free consulting services to setup Office 365 and migrate any data. Cheers Ryan From alvarezp at alvarezp.ods.org Tue Apr 14 23:58:49 2015 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 14 Apr 2015 16:58:49 -0700 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: <552DA9B9.2020101@alvarezp.ods.org> On 14/04/15 06:26, Colin Johnston wrote: > Best practice says avoid such info in records as does not aid debug since mix of dec and hex Can you please cite the best practice document where this is stated? Thanks. From larrysheldon at cox.net Wed Apr 15 00:29:32 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 14 Apr 2015 19:29:32 -0500 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> Message-ID: <552DB0EC.20100@cox.net> On 4/14/2015 08:26, Colin Johnston wrote: > Because looks strange especially if the traffic is 100% bad Best > practice says avoid such info in records as does not aid debug since > mix of dec and hex Which is precisely why spammers have been doing it for years. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From larrysheldon at cox.net Wed Apr 15 00:31:50 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 14 Apr 2015 19:31:50 -0500 Subject: macomnet weird dns record In-Reply-To: References: <49A81EB09F493442B6D259E36251192C0171991E52@ndcc-exch1.neutraldata.com> <5526A0FF.8030603@ispn.net> <5526A965.5040106@sonn.com> <552D1196.2000408@inblock.ru> <552D1AC8.7010108@inblock.ru> Message-ID: <552DB176.7050704@cox.net> On 4/14/2015 08:51, Colin Johnston wrote: > Get real, why make is hard for others to debug abuse issues, another > reason why blocks in place as no technical cooperation. Because "others" has a subset = "dreaded anti-spammers". -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From jlewis at lewis.org Wed Apr 15 13:05:29 2015 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 15 Apr 2015 09:05:29 -0400 (EDT) Subject: reclaiming arin IP allocations? In-Reply-To: References: Message-ID: You can't get their IP space revoked just because you got a stupid response from a confused/uneducated/overworked abuse handler. If you could, Yahoo and Hotmail would have been shut down ages ago. :) On Mon, 13 Apr 2015 goemon at anime.net wrote: > i reported abuse to them that was originating directly from > 209.17.115.109, they responded stating they have no control over the origin > IP and that i should look up the IP in arin to get the owner. > > -Dan > > On Mon, 13 Apr 2015, Mel Beckman wrote: > >> What makes you think they are disavowing ownership? Did they state that to >> you personally, or are you inferring that from other information? >> >> -mel beckman >> >>> On Apr 13, 2015, at 1:36 PM, "goemon at anime.net" wrote: >>> >>> web.com/netsol is disavowing ownership of 209.17.115.109. >>> >>> NetRange: 209.17.112.0 - 209.17.127.255 >>> CIDR: 209.17.112.0/20 >>> NetName: WEB-COM-BLK3 >>> NetHandle: NET-209-17-112-0-1 >>> Parent: NET209 (NET-209-0-0-0-0) >>> >>> What is the process to get this netblock reclaimed? >>> >>> -Dan >> > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Rod.Beck at hibernianetworks.com Wed Apr 15 14:28:34 2015 From: Rod.Beck at hibernianetworks.com (Rod Beck) Date: Wed, 15 Apr 2015 14:28:34 +0000 Subject: Peering and Network Cost Message-ID: <1429104508516.63849@hibernianetworks.com> Hi, As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. I thank you in advance for any insights. Regards, - R. Roderick Beck Sales Director/Europe and the Americas Hibernia Networks This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. From psirt at cisco.com Wed Apr 15 16:11:44 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 15 Apr 2015 12:11:44 -0400 Subject: Cisco Security Advisory: Cisco IOS XR Software BVI Routed Packet Denial of Service Vulnerability Message-ID: <201504151211.17.iosxr@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS XR Software BVI Routed Packet Denial of Service Vulnerability Advisory ID: cisco-sa-20150415-iosxr Revision 1.0 For Public Release 2015 April 15 16:00 UTC (GMT) Summary ======= A vulnerability in the packet-processing code of Cisco IOS XR Software for Cisco ASR 9000 Series Aggregation Services Routers (ASR) could allow an unauthenticated, remote attacker to cause a lockup and eventual reload of a network processor chip and the line card that is processing traffic. Only Typhoon-based line cards on Cisco ASR 9000 Series Aggregation Services Routers are affected by this vulnerability. The vulnerability is due to improper processing of packets that are routed via the bridge-group virtual interface (BVI) when any of the following features are configured: Unicast Reverse Path Forwarding (uRPF), policy-based routing (PBR), quality of service (QoS), or access control lists (ACLs). An attacker could exploit this vulnerability by sending IPv4 packets through an affected device that is configured to route them via the BVI interface. A successful exploit could allow the attacker to cause a lockup and eventual reload of a network processor chip and the line card that is processing traffic, leading to a denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. There are no workarounds to address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150415-iosxr -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVLoaBAAoJEIpI1I6i1Mx3QxoP/0l8Z+HfJhF5ipb0CZT62TIS m6gBR5TnXtkQTSLPBqvGTALoKTpXIuY49YwRjkAYRmVMei+ercsf6llE8YSmYL3Q TjaGxxhp4v9dQo36IwuzhjY8oGiMHIrLuRwWt+b8OZos2d+wQAcP76nfKyWhnGhC rBwN/js1uxBkTWpxIru149xf76moe3+1v353kjVS+PUbm33Uwe1dfAS1uETZvN1N lIIYlyzwqzokl+KRFvPKq0Iyr/qLa2cHqtfcLOwAD2VuLwGboFcno1uOlf7uEt4Z Wb1T1tAHvEHVBMpmh2jcV6EgGw3igU5Azx2C/+YeNqFTAei4qbUYi9Jhg9vuvhO1 ED5w+GaXg58opiaYEvP4GAXJ6pcq2P39Nawncodz/rA2IM5bQyTRWzCflMMfivFC AR0/g500NvwyCWluXaDVpvcZMI/MNuw8nq4MaTp7e/opYAiJFMW/ru6YAAFZOTW3 yG0Iij+vObL977hGlSHxlbJfqusfHT9m1tvARUhqRnD+LJcymvGMY9bJnndGqFr1 MQowrdz2acEX4DYF6RJgjgYSUfpH7QZd2Dh7STxmOS1y+8oUBplcr8oD4qgl/NRk NJyyuN2lLywb+v0EJGwz1+QjCBOLRJ5y3CvYM9ZsPOWJJZASDmPa4EvVQSyXloBM 8aItCdd34k/4H7gj+gYy =nnUg -----END PGP SIGNATURE----- From rs at seastrom.com Wed Apr 15 16:39:23 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 15 Apr 2015 12:39:23 -0400 Subject: reclaiming arin IP allocations? In-Reply-To: (goemon@anime.net's message of "Mon, 13 Apr 2015 15:02:08 -0700 (PDT)") References: Message-ID: <86vbgxibwk.fsf@valhalla.seastrom.com> goemon at anime.net writes: > "Note ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2013-11-06" > > So if the owner does not care to respond to ARIN, what now? POC validation has an extraordinarily low success rate (under 50% if memory serves). Since this is a direct allocation and the space has not been "revoked" (pulled for cause, e.g. non-payment), I can only assume that the billing POC over snail mail is continuing to work as anticipated. -r From rs at seastrom.com Wed Apr 15 17:03:40 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 15 Apr 2015 13:03:40 -0400 Subject: reclaiming arin IP allocations? In-Reply-To: <86vbgxibwk.fsf@valhalla.seastrom.com> (Rob Seastrom's message of "Wed, 15 Apr 2015 12:39:23 -0400") References: <86vbgxibwk.fsf@valhalla.seastrom.com> Message-ID: <86mw29gw7n.fsf@valhalla.seastrom.com> Rob Seastrom writes: > goemon at anime.net writes: > >> "Note ARIN has attempted to validate the data for this POC, but has received no response from the POC since 2013-11-06" >> >> So if the owner does not care to respond to ARIN, what now? > > POC validation has an extraordinarily low success rate (under 50% if > memory serves). Since this is a direct allocation and the space has > not been "revoked" (pulled for cause, e.g. non-payment), I can only > assume that the billing POC over snail mail is continuing to work as > anticipated. > > -r Ahhhh, irony. :-) goemon at anime.net SMTP error from remote mail server after MAIL FROM:: host sasami.anime.net [207.109.251.120]: 554 5.7.1 twit filter -r From maxtul at netassist.ua Wed Apr 15 17:50:41 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 15 Apr 2015 20:50:41 +0300 Subject: Peering and Network Cost In-Reply-To: <1429104508516.63849@hibernianetworks.com> References: <1429104508516.63849@hibernianetworks.com> Message-ID: <552EA4F1.5010700@netassist.ua> Hi Roderick, transit cost is lowering close to peering cost, so it is doubghtful economy on small channels. If you don't live in Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major IX. That's the magic. In large scale peering is still efficient. It is efficient on local traffic which is often huge. On 04/15/15 17:28, Rod Beck wrote: > Hi, > > > As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. > > > But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. > > > I thank you in advance for any insights. > > > Regards, > > > - R. > > > Roderick Beck > Sales Director/Europe and the Americas > Hibernia Networks > > This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. > From nanog at ics-il.net Wed Apr 15 17:58:02 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 Apr 2015 12:58:02 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: <552EA4F1.5010700@netassist.ua> Message-ID: <7329192.7196.1429120651932.JavaMail.mhammett@ThunderFuck> It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Wednesday, April 15, 2015 12:50:41 PM Subject: Re: Peering and Network Cost Hi Roderick, transit cost is lowering close to peering cost, so it is doubghtful economy on small channels. If you don't live in Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major IX. That's the magic. In large scale peering is still efficient. It is efficient on local traffic which is often huge. On 04/15/15 17:28, Rod Beck wrote: > Hi, > > > As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. > > > But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. > > > I thank you in advance for any insights. > > > Regards, > > > - R. > > > Roderick Beck > Sales Director/Europe and the Americas > Hibernia Networks > > This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. > From maxtul at netassist.ua Wed Apr 15 18:27:45 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Wed, 15 Apr 2015 21:27:45 +0300 Subject: Peering and Network Cost In-Reply-To: <7329192.7196.1429120651932.JavaMail.mhammett@ThunderFuck> References: <7329192.7196.1429120651932.JavaMail.mhammett@ThunderFuck> Message-ID: <552EADA1.6000704@netassist.ua> Not actually Facebook net, but Akamai CDN. Not a Google (peer), but GCC node ;) It is varying from location to location. For example here in Ukraine we (still) have 1st place for traffic amount from Vkontakte (mostly music streams), second from EX.ua (movie store), but almost none NetFlix, Hulu or Amazon. And you can't get both of them in a good quality neither at IXes, nor at Tier1. I think in another locations, for example in India, traffic profile will be different from both of us, and have some local specific as well. On 04/15/15 20:58, Mike Hammett wrote: > It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. > > A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Wednesday, April 15, 2015 12:50:41 PM > Subject: Re: Peering and Network Cost > > Hi Roderick, > > transit cost is lowering close to peering cost, so it is doubghtful > economy on small channels. If you don't live in > Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major > IX. That's the magic. > > In large scale peering is still efficient. It is efficient on local > traffic which is often huge. > > On 04/15/15 17:28, Rod Beck wrote: >> Hi, >> >> >> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >> >> >> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >> >> >> I thank you in advance for any insights. >> >> >> Regards, >> >> >> - R. >> >> >> Roderick Beck >> Sales Director/Europe and the Americas >> Hibernia Networks >> >> This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry > out your > > own virus checks before opening any attachment. >> > > > From nanog at ics-il.net Wed Apr 15 18:33:35 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 Apr 2015 13:33:35 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: <552EADA1.6000704@netassist.ua> Message-ID: <25767710.7317.1429122785544.JavaMail.mhammett@ThunderFuck> Very true. I left it as I did given that I expect a similar profile from others in North America... on NANOG. Basically, wherever your region's streaming video or application updates come from. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Wednesday, April 15, 2015 1:27:45 PM Subject: Re: Peering and Network Cost Not actually Facebook net, but Akamai CDN. Not a Google (peer), but GCC node ;) It is varying from location to location. For example here in Ukraine we (still) have 1st place for traffic amount from Vkontakte (mostly music streams), second from EX.ua (movie store), but almost none NetFlix, Hulu or Amazon. And you can't get both of them in a good quality neither at IXes, nor at Tier1. I think in another locations, for example in India, traffic profile will be different from both of us, and have some local specific as well. On 04/15/15 20:58, Mike Hammett wrote: > It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. > > A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Wednesday, April 15, 2015 12:50:41 PM > Subject: Re: Peering and Network Cost > > Hi Roderick, > > transit cost is lowering close to peering cost, so it is doubghtful > economy on small channels. If you don't live in > Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major > IX. That's the magic. > > In large scale peering is still efficient. It is efficient on local > traffic which is often huge. > > On 04/15/15 17:28, Rod Beck wrote: >> Hi, >> >> >> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >> >> >> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >> >> >> I thank you in advance for any insights. >> >> >> Regards, >> >> >> - R. >> >> >> Roderick Beck >> Sales Director/Europe and the Americas >> Hibernia Networks >> >> This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry > out your > > own virus checks before opening any attachment. >> > > > From nanog at ics-il.net Wed Apr 15 18:45:27 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 Apr 2015 13:45:27 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: <25767710.7317.1429122785544.JavaMail.mhammett@ThunderFuck> Message-ID: <26042041.7346.1429123494063.JavaMail.mhammett@ThunderFuck> (Reply to thread, not necessarily myself.) If you can pull a third of your traffic off at the cost of a cross connect and another third at the cost of an IX port, now you can spend a buck or two a meg on what's left. Yes, I understand the cost of a cross connect or IX port is the $/megabit you're actually using and not $/megabit of capacity. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Hammett" To: "Max Tulyev" Cc: nanog at nanog.org Sent: Wednesday, April 15, 2015 1:33:35 PM Subject: Re: Peering and Network Cost Very true. I left it as I did given that I expect a similar profile from others in North America... on NANOG. Basically, wherever your region's streaming video or application updates come from. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Wednesday, April 15, 2015 1:27:45 PM Subject: Re: Peering and Network Cost Not actually Facebook net, but Akamai CDN. Not a Google (peer), but GCC node ;) It is varying from location to location. For example here in Ukraine we (still) have 1st place for traffic amount from Vkontakte (mostly music streams), second from EX.ua (movie store), but almost none NetFlix, Hulu or Amazon. And you can't get both of them in a good quality neither at IXes, nor at Tier1. I think in another locations, for example in India, traffic profile will be different from both of us, and have some local specific as well. On 04/15/15 20:58, Mike Hammett wrote: > It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. > > A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Wednesday, April 15, 2015 12:50:41 PM > Subject: Re: Peering and Network Cost > > Hi Roderick, > > transit cost is lowering close to peering cost, so it is doubghtful > economy on small channels. If you don't live in > Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major > IX. That's the magic. > > In large scale peering is still efficient. It is efficient on local > traffic which is often huge. > > On 04/15/15 17:28, Rod Beck wrote: >> Hi, >> >> >> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >> >> >> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >> >> >> I thank you in advance for any insights. >> >> >> Regards, >> >> >> - R. >> >> >> Roderick Beck >> Sales Director/Europe and the Americas >> Hibernia Networks >> >> This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry > out your > > own virus checks before opening any attachment. >> > > > From David.Siegel at Level3.com Wed Apr 15 19:22:33 2015 From: David.Siegel at Level3.com (Siegel, David) Date: Wed, 15 Apr 2015 19:22:33 +0000 Subject: Peering and Network Cost In-Reply-To: <26042041.7346.1429123494063.JavaMail.mhammett@ThunderFuck> References: <25767710.7317.1429122785544.JavaMail.mhammett@ThunderFuck> <26042041.7346.1429123494063.JavaMail.mhammett@ThunderFuck> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0A4043BF6@USIDCWVEMBX05.corp.global.level3.com> Most cost models select a capacity figure that represents typical high-watermark utilization before the next cash outlay is triggered. By using your actual utilization, you might be penalizing your cost if you have low utilization and that low utilization is expected to be a temporary situation given the state of your business. That way your cost doesn't increase (for example) as a function of losing a large customer or other traffic shifting event. The only reason I would see some intentionally pick a lower figure is if the dynamic of their specific business suggests that low-utilization interconnect ports are typical for them. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Wednesday, April 15, 2015 12:45 PM To: nanog at nanog.org Subject: Re: Peering and Network Cost (Reply to thread, not necessarily myself.) If you can pull a third of your traffic off at the cost of a cross connect and another third at the cost of an IX port, now you can spend a buck or two a meg on what's left. Yes, I understand the cost of a cross connect or IX port is the $/megabit you're actually using and not $/megabit of capacity. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Hammett" To: "Max Tulyev" Cc: nanog at nanog.org Sent: Wednesday, April 15, 2015 1:33:35 PM Subject: Re: Peering and Network Cost Very true. I left it as I did given that I expect a similar profile from others in North America... on NANOG. Basically, wherever your region's streaming video or application updates come from. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Wednesday, April 15, 2015 1:27:45 PM Subject: Re: Peering and Network Cost Not actually Facebook net, but Akamai CDN. Not a Google (peer), but GCC node ;) It is varying from location to location. For example here in Ukraine we (still) have 1st place for traffic amount from Vkontakte (mostly music streams), second from EX.ua (movie store), but almost none NetFlix, Hulu or Amazon. And you can't get both of them in a good quality neither at IXes, nor at Tier1. I think in another locations, for example in India, traffic profile will be different from both of us, and have some local specific as well. On 04/15/15 20:58, Mike Hammett wrote: > It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. > > A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Wednesday, April 15, 2015 12:50:41 PM > Subject: Re: Peering and Network Cost > > Hi Roderick, > > transit cost is lowering close to peering cost, so it is doubghtful > economy on small channels. If you don't live in > Amsterdam/Frankfurt/London - add the DWDM cost from you to one of > major IX. That's the magic. > > In large scale peering is still efficient. It is efficient on local > traffic which is often huge. > > On 04/15/15 17:28, Rod Beck wrote: >> Hi, >> >> >> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >> >> >> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >> >> >> I thank you in advance for any insights. >> >> >> Regards, >> >> >> - R. >> >> >> Roderick Beck >> Sales Director/Europe and the Americas Hibernia Networks >> >> This e-mail and any attachments thereto is intended only for use by >> the addressee(s) named herein and may be proprietary and/or legally >> privileged. If you are not the intended recipient of this e-mail, you >> are hereby notified that any dissemination, distribution or copying >> of this email, and any attachments thereto, without the prior written >> permission of the sender is strictly prohibited. If you receive this >> e-mail in error, please immediately telephone or e-mail the sender >> and permanently delete the original copy and any copy of this e-mail, >> and any printout thereof. All documents, contracts or agreements >> referred or attached to this e-mail are SUBJECT TO CONTRACT. The >> contents of an attachment to this e-mail may contain software viruses >> that could damage your own computer system. While Hibernia Networks >> has taken every reasonable precaution to minimize this risk, we >> cannot accept liability for any damage that you sustain as a result >> of software viruses. You should carry > out your > > own virus checks before opening any attachment. >> > > > From swhyte at gmail.com Wed Apr 15 20:06:04 2015 From: swhyte at gmail.com (Scott Whyte) Date: Wed, 15 Apr 2015 13:06:04 -0700 Subject: Peering and Network Cost In-Reply-To: <1429104508516.63849@hibernianetworks.com> References: <1429104508516.63849@hibernianetworks.com> Message-ID: <552EC4AC.5030901@gmail.com> On 4/15/15 07:28, Rod Beck wrote: > Hi, > > > As you all know, transit costs in the wholesale market today a few > percent of what it did in 2000. I assume that most of that decline is > due to a modified version of Moore's Law (I don't believe optics > costs decline 50% every 18 months) and the advent of maverick players > like Cogent that broker cozy oligopoly pricing. > > > But I also wondering whether the advent of widespread peering > (promiscuous?) among the Tier 2 players (buy transit and peer) has > played a role. In 2000 peering was still an exclusive club and in > contrast today Tier 2 players often have hundreds of peers. Peering > should reduce costs and also demand in the wholesale IP market. > Supply increases and demand falls. You might find https://www.nanog.org/meetings/nanog53/presentations/Tuesday/valancius.pdf and the concomitant http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p194.pdf interesting. -Scot > > > I thank you in advance for any insights. > > > Regards, > > > - R. > > > Roderick Beck Sales Director/Europe and the Americas Hibernia > Networks > > This e-mail and any attachments thereto is intended only for use by > the addressee(s) named herein and may be proprietary and/or legally > privileged. If you are not the intended recipient of this e-mail, you > are hereby notified that any dissemination, distribution or copying > of this email, and any attachments thereto, without the prior written > permission of the sender is strictly prohibited. If you receive this > e-mail in error, please immediately telephone or e-mail the sender > and permanently delete the original copy and any copy of this e-mail, > and any printout thereof. All documents, contracts or agreements > referred or attached to this e-mail are SUBJECT TO CONTRACT. The > contents of an attachment to this e-mail may contain software viruses > that could damage your own computer system. While Hibernia Networks > has taken every reasonable precaution to minimize this risk, we > cannot accept liability for any damage that you sustain as a result > of software viruses. You should carry out your own virus checks > before opening any attachment. > From baldur.norddahl at gmail.com Wed Apr 15 20:07:52 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 15 Apr 2015 22:07:52 +0200 Subject: Peering and Network Cost In-Reply-To: <1429104508516.63849@hibernianetworks.com> References: <1429104508516.63849@hibernianetworks.com> Message-ID: Transit cost is down but IX cost remains the same. Therefore IX is longer cost effective for a small ISP. As an (non US) example, here in Copenhagen, Denmark we have two internet exchanges DIX and Netnod. We also have many major transit providers, including Hurricane Electric and Cogent. Netnod price for a 1 Gbps port is 40000 SEK = 4500 USD / year http://www.netnod.se/ix/join/prices. DIX is 40000 DKK = 5700 USD / year http://dix.dk/serviceinformation/ HE.net is offering 1 Gbps flatrate for 450 USD / month list price = 5400 USD /year. Cogent can match that. So why would a small ISP pay 4500 USD for a service with no guarantee of how much traffic they will be able to peer away? You need to get a 10 Gbps port and be able to peer at least 2-3 Gbps before it is even break even with the deals you get from the transit providers. But then you will notice that all the traffic is only with a few peers and you can just peer directly with those and skip the middleman. Regards, Baldur From Grzegorz at Janoszka.pl Wed Apr 15 20:12:18 2015 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Wed, 15 Apr 2015 22:12:18 +0200 Subject: Peering and Network Cost In-Reply-To: <552EA4F1.5010700@netassist.ua> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> Message-ID: <552EC622.8090004@Janoszka.pl> On 2015-04-15 19:50, Max Tulyev wrote: > transit cost is lowering close to peering cost, so it is doubghtful > economy on small channels. If you don't live in > Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major > IX. That's the magic. > > In large scale peering is still efficient. It is efficient on local > traffic which is often huge. Even in the three cities you mentioned peering on small scale is usually not cheaper at all or only very little. Please keep in mind that some companies peer despite it offers no savings for them and at the end of the day it might be even more expensive. They do it because of performance and reliability reasons. -- Grzegorz Janoszka From nanog at ics-il.net Wed Apr 15 20:18:11 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 15 Apr 2015 15:18:11 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: Message-ID: <14882211.7629.1429129051379.JavaMail.mhammett@ThunderFuck> https://www.youtube.com/watch?v=Y43Fy4oU2XE There are reasons to peer other than cost reduction. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Wednesday, April 15, 2015 3:07:52 PM Subject: Re: Peering and Network Cost Transit cost is down but IX cost remains the same. Therefore IX is longer cost effective for a small ISP. As an (non US) example, here in Copenhagen, Denmark we have two internet exchanges DIX and Netnod. We also have many major transit providers, including Hurricane Electric and Cogent. Netnod price for a 1 Gbps port is 40000 SEK = 4500 USD / year http://www.netnod.se/ix/join/prices. DIX is 40000 DKK = 5700 USD / year http://dix.dk/serviceinformation/ HE.net is offering 1 Gbps flatrate for 450 USD / month list price = 5400 USD /year. Cogent can match that. So why would a small ISP pay 4500 USD for a service with no guarantee of how much traffic they will be able to peer away? You need to get a 10 Gbps port and be able to peer at least 2-3 Gbps before it is even break even with the deals you get from the transit providers. But then you will notice that all the traffic is only with a few peers and you can just peer directly with those and skip the middleman. Regards, Baldur From tore at fud.no Thu Apr 16 05:25:45 2015 From: tore at fud.no (Tore Anderson) Date: Thu, 16 Apr 2015 07:25:45 +0200 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> Message-ID: <20150416072545.578b757f@echo.ms.redpill-linpro.com> * Baldur Norddahl > Transit cost is down but IX cost remains the same. Therefore IX is longer > cost effective for a small ISP. > > As an (non US) example, here in Copenhagen, Denmark we have two internet > exchanges DIX and Netnod. We also have many major transit providers, > including Hurricane Electric and Cogent. > > Netnod price for a 1 Gbps port is 40000 SEK = 4500 USD / year > http://www.netnod.se/ix/join/prices. DIX is 40000 DKK = 5700 USD / year > http://dix.dk/serviceinformation/ > > HE.net is offering 1 Gbps flatrate for 450 USD / month list price = 5400 > USD /year. > > Cogent can match that. > > So why would a small ISP pay 4500 USD for a service with no guarantee of > how much traffic they will be able to peer away? We're in a similar situation here; transit prices has come down so much in recent years (while IX fees are indeed stagnant) that I am certain that if I were to cut all peering and buy everything from a regional tier-2 instead, I'd be lowering my total MRC somewhat, without really reducing connectivity quality to my (former) peers. For us, the primary reason that keeps us peering is DDoS prevention. Our traffic is mostly regional, so if a customer of mine gets hit with a volumetric DDoS attack that would saturate my IP transit lines and cause collateral damage, that's no big deal as we can just RTBH the customers prefix towards our transit providers. The customer is only mildly inconvenienced by this as, say, 90% of his traffic goes to our peers. Without peering the attack would succeed because my RTBH would completely offline my customer. Tore From mark.tinka at seacom.mu Thu Apr 16 06:08:27 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 16 Apr 2015 08:08:27 +0200 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> Message-ID: <552F51DB.2040101@seacom.mu> On 15/Apr/15 22:07, Baldur Norddahl wrote: > Transit cost is down but IX cost remains the same. Therefore IX is longer > cost effective for a small ISP. > > As an (non US) example, here in Copenhagen, Denmark we have two internet > exchanges DIX and Netnod. We also have many major transit providers, > including Hurricane Electric and Cogent. > > Netnod price for a 1 Gbps port is 40000 SEK = 4500 USD / year > http://www.netnod.se/ix/join/prices. DIX is 40000 DKK = 5700 USD / year > http://dix.dk/serviceinformation/ > > HE.net is offering 1 Gbps flatrate for 450 USD / month list price = 5400 > USD /year. > > Cogent can match that. > > So why would a small ISP pay 4500 USD for a service with no guarantee of > how much traffic they will be able to peer away? > > You need to get a 10 Gbps port and be able to peer at least 2-3 Gbps before > it is even break even with the deals you get from the transit providers. > But then you will notice that all the traffic is only with a few peers and > you can just peer directly with those and skip the middleman. Even though you get more bandwidth at an exchange point for the price you pay a transit provider for less bandwidth, the value you extract from the more cost-efficient peering port is directly proportional to how much peering you can get off of it. If you are unable to offload enough of your traffic on to peering that an incremental transit service cost can justify, you're likely better off with a transit provider if budget is your constraint. Mark. From mark.tinka at seacom.mu Thu Apr 16 06:10:25 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 16 Apr 2015 08:10:25 +0200 Subject: Peering and Network Cost In-Reply-To: <552EC622.8090004@Janoszka.pl> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> Message-ID: <552F5251.5090704@seacom.mu> On 15/Apr/15 22:12, Grzegorz Janoszka wrote: > > > Please keep in mind that some companies peer despite it offers no > savings for them and at the end of the day it might be even more > expensive. They do it because of performance and reliability reasons. And also to reduce AS hops. If you and your competition are pushing BGP routes to your multi-homed customers, the customers are "more likely" to choose paths with fewer AS hops. Traffic to you means $$ to you. In the long run, it "could" pay off, or at the very least, get you more customers. Mark. From mark.tinka at seacom.mu Thu Apr 16 06:15:16 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 16 Apr 2015 08:15:16 +0200 Subject: Peering and Network Cost In-Reply-To: <20150416072545.578b757f@echo.ms.redpill-linpro.com> References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> Message-ID: <552F5374.5080202@seacom.mu> On 16/Apr/15 07:25, Tore Anderson wrote: > We're in a similar situation here; transit prices has come down so much > in recent years (while IX fees are indeed stagnant) that I am certain > that if I were to cut all peering and buy everything from a regional > tier-2 instead, I'd be lowering my total MRC somewhat, without really > reducing connectivity quality to my (former) peers. I wouldn't say exchange point prices are stagnant, per se. They may remain the same, but what goes up is the port bandwidth. It's not directly linear, but you get my point. Again, the burden is on the peering members to extract the most out of their peering links by having as much peering as possible. Route servers at the exchange points have played a huge role in facilitating this, but the final stretch involves getting in touch with a bunch of members to setup bi-lateral sessions, with no guarantee they will agree, or if they do, may not peer their entire network, not taking into account whether they will do this for free or not. Perhaps the next bunch of exchange point operators will be those who play a more active role in facilitating peering across all members, so as to keep traffic on their switch fabric and away from transit providers. But that is probably a zero-sum game, as their involvement will just mean more salaries that need to get paid, leading to an increase in membership fees. Mark. From tore at fud.no Thu Apr 16 07:00:53 2015 From: tore at fud.no (Tore Anderson) Date: Thu, 16 Apr 2015 09:00:53 +0200 Subject: Peering and Network Cost In-Reply-To: <552F5374.5080202@seacom.mu> References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> Message-ID: <20150416090053.4c01330c@echo.ms.redpill-linpro.com> * Mark Tinka > On 16/Apr/15 07:25, Tore Anderson wrote: > > We're in a similar situation here; transit prices has come down so > > much in recent years (while IX fees are indeed stagnant) that I am > > certain that if I were to cut all peering and buy everything from a > > regional tier-2 instead, I'd be lowering my total MRC somewhat, > > without really reducing connectivity quality to my (former) peers. > > I wouldn't say exchange point prices are stagnant, per se. They may > remain the same, but what goes up is the port bandwidth. It's not > directly linear, but you get my point. > > Again, the burden is on the peering members to extract the most out of > their peering links by having as much peering as possible. You appear to be assuming that an IP transit port is more expensive then an IXP port with the same speed. That doesn't seem to always be the case anymore, at least not in all parts of the world, and I expect this trend to continue - transit prices seems to go down almost on a monthly basis, while the price lists of the two closest IXPs to where I'm sitting are dated 2011 and 2013, respectively. Even if the transit port itself remains slightly more expensive than the IXP port like in the example Baldur showed, the no-peering alternative might still be cheaper overall because even if you're peering most of your traffic you'll still need to pay a nonzero amount for a (smaller or less utilised) transit port anyway. Tore From david at mailplus.nl Thu Apr 16 10:58:03 2015 From: david at mailplus.nl (David Hofstee) Date: Thu, 16 Apr 2015 12:58:03 +0200 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es Message-ID: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> Hi, I saw the following and thought it would be interesting to share. In case of a persistent DDoS an ASy can fallback to a small set of (more trustable) AS'es for their routing: http://www.trustednetworksinitiative.nl/ They have a policy with procedural and technical parts, which may be upgraded later, for parties who want to participate: https://www.thehaguesecuritydelta.com/images/20141124_Trusted_Networks_Policy_beta-vs0_7.pdf Without having an opinion if everybody in the world should join this (I don't know the desired scope of this group), but the idea is interesting. I had not seen something like it before. Yours sincerely, David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) From nanog at ics-il.net Thu Apr 16 12:19:47 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 16 Apr 2015 07:19:47 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: <20150416090053.4c01330c@echo.ms.redpill-linpro.com> Message-ID: <431287.8823.1429186769685.JavaMail.mhammett@ThunderFuck> IX port pricing in the Chicago area has plummeted in the past two or three years. It's gone down... maybe 2/3. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Tore Anderson" To: "Mark Tinka" Cc: nanog at nanog.org Sent: Thursday, April 16, 2015 2:00:53 AM Subject: Re: Peering and Network Cost * Mark Tinka > On 16/Apr/15 07:25, Tore Anderson wrote: > > We're in a similar situation here; transit prices has come down so > > much in recent years (while IX fees are indeed stagnant) that I am > > certain that if I were to cut all peering and buy everything from a > > regional tier-2 instead, I'd be lowering my total MRC somewhat, > > without really reducing connectivity quality to my (former) peers. > > I wouldn't say exchange point prices are stagnant, per se. They may > remain the same, but what goes up is the port bandwidth. It's not > directly linear, but you get my point. > > Again, the burden is on the peering members to extract the most out of > their peering links by having as much peering as possible. You appear to be assuming that an IP transit port is more expensive then an IXP port with the same speed. That doesn't seem to always be the case anymore, at least not in all parts of the world, and I expect this trend to continue - transit prices seems to go down almost on a monthly basis, while the price lists of the two closest IXPs to where I'm sitting are dated 2011 and 2013, respectively. Even if the transit port itself remains slightly more expensive than the IXP port like in the example Baldur showed, the no-peering alternative might still be cheaper overall because even if you're peering most of your traffic you'll still need to pay a nonzero amount for a (smaller or less utilised) transit port anyway. Tore From jason at lixfeld.ca Thu Apr 16 14:16:17 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 16 Apr 2015 10:16:17 -0400 Subject: Ixia or Spirent around? Message-ID: <8294A7C5-E2C1-4455-9E25-53B16FFEADFA@lixfeld.ca> I tried the contact form on their respective websites a couple of weeks back, but have not heard back. If anyone from there is lurking about or if anyone has a sales contact that covers Toronto and could send me off-list, I'd be grateful. Thank you! Sent from my iPhone From edward.dore at freethought-internet.co.uk Thu Apr 16 15:10:46 2015 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Thu, 16 Apr 2015 16:10:46 +0100 Subject: Peering and Network Cost In-Reply-To: <20150416090053.4c01330c@echo.ms.redpill-linpro.com> References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> <20150416090053.4c01330c@echo.ms.redpill-linpro.com> Message-ID: <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> On 16 Apr 2015, at 08:00, Tore Anderson wrote: > * Mark Tinka > >> On 16/Apr/15 07:25, Tore Anderson wrote: >>> We're in a similar situation here; transit prices has come down so >>> much in recent years (while IX fees are indeed stagnant) that I am >>> certain that if I were to cut all peering and buy everything from a >>> regional tier-2 instead, I'd be lowering my total MRC somewhat, >>> without really reducing connectivity quality to my (former) peers. >> >> I wouldn't say exchange point prices are stagnant, per se. They may >> remain the same, but what goes up is the port bandwidth. It's not >> directly linear, but you get my point. >> >> Again, the burden is on the peering members to extract the most out of >> their peering links by having as much peering as possible. > > You appear to be assuming that an IP transit port is more expensive > then an IXP port with the same speed. That doesn't seem to always be > the case anymore, at least not in all parts of the world, and I expect > this trend to continue - transit prices seems to go down almost on a > monthly basis, while the price lists of the two closest IXPs to where > I'm sitting are dated 2011 and 2013, respectively. > > Even if the transit port itself remains slightly more expensive than > the IXP port like in the example Baldur showed, the no-peering > alternative might still be cheaper overall because even if you're > peering most of your traffic you'll still need to pay a nonzero amount > for a (smaller or less utilised) transit port anyway. > > Tore Pricing at LINX here in the UK has definitely dropped over the past few years. Back in 2011, the membership fee was £1500/year and it's now £1200/year. 1G ports were £391/month on the first London LAN and £335/month on the second London LAN. They're now free on both LANs for the first port and then £270/month and £180/month respectively for additional ports. You can also get a free 1G port on each of the Manchester UK, Cardiff UK, Edinburgh UK and North Virginia/Washington DC USA LANs as part of the same membership fee (none of these additional LANs existed in 2011). 10G ports were £1463/month on the first London LAN and £1250/month on the second London LAN. They're now £1030/month and £785/month respectively. So that's what, a 20% reduction in membership fees and a 30% or higher (depending on the service) reduction in port fees in 4 years? I don't have any quantifiable data on what has happened to IP transit costs over the same period, but for a point comparison I'd say that off the top of my head you can get a 1G CDR on a 10G port from a tier-1 provider in London for approximately the same cost as a 10G port at LINX these days, maybe slightly cheaper. Edward Dore Freethought Internet From lists at mtin.net Thu Apr 16 16:01:58 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Thu, 16 Apr 2015 12:01:58 -0400 Subject: Low cost WDM gear In-Reply-To: References: Message-ID: <18D1F86E-DA32-4642-8179-724884EF6EF3@mtin.net> Does anyone have a English speaking rep for FiberStore? I have a client with a difficult time ordering some custom stuff. Language barrier is a big issue. Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Feb 7, 2015, at 4:30 PM, Kenneth McRae wrote: > > I will live vicariously though your experiences with them. I'm good on FiberStore. :-) > > Thanks for the feedback.. > > On Feb 07, 2015, at 01:27 PM, Faisal Imtiaz wrote: > > Maybe, your experience was the pivotal event that became a turning point in their customer service attitudes... > > :) > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From: "Kenneth McRae" > To: "Faisal Imtiaz" > Cc: "Rodrigo 1telecom" , "NANOG" > Sent: Saturday, February 7, 2015 4:24:18 PM > Subject: Re: Low cost WDM gear > > Point taken on the specs.. Still doesn't excuse poor customer service and tech support. I never expect to be told that no refund will be issued when I am dissatisfied with the product. A request for RMA because something is not working as expected should not have to be escalated to the President of the company. > > Other than that I am sure FiberStore is a great company :-) > > On Feb 07, 2015, at 01:17 PM, Faisal Imtiaz wrote: > > My point is...... > ... The thing to rely on is/are the Specs. > If the Specs are right or specs are wrong, that is what determines the product's mfg shortcoming (defect). > > Mfg. Engineers are people, just like you and me.... and people can make mistakes... > Being an Engineer, when I ask someone to do the design work, I ask them to explain it, and this way I double check their work.... Yes Mfg. Engineers are known to F***up too. > > While it is expected to be disappointed when something does not work.. and having a bad taste for dealing with that mfg, claiming that all of that mfg products are bad is a whole different issue. > > I deal with FiberStore, my experience have been very different, when stuff purchased from them, did not meet the specs, they took it back no questions asked. > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From: "Kenneth McRae" > To: "Faisal Imtiaz" > Cc: "Rodrigo 1telecom" , "NANOG" > Sent: Saturday, February 7, 2015 4:01:29 PM > Subject: Re: Low cost WDM gear > > That's true up to a point. Specs are only as good as the entity providing the data. I can tell you a few stories about specs and some MAJOR fails by a major network equipment manufacturer failing to meet advertised specs. When you engage the engineering folks to assist in a build, they should know the true specs of their gear better than anyone else. If they say for a certain distance that A+B will work, then that is exactly what I expect. > > That is pretty basic. > > On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: > > More power to you .... > > I always get a chuckle out of statements such as ... "Compared FiberStore to another Vendor"... > > It was pointed out to me long time ago.... when someone said.. "My Chevy is better than a Ford".... > Someone pointed out, hey, which Chevy ? the Chevette ? or the Corvette ? and Which Ford the Fiesta or Mustang ? > > > Every mfg. has a lots and lots of products, and they are always getting improved... > > One has to pay attention to the specs.. even the same model products at different times don't have the same specs ! > > :) > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net > From: "Kenneth McRae" > To: "Faisal Imtiaz" > Cc: "Rodrigo 1telecom" , "NANOG" > Sent: Saturday, February 7, 2015 3:49:16 PM > Subject: Re: Low cost WDM gear > > That's why I engage the engineering resources on their end to make sure the chosen candidate will support the use case. I have now performed an A/B comparison and the FiberStore gear is inferior. Excessive loss on the mux and optics. > > On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: > > If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. > > If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. > > :) > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > From: "Rodrigo 1telecom" > To: "Kenneth McRae" > Cc: "NANOG" > Sent: Saturday, February 7, 2015 3:24:43 PM > Subject: Re: Low cost WDM gear > What others vendors do you using? Here in Brazil only PADTEC have this > passive solution... Some days ago Digitel contact me to show your multiplex > solution... Is a active solution... > We import this from fiberstore, but i don't know others vendors to buy 10G > sfp+ cwdm and this mux/demux... > Enviado via iPhone  > Grupo Connectoway >> Em 07/02/2015, às 16:04, Kenneth McRae escreveu: >> >> Hi Enviado, >> >> I cannot recommend FiberStore as I had a bad experience with them. I >> needed to cover only 3km from A to B side. When using 10km optics, I saw >> a loss of over 5db with their passive mux inserted into the path which >> created a total loss of over -20db which is outside of the tolerances for >> our equipment with 10km SFP+. Using another vendors low insertion loss >> mux corrected our issue. I am sure if you are using an 80km optic, you >> may be able to tolerate a higher insertion loss to cover < 60km. I also >> notice that their CDWM optics averaged about 3db less in power output when >> compared to other vendors. >> >> Thanks >> >> Kenneth >> >>> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom >>> wrote: >>> >> >>> Hi kenneth... which the distance do you have from side A to side B when >>> you using passive solutions from fiberstore( mux and demux)? >>> I buy this mux and demux(4 channels single fiber) and only make a test >>> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( >>> only see ddm on my ex3300( about -19db for 60km). Test switch access with >>> ssh and pinging tests... >>> What kind os issue do you have? For distances less than 60km is this >>> solution good? >>> Thanks!!! >>> >>> Enviado via iPhone  >>> Grupo Connectoway >>> >>>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: >>>> Mike, >>>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware >>>> equipment. The FiberStore gear was a huge disappointment (excessive >>>> loss, poor technical support, refusal to issue refund without >>>> threatening legal action, etc.). I have had good results from the OSI >>>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>>> Hi Mike >>>> I can recommend a couple of vendors that provide cost effective >>>> solutions. >>>> Ekinops & Packetlight. >>>> On Saturday, February 7, 2015, Mike Hammett wrote: >>>> I know there are various Asian vendors for low cost (less than $500) >>>> muxes >>>> to throw 16 or however many colors onto a strand. However, they don't >>>> work >>>> so well when you don't control the optics used on both sides (therefore >>>> must use standard wavelengths), obviously only do a handful of channels >>>> and >>>> have a distance limitation. >>>> What solutions are out there that don't cost an arm and a leg? >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> -- >>>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>>> *+52 >>>> 656-257-1109* >>>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>>> of the individual or entity to which it is addressed and may contain >>>> information that is privileged, confidential, and exempt from disclosure >>>> under applicable law. If you are not the intended recipient of this >>>> information, you are notified that any use, dissemination, distribution, >>>> or >>>> copying of the communication is strictly prohibited. >>>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>>> persona o entidad a la que se dirige y puede contener información >>>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>>> aplicable. Si no es el destinatario de esta información, se le notifica >>>> que >>>> cualquier uso, difusión, distribución o copia de la comunicación está >>>> estrictamente prohibido. > > > > From morrowc.lists at gmail.com Thu Apr 16 19:39:46 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 16 Apr 2015 15:39:46 -0400 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> Message-ID: On Thu, Apr 16, 2015 at 6:58 AM, David Hofstee wrote: > Hi, > > I saw the following and thought it would be interesting to share. In case of a persistent DDoS an ASy can fallback to a small set of (more trustable) AS'es for their routing: > http://www.trustednetworksinitiative.nl/ > > They have a policy with procedural and technical parts, which may be upgraded later, for parties who want to participate: > https://www.thehaguesecuritydelta.com/images/20141124_Trusted_Networks_Policy_beta-vs0_7.pdf > > Without having an opinion if everybody in the world should join this (I don't know the desired scope of this group), but the idea is interesting. I had not seen something like it before. so...: "The principles of the solutions are simple: each participating network at its sole discretion can step to ‘trusted internet only’ if an emergency situation requires to temporary disconnect from the global internet." you're asking your ISP or set of ISPs to 'stop forwarding me packets from X and Y and Z' sure, why do we need a new special group and designation for that? can't you just no-export your routes to your provider today? (or other similar options). this seems ... shortsighted at best and incredibly dumb at worst. From Valdis.Kletnieks at vt.edu Thu Apr 16 20:09:43 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 16 Apr 2015 16:09:43 -0400 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: Your message of "Thu, 16 Apr 2015 15:39:46 -0400." References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> Message-ID: <18012.1429214983@turing-police.cc.vt.edu> On Thu, 16 Apr 2015 15:39:46 -0400, Christopher Morrow said: > you're asking your ISP or set of ISPs to 'stop forwarding me packets > from X and Y and Z' > > sure, why do we need a new special group and designation for that? > can't you just no-export your routes to your provider today? (or other > similar options). How does sending your route for AS1312 with no-export keep packets *from* AS1312 from reaching you? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From job at instituut.net Thu Apr 16 20:13:56 2015 From: job at instituut.net (Job Snijders) Date: Thu, 16 Apr 2015 22:13:56 +0200 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: <18012.1429214983@turing-police.cc.vt.edu> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> Message-ID: <20150416201356.GN67158@Vurt.local> On Thu, Apr 16, 2015 at 04:09:43PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Thu, 16 Apr 2015 15:39:46 -0400, Christopher Morrow said: > > you're asking your ISP or set of ISPs to 'stop forwarding me packets > > from X and Y and Z' > > > > sure, why do we need a new special group and designation for that? > > can't you just no-export your routes to your provider today? (or other > > similar options). > > How does sending your route for AS1312 with no-export keep packets *from* > AS1312 from reaching you? If you don't want packets from 1312 don't announce to them? Kind regards, Job From Valdis.Kletnieks at vt.edu Thu Apr 16 20:30:47 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 16 Apr 2015 16:30:47 -0400 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: Your message of "Thu, 16 Apr 2015 22:13:56 +0200." <20150416201356.GN67158@Vurt.local> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> Message-ID: <19328.1429216247@turing-police.cc.vt.edu> On Thu, 16 Apr 2015 22:13:56 +0200, Job Snijders said: > If you don't want packets from 1312 don't announce to them? I'm probably at least 4-5 AS's away, and you're probably routed to us through Cogent or similar large transit. Feel free to not announce your routes to Cogent because you don't want packets from my AS... (For whatever value of "Cogent" you have for your upstream) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From joelja at bogus.com Thu Apr 16 20:42:03 2015 From: joelja at bogus.com (joel jaeggli) Date: Thu, 16 Apr 2015 13:42:03 -0700 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: <19328.1429216247@turing-police.cc.vt.edu> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> Message-ID: <55301E9B.4010601@bogus.com> On 4/16/15 1:30 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 16 Apr 2015 22:13:56 +0200, Job Snijders said: > >> If you don't want packets from 1312 don't announce to them? > > I'm probably at least 4-5 AS's away, and you're probably routed to us > through Cogent or similar large transit. Feel free to not announce your > routes to Cogent because you don't want packets from my AS... > > (For whatever value of "Cogent" you have for your upstream) bearing in mind that transit providers rarely give you communities to influence their customers, just peers. There is an illusion of control that provider no export communities provide that always requires confirmation when applied. if 1312 buys the full internet cone they can also install a default. so they can send you packets even if they in fact do not have your route. my assumption is there is more default out there then generally assumed and work to replicate the findings in http://www.eecs.qmul.ac.uk/~steve/papers/imc099-bush.pdf would probably find the same thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Thu Apr 16 21:30:35 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 16 Apr 2015 17:30:35 -0400 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: <55301E9B.4010601@bogus.com> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> Message-ID: On Thu, Apr 16, 2015 at 4:42 PM, joel jaeggli wrote: > On 4/16/15 1:30 PM, Valdis.Kletnieks at vt.edu wrote: >> On Thu, 16 Apr 2015 22:13:56 +0200, Job Snijders said: >> >>> If you don't want packets from 1312 don't announce to them? >> >> I'm probably at least 4-5 AS's away, and you're probably routed to us >> through Cogent or similar large transit. Feel free to not announce your >> routes to Cogent because you don't want packets from my AS... >> >> (For whatever value of "Cogent" you have for your upstream) > > bearing in mind that transit providers rarely give you communities to > influence their customers, just peers. There is an illusion of control > that provider no export communities provide that always requires > confirmation when applied. if 1312 buys the full internet cone they can > also install a default. so they can send you packets even if they in > fact do not have your route. lesson learned don't use an example... Note I also said: " (or othersimilar options)." (ha! here's more examples!) o poison the route with remote asn' in the aspath! (except for default followers) o ask for packet filter from upstream isp o stop announcing your route o filter on your side of the fence. in any case the idea still seems silly. From kenneth.mcrae at me.com Fri Apr 17 00:23:48 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Fri, 17 Apr 2015 00:23:48 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <819561ad-9616-4915-8369-e989d7058184@me.com> Michelle speaks English. On Apr 16, 2015, at 09:04 AM, Justin Wilson - MTIN wrote: Does anyone have a English speaking rep for FiberStore? I have a client with a difficult time ordering some custom stuff. Language barrier is a big issue. Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange On Feb 7, 2015, at 4:30 PM, Kenneth McRae wrote: I will live vicariously though your experiences with them. I'm good on FiberStore. :-) Thanks for the feedback.. On Feb 07, 2015, at 01:27 PM, Faisal Imtiaz wrote: Maybe, your experience was the pivotal event that became a turning point in their customer service attitudes... :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 4:24:18 PM Subject: Re: Low cost WDM gear Point taken on the specs.. Still doesn't excuse poor customer service and tech support. I never expect to be told that no refund will be issued when I am dissatisfied with the product. A request for RMA because something is not working as expected should not have to be escalated to the President of the company. Other than that I am sure FiberStore is a great company :-) On Feb 07, 2015, at 01:17 PM, Faisal Imtiaz wrote: My point is...... ... The thing to rely on is/are the Specs. If the Specs are right or specs are wrong, that is what determines the product's mfg shortcoming (defect). Mfg. Engineers are people, just like you and me.... and people can make mistakes... Being an Engineer, when I ask someone to do the design work, I ask them to explain it, and this way I double check their work.... Yes Mfg. Engineers are known to F***up too. While it is expected to be disappointed when something does not work.. and having a bad taste for dealing with that mfg, claiming that all of that mfg products are bad is a whole different issue. I deal with FiberStore, my experience have been very different, when stuff purchased from them, did not meet the specs, they took it back no questions asked. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 4:01:29 PM Subject: Re: Low cost WDM gear That's true up to a point. Specs are only as good as the entity providing the data. I can tell you a few stories about specs and some MAJOR fails by a major network equipment manufacturer failing to meet advertised specs. When you engage the engineering folks to assist in a build, they should know the true specs of their gear better than anyone else. If they say for a certain distance that A+B will work, then that is exactly what I expect. That is pretty basic. On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: More power to you .... I always get a chuckle out of statements such as ... "Compared FiberStore to another Vendor"... It was pointed out to me long time ago.... when someone said.. "My Chevy is better than a Ford".... Someone pointed out, hey, which Chevy ? the Chevette ? or the Corvette ? and Which Ford the Fiesta or Mustang ? Every mfg. has a lots and lots of products, and they are always getting improved... One has to pay attention to the specs.. even the same model products at different times don't have the same specs ! :) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 3:49:16 PM Subject: Re: Low cost WDM gear That's why I engage the engineering resources on their end to make sure the chosen candidate will support the use case. I have now performed an A/B comparison and the FiberStore gear is inferior. Excessive loss on the mux and optics. On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- From: "Rodrigo 1telecom" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 3:24:43 PM Subject: Re: Low cost WDM gear What others vendors do you using? Here in Brazil only PADTEC have this passive solution... Some days ago Digitel contact me to show your multiplex solution... Is a active solution... We import this from fiberstore, but i don't know others vendors to buy 10G sfp+ cwdm and this mux/demux... Enviado via iPhone  Grupo Connectoway Em 07/02/2015, às 16:04, Kenneth McRae escreveu: Hi Enviado, I cannot recommend FiberStore as I had a bad experience with them. I needed to cover only 3km from A to B side. When using 10km optics, I saw a loss of over 5db with their passive mux inserted into the path which created a total loss of over -20db which is outside of the tolerances for our equipment with 10km SFP+. Using another vendors low insertion loss mux corrected our issue. I am sure if you are using an 80km optic, you may be able to tolerate a higher insertion loss to cover < 60km. I also notice that their CDWM optics averaged about 3db less in power output when compared to other vendors. Thanks Kenneth On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom wrote: Hi kenneth... which the distance do you have from side A to side B when you using passive solutions from fiberstore( mux and demux)? I buy this mux and demux(4 channels single fiber) and only make a test about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( only see ddm on my ex3300( about -19db for 60km). Test switch access with ssh and pinging tests... What kind os issue do you have? For distances less than 60km is this solution good? Thanks!!! Enviado via iPhone  Grupo Connectoway Em 07/02/2015, às 14:55, Kenneth McRae escreveu: Mike, I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware equipment. The FiberStore gear was a huge disappointment (excessive loss, poor technical support, refusal to issue refund without threatening legal action, etc.). I have had good results from the OSI equipment so far. I run passive muxes for CWDM (8 - 16 channels). On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: Hi Mike I can recommend a couple of vendors that provide cost effective solutions. Ekinops & Packetlight. On Saturday, February 7, 2015, Mike Hammett wrote: I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com -- TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 656-257-1109* CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient of this information, you are notified that any use, dissemination, distribution, or copying of the communication is strictly prohibited. AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la persona o entidad a la que se dirige y puede contener información privilegiada, confidencial y exenta de divulgación bajo la legislación aplicable. Si no es el destinatario de esta información, se le notifica que cualquier uso, difusión, distribución o copia de la comunicación está estrictamente prohibido. From randy at psg.com Fri Apr 17 01:49:06 2015 From: randy at psg.com (Randy Bush) Date: Fri, 17 Apr 2015 10:49:06 +0900 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> Message-ID: > in any case the idea still seems silly. not if you need to appear to be DOING SOMETHING!!! From frnkblk at iname.com Fri Apr 17 02:07:48 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Thu, 16 Apr 2015 21:07:48 -0500 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: References: <552C51A4.1080200@willscorner.net> <20150414020413.GS3663@tamriel.snowman.net> Message-ID: <000501d078b3$4eaacd40$ec0067c0$@iname.com> It's my educated guess that much of Verizon's initially FTTH deployment used BPON, and that access gear didn't (and probably will never) support IPv6. So to get IPv6 they need to move the customer to a GPON-enabled access shelf, which apparently requires a new ONT because their initial ONTs were BPON only. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin M. Streiner Sent: Monday, April 13, 2015 10:40 PM To: nanog at nanog.org Subject: Re: Galaxy S6 is IPv6 on all US National Mobile carriers On Mon, 13 Apr 2015, Stephen Frost wrote: > I'm still wondering when they're going to teach the Verizon FIOS people > about the IPv6 goodness... I've been barking up that three for nearly the past three years. No definite answers thus far, other than the ONTs deployed in many customer locations might make IPv6 deployment a bit of a PITA, regardless of which model router you have on site. Trying to get good answers on this from VZ sales/marketing contacts through $dayjob has not gotten much in the way of good answers either. I have a v6 tunnel through Hurricane Electric that works very well, but it would be nice to go native. jms From frnkblk at iname.com Fri Apr 17 02:09:40 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Thu, 16 Apr 2015 21:09:40 -0500 Subject: Galaxy S6 is IPv6 on all US National Mobile carriers In-Reply-To: <595edf8298914d349501eee874559a40@pur-vm-exch13n1.ox.com> References: <552C51A4.1080200@willscorner.net> <20150414022545.GF17406@hezmatt.org>, <565F426F-3786-43FF-A9C8-16BC0EC3D54E@cisco.com> <595edf8298914d349501eee874559a40@pur-vm-exch13n1.ox.com> Message-ID: <000601d078b3$91c8f610$b55ae230$@iname.com> My second educated guess is that those initial (BPON) ONTs only supported FastE client interface(s), and that Verizon's new (GPON) ONTs support GigE client interfaces. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Huff Sent: Tuesday, April 14, 2015 10:11 AM To: Joel Esler (jesler); Joe Klein Cc: nanog at nanog.org Subject: RE: Galaxy S6 is IPv6 on all US National Mobile carriers The earlier generation of ONT has 100MB Ethernet and MOCA. If you upgrade to Quantum and order speeds > 100MB you'll need an ONT with gig-E and switch from MOCA to wired Ethernet. The MOCA standard specifies up to 175MB, but I don't think MOCA vendors have made any adapters > 100MB. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joel Esler (jesler) Sent: Tuesday, April 14, 2015 7:17 AM To: Joe Klein Cc: nanog at nanog.org Subject: Re: Galaxy S6 is IPv6 on all US National Mobile carriers I don't believe Quantum has any changes relative to the external of the house. Fios has been capable of pushing those speeds with the "old" modem for years. The difference between the old modem and the new one is that the wireless is 802.11n whereas the old one was only capable of g. -- Joel Esler Sent from my iPhone On Apr 13, 2015, at 11:20 PM, Joe Klein > wrote: Was in a meeting over 4 years ago, where the people from Verizon were claiming they would be rolling out IPv6 for FIOS in the following years. Still waiting. Can anyone confirm or deny that Verizon FIOS requires an upgrade to the ONT and router for its "FiOS Quantum" service in order to get IPv6? Joe Klein "Inveniam viam aut faciam" On Mon, Apr 13, 2015 at 10:25 PM, Matt Palmer > wrote: On Mon, Apr 13, 2015 at 09:42:07PM -0400, Jared Mauch wrote: On Apr 13, 2015, at 9:02 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: On Mon, Apr 13, 2015 at 7:30 PM, Will Dean > wrote: Reddit started using CloudFlare late last year, so they should able to serve content up over v6. nice! Sorry to rain on your parade: dhcp-7f000001:~ jared% host -t aaaa www.reddit.com. www.reddit.com has no AAAA record "should be able to serve" != "are serving". - Matt -- If you are a trauma surgeon and someone dies on your table, [...] everyone would know you "did your best". When someone does something truly stupid with their system and it dies and you can't resuscitate it, you must be incompetent or an idiot. -- Julian Macassey, in the Monastery From morrowc.lists at gmail.com Fri Apr 17 03:31:21 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 16 Apr 2015 23:31:21 -0400 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> Message-ID: On Thu, Apr 16, 2015 at 9:49 PM, Randy Bush wrote: >> in any case the idea still seems silly. > > not if you need to appear to be DOING SOMETHING!!! to be fair, I do tend to forget this point :( From randy at psg.com Fri Apr 17 03:40:49 2015 From: randy at psg.com (Randy Bush) Date: Fri, 17 Apr 2015 12:40:49 +0900 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> Message-ID: <10B01152-9AAC-4747-BB04-F6BA3C0E5A23@psg.com> It's only a problem when it distracts from actually doing something. randy, please excuse tiPos > On Apr 17, 2015, at 12:31, Christopher Morrow wrote: > > On Thu, Apr 16, 2015 at 9:49 PM, Randy Bush wrote: >>> in any case the idea still seems silly. >> >> not if you need to appear to be DOING SOMETHING!!! > > to be fair, I do tend to forget this point :( From mark.tinka at seacom.mu Fri Apr 17 05:43:04 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 17 Apr 2015 07:43:04 +0200 Subject: Peering and Network Cost In-Reply-To: <20150416090053.4c01330c@echo.ms.redpill-linpro.com> References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> <20150416090053.4c01330c@echo.ms.redpill-linpro.com> Message-ID: <55309D68.7000703@seacom.mu> On 16/Apr/15 09:00, Tore Anderson wrote: > You appear to be assuming that an IP transit port is more expensive > then an IXP port with the same speed. That doesn't seem to always be > the case anymore, at least not in all parts of the world, and I expect > this trend to continue - transit prices seems to go down almost on a > monthly basis, while the price lists of the two closest IXPs to where > I'm sitting are dated 2011 and 2013, respectively. Agreed. > > Even if the transit port itself remains slightly more expensive than > the IXP port like in the example Baldur showed, the no-peering > alternative might still be cheaper overall because even if you're > peering most of your traffic you'll still need to pay a nonzero amount > for a (smaller or less utilised) transit port anyway. Agreed again. Mark. From maxtul at netassist.ua Fri Apr 17 10:33:04 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 17 Apr 2015 13:33:04 +0300 Subject: Peering and Network Cost In-Reply-To: <26042041.7346.1429123494063.JavaMail.mhammett@ThunderFuck> References: <26042041.7346.1429123494063.JavaMail.mhammett@ThunderFuck> Message-ID: <5530E160.9060207@netassist.ua> If you have so much difference in price of IX connectivity (in general, including cabling, DWDM to one of major IX, colo, etc) - this only mean you should have a long talk with your current IP transit sales. Or just change it to another one. On 04/15/15 21:45, Mike Hammett wrote: > (Reply to thread, not necessarily myself.) > > If you can pull a third of your traffic off at the cost of a cross connect and another third at the cost of an IX port, now you can spend a buck or two a meg on what's left. Yes, I understand the cost of a cross connect or IX port is the $/megabit you're actually using and not $/megabit of capacity. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Mike Hammett" > To: "Max Tulyev" > Cc: nanog at nanog.org > Sent: Wednesday, April 15, 2015 1:33:35 PM > Subject: Re: Peering and Network Cost > > Very true. I left it as I did given that I expect a similar profile from others in North America... on NANOG. > > Basically, wherever your region's streaming video or application updates come from. ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Wednesday, April 15, 2015 1:27:45 PM > Subject: Re: Peering and Network Cost > > Not actually Facebook net, but Akamai CDN. Not a Google (peer), but GCC > node ;) > > It is varying from location to location. For example here in Ukraine we > (still) have 1st place for traffic amount from Vkontakte (mostly music > streams), second from EX.ua (movie store), but almost none NetFlix, Hulu > or Amazon. And you can't get both of them in a good quality neither at > IXes, nor at Tier1. > > I think in another locations, for example in India, traffic profile will > be different from both of us, and have some local specific as well. > > On 04/15/15 20:58, Mike Hammett wrote: >> It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. >> >> A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Max Tulyev" >> To: nanog at nanog.org >> Sent: Wednesday, April 15, 2015 12:50:41 PM >> Subject: Re: Peering and Network Cost >> >> Hi Roderick, >> >> transit cost is lowering close to peering cost, so it is doubghtful >> economy on small channels. If you don't live in >> Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major >> IX. That's the magic. >> >> In large scale peering is still efficient. It is efficient on local >> traffic which is often huge. >> >> On 04/15/15 17:28, Rod Beck wrote: >>> Hi, >>> >>> >>> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >>> >>> >>> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >>> >>> >>> I thank you in advance for any insights. >>> >>> >>> Regards, >>> >>> >>> - R. >>> >>> >>> Roderick Beck >>> Sales Director/Europe and the Americas >>> Hibernia Networks >>> >>> This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry > >> out your >> >> own virus checks before opening any attachment. >>> >> >> >> > > > > From maxtul at netassist.ua Fri Apr 17 10:35:49 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 17 Apr 2015 13:35:49 +0300 Subject: Peering and Network Cost In-Reply-To: <552EC622.8090004@Janoszka.pl> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> Message-ID: <5530E205.4020002@netassist.ua> For sure, that's the main reason of peering, not a cost saving ;) On 04/15/15 23:12, Grzegorz Janoszka wrote: > Please keep in mind that some companies peer despite it offers no > savings for them and at the end of the day it might be even more > expensive. They do it because of performance and reliability reasons. From mark.tinka at seacom.mu Fri Apr 17 10:40:05 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 17 Apr 2015 12:40:05 +0200 Subject: Peering and Network Cost In-Reply-To: <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> <20150416090053.4c01330c@echo.ms.redpill-linpro.com> <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> Message-ID: <5530E305.30109@seacom.mu> On 16/Apr/15 17:10, Edward Dore wrote: > > I don't have any quantifiable data on what has happened to IP transit > costs over the same period, but for a point comparison I'd say that > off the top of my head you can get a 1G CDR on a 10G port from a > tier-1 provider in London for approximately the same cost as a 10G > port at LINX these days, maybe slightly cheaper. Transit costs are certainly falling at a much faster rate than exchange point ports. However, because most major exchange points are pushing reasonably high ports (1Gbps and 10Gbps) to members, the challenge with filling those ports makes transit ports a more viable solution in the short term. If you're willing to stick it out long enough, peering ports can become as cheap as transit ports, but they will never give you 100% coverage like a transit port can. Mark. From israel.lugo at lugosys.com Fri Apr 17 10:40:31 2015 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Fri, 17 Apr 2015 11:40:31 +0100 Subject: Looking for core L3 switch for campus network; feedback on Juniper EX8208? Message-ID: <5530E31F.8050005@lugosys.com> Hello, I'm thinking of buying a Juniper EX8208 to serve as the core L3 switch on an collapsed campus network (faculty, academia). Rough figures: around 6,000 eyeballs, up to around 10,000 MACs, spread over some 30 buildings of varying size. OM2/OM3 fiber from the buildings to the core, using 1Gb optics. Planning to upgrade to monomode within 2 years and may migrate some buildings to 10 Gb. >From the spec sheets, the EX8208 seems to fit the bill. It will be teaming up with an older Alcatel L3 switch, which will work as backup. VRRP, OSPF, MSTP. It'll be replacing another Alcatel L3 switch that we're sending back due to way too many bugs and reliability issues over the 1.5 year span that we had it. We are fully IPv6 dual-stack (for over 10 years now), so this needs to support fully working OSPFv3, VRRPv3, MLD and so on. According to the manuals for the EX line, that seems to be the case (with some limitations regarding OSPFv3, it seems). Access and aggregation switches are mostly Alcatel. There are a few other routers for VLANs with specific requirements (NAT, firewalling, etc). All using OSPFv2 and OSPFv3. I'd welcome any feedback regarding the EX820x, positive or negative. Bugs, support quality, stability issues, scalability, IPv6 support... I could go up to the EX9200 if necessary. I've had very good experience with the SRX2x0 line in a separate setting, and Juniper TAC in general always seemed quite good. Of course the EX8200 is a different ballpark so things may be different. I'm curious for example: as a switch, I'd expect the EX8200 to work in packet mode, yes? Or does it have flowd and its security {...} section? I wouldn't really use the flow features at this level and wouldn't like to have it there waiting to catch a bug from some weird packets thrown at it. Thank you for reading. Regards, Israel G. Lugo From nanog at ics-il.net Fri Apr 17 11:51:09 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 17 Apr 2015 06:51:09 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: <5530E160.9060207@netassist.ua> Message-ID: <26454871.10698.1429271447906.JavaMail.mhammett@ThunderFuck> Transit should cost more than peering and should never cost little more than the cost of a cross connect or a switch, given the load of additional responsibilities. I counter that if peering is cheaper than transit, you need to talk to your IX about it's cost models. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Friday, April 17, 2015 5:33:04 AM Subject: Re: Peering and Network Cost If you have so much difference in price of IX connectivity (in general, including cabling, DWDM to one of major IX, colo, etc) - this only mean you should have a long talk with your current IP transit sales. Or just change it to another one. On 04/15/15 21:45, Mike Hammett wrote: > (Reply to thread, not necessarily myself.) > > If you can pull a third of your traffic off at the cost of a cross connect and another third at the cost of an IX port, now you can spend a buck or two a meg on what's left. Yes, I understand the cost of a cross connect or IX port is the $/megabit you're actually using and not $/megabit of capacity. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Mike Hammett" > To: "Max Tulyev" > Cc: nanog at nanog.org > Sent: Wednesday, April 15, 2015 1:33:35 PM > Subject: Re: Peering and Network Cost > > Very true. I left it as I did given that I expect a similar profile from others in North America... on NANOG. > > Basically, wherever your region's streaming video or application updates come from. ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Wednesday, April 15, 2015 1:27:45 PM > Subject: Re: Peering and Network Cost > > Not actually Facebook net, but Akamai CDN. Not a Google (peer), but GCC > node ;) > > It is varying from location to location. For example here in Ukraine we > (still) have 1st place for traffic amount from Vkontakte (mostly music > streams), second from EX.ua (movie store), but almost none NetFlix, Hulu > or Amazon. And you can't get both of them in a good quality neither at > IXes, nor at Tier1. > > I think in another locations, for example in India, traffic profile will > be different from both of us, and have some local specific as well. > > On 04/15/15 20:58, Mike Hammett wrote: >> It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. >> >> A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Max Tulyev" >> To: nanog at nanog.org >> Sent: Wednesday, April 15, 2015 12:50:41 PM >> Subject: Re: Peering and Network Cost >> >> Hi Roderick, >> >> transit cost is lowering close to peering cost, so it is doubghtful >> economy on small channels. If you don't live in >> Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major >> IX. That's the magic. >> >> In large scale peering is still efficient. It is efficient on local >> traffic which is often huge. >> >> On 04/15/15 17:28, Rod Beck wrote: >>> Hi, >>> >>> >>> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >>> >>> >>> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >>> >>> >>> I thank you in advance for any insights. >>> >>> >>> Regards, >>> >>> >>> - R. >>> >>> >>> Roderick Beck >>> Sales Director/Europe and the Americas >>> Hibernia Networks >>> >>> This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carr y > >> out your >> >> own virus checks before opening any attachment. >>> >> >> >> > > > > From nanog at ics-il.net Fri Apr 17 11:54:54 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 17 Apr 2015 06:54:54 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: <26454871.10698.1429271447906.JavaMail.mhammett@ThunderFuck> Message-ID: <26301857.10746.1429271675720.JavaMail.mhammett@ThunderFuck> Errrr, countering that if transit is cheaper than peering, you should talk to your IX. The effects of posting when I haven't been awake for hardy more than ten minutes.... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Hammett" To: nanog at nanog.org Sent: Friday, April 17, 2015 6:51:09 AM Subject: Re: Peering and Network Cost Transit should cost more than peering and should never cost little more than the cost of a cross connect or a switch, given the load of additional responsibilities. I counter that if peering is cheaper than transit, you need to talk to your IX about it's cost models. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Max Tulyev" To: nanog at nanog.org Sent: Friday, April 17, 2015 5:33:04 AM Subject: Re: Peering and Network Cost If you have so much difference in price of IX connectivity (in general, including cabling, DWDM to one of major IX, colo, etc) - this only mean you should have a long talk with your current IP transit sales. Or just change it to another one. On 04/15/15 21:45, Mike Hammett wrote: > (Reply to thread, not necessarily myself.) > > If you can pull a third of your traffic off at the cost of a cross connect and another third at the cost of an IX port, now you can spend a buck or two a meg on what's left. Yes, I understand the cost of a cross connect or IX port is the $/megabit you're actually using and not $/megabit of capacity. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Mike Hammett" > To: "Max Tulyev" > Cc: nanog at nanog.org > Sent: Wednesday, April 15, 2015 1:33:35 PM > Subject: Re: Peering and Network Cost > > Very true. I left it as I did given that I expect a similar profile from others in North America... on NANOG. > > Basically, wherever your region's streaming video or application updates come from. ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Max Tulyev" > To: nanog at nanog.org > Sent: Wednesday, April 15, 2015 1:27:45 PM > Subject: Re: Peering and Network Cost > > Not actually Facebook net, but Akamai CDN. Not a Google (peer), but GCC > node ;) > > It is varying from location to location. For example here in Ukraine we > (still) have 1st place for traffic amount from Vkontakte (mostly music > streams), second from EX.ua (movie store), but almost none NetFlix, Hulu > or Amazon. And you can't get both of them in a good quality neither at > IXes, nor at Tier1. > > I think in another locations, for example in India, traffic profile will > be different from both of us, and have some local specific as well. > > On 04/15/15 20:58, Mike Hammett wrote: >> It also depends on traffic makeup. Huge amounts of eyeball traffic go to (well, come from) NetFlix (a third) and Google, FaceBook, Hulu, Amazon, etc. (another third). It's comparable price to peer off those few huge sources of traffic and buy better transit than you would have than to just buy cheap transit. >> >> A lot of people tend to forget there are thousands of independent ISPs out there, usually in areas where there aren't a breadth of providers in the first place. Most could get buy with a single GigE (or even less). >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Max Tulyev" >> To: nanog at nanog.org >> Sent: Wednesday, April 15, 2015 12:50:41 PM >> Subject: Re: Peering and Network Cost >> >> Hi Roderick, >> >> transit cost is lowering close to peering cost, so it is doubghtful >> economy on small channels. If you don't live in >> Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major >> IX. That's the magic. >> >> In large scale peering is still efficient. It is efficient on local >> traffic which is often huge. >> >> On 04/15/15 17:28, Rod Beck wrote: >>> Hi, >>> >>> >>> As you all know, transit costs in the wholesale market today a few percent of what it did in 2000. I assume that most of that decline is due to a modified version of Moore's Law (I don't believe optics costs decline 50% every 18 months) and the advent of maverick players like Cogent that broker cozy oligopoly pricing. >>> >>> >>> But I also wondering whether the advent of widespread peering (promiscuous?) among the Tier 2 players (buy transit and peer) has played a role. In 2000 peering was still an exclusive club and in contrast today Tier 2 players often have hundreds of peers. Peering should reduce costs and also demand in the wholesale IP market. Supply increases and demand falls. >>> >>> >>> I thank you in advance for any insights. >>> >>> >>> Regards, >>> >>> >>> - R. >>> >>> >>> Roderick Beck >>> Sales Director/Europe and the Americas >>> Hibernia Networks >>> >>> This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carr y > >> out your >> >> own virus checks before opening any attachment. >>> >> >> >> > > > > From maxtul at netassist.ua Fri Apr 17 13:05:21 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 17 Apr 2015 16:05:21 +0300 Subject: Peering and Network Cost In-Reply-To: <552EC622.8090004@Janoszka.pl> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> Message-ID: <55310511.5060308@netassist.ua> One more interesting thing. If you buy IP transit, mostly you are paying by exact bandwidth, per megabit. If you buy IX peering port, you are paying for port. This means Tranist ports are overloaded or close to it, while IX ports usually always have some extra free capacity. In practice, this mean if your customer download some file using IX way, speed will be much higher that same file reachable by IP transit. So more peerings your uplink use - better performance of your network connection you have ;) On 04/15/15 23:12, Grzegorz Janoszka wrote: > On 2015-04-15 19:50, Max Tulyev wrote: >> transit cost is lowering close to peering cost, so it is doubghtful >> economy on small channels. If you don't live in >> Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major >> IX. That's the magic. >> >> In large scale peering is still efficient. It is efficient on local >> traffic which is often huge. > > Even in the three cities you mentioned peering on small scale is usually > not cheaper at all or only very little. > > Please keep in mind that some companies peer despite it offers no > savings for them and at the end of the day it might be even more > expensive. They do it because of performance and reliability reasons. > From lists at mtin.net Fri Apr 17 15:53:49 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Fri, 17 Apr 2015 11:53:49 -0400 Subject: Peering and Network Cost In-Reply-To: <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> References: <1429104508516.63849@hibernianetworks.com> <20150416072545.578b757f@echo.ms.redpill-linpro.com> <552F5374.5080202@seacom.mu> <20150416090053.4c01330c@echo.ms.redpill-linpro.com> <8E740079-528D-4C55-9BD0-8884A9EDC139@freethought-internet.co.uk> Message-ID: <9EBC7271-76AA-4771-936D-E0794A7E9920@mtin.net> Peering and peering on an exchange are two different things. Peering at an exchange has several benefits other than the simple cost of transit. If you are in a large data center which charges fees for cross connects a single cross connect to an exchange can save you money. Peering can also be a sales tool. If you buy from a VOIP provider and are peered with them your latency and such will go down. You also have more control over the QOS over that peer. This can be spun into marketing. Not to toot our own horn but we put together a list of benefits for our IX customers: http://www.midwest-ix.com/blog/?p=15 Also, a good article at: http://blog.webserver.com.my/index.php/the-benefits-of-hosting-at-internet-exchange-point/ Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Apr 16, 2015, at 11:10 AM, Edward Dore wrote: > > On 16 Apr 2015, at 08:00, Tore Anderson wrote: > >> * Mark Tinka >> >>> On 16/Apr/15 07:25, Tore Anderson wrote: >>>> We're in a similar situation here; transit prices has come down so >>>> much in recent years (while IX fees are indeed stagnant) that I am >>>> certain that if I were to cut all peering and buy everything from a >>>> regional tier-2 instead, I'd be lowering my total MRC somewhat, >>>> without really reducing connectivity quality to my (former) peers. >>> >>> I wouldn't say exchange point prices are stagnant, per se. They may >>> remain the same, but what goes up is the port bandwidth. It's not >>> directly linear, but you get my point. >>> >>> Again, the burden is on the peering members to extract the most out of >>> their peering links by having as much peering as possible. >> >> You appear to be assuming that an IP transit port is more expensive >> then an IXP port with the same speed. That doesn't seem to always be >> the case anymore, at least not in all parts of the world, and I expect >> this trend to continue - transit prices seems to go down almost on a >> monthly basis, while the price lists of the two closest IXPs to where >> I'm sitting are dated 2011 and 2013, respectively. >> >> Even if the transit port itself remains slightly more expensive than >> the IXP port like in the example Baldur showed, the no-peering >> alternative might still be cheaper overall because even if you're >> peering most of your traffic you'll still need to pay a nonzero amount >> for a (smaller or less utilised) transit port anyway. >> >> Tore > > Pricing at LINX here in the UK has definitely dropped over the past few years. > > Back in 2011, the membership fee was £1500/year and it's now £1200/year. > > 1G ports were £391/month on the first London LAN and £335/month on the second London LAN. They're now free on both LANs for the first port and then £270/month and £180/month respectively for additional ports. > You can also get a free 1G port on each of the Manchester UK, Cardiff UK, Edinburgh UK and North Virginia/Washington DC USA LANs as part of the same membership fee (none of these additional LANs existed in 2011). > > 10G ports were £1463/month on the first London LAN and £1250/month on the second London LAN. They're now £1030/month and £785/month respectively. > > So that's what, a 20% reduction in membership fees and a 30% or higher (depending on the service) reduction in port fees in 4 years? > > I don't have any quantifiable data on what has happened to IP transit costs over the same period, but for a point comparison I'd say that off the top of my head you can get a 1G CDR on a 10G port from a tier-1 provider in London for approximately the same cost as a 10G port at LINX these days, maybe slightly cheaper. > > Edward Dore > Freethought Internet From cscora at apnic.net Fri Apr 17 18:11:55 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Apr 2015 04:11:55 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201504171811.t3HIBt1l004314@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 18 Apr, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 540786 Prefixes after maximum aggregation (per Origin AS): 206550 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 263869 Total ASes present in the Internet Routing Table: 50040 Prefixes per ASN: 10.81 Origin-only ASes present in the Internet Routing Table: 36566 Origin ASes announcing only one prefix: 16289 Transit ASes present in the Internet Routing Table: 6330 Transit-only ASes present in the Internet Routing Table: 176 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 45 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1189 Unregistered ASNs in the Routing Table: 415 Number of 32-bit ASNs allocated by the RIRs: 9182 Number of 32-bit ASNs visible in the Routing Table: 7144 Prefixes from 32-bit ASNs in the Routing Table: 25731 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 363 Number of addresses announced to Internet: 2739671460 Equivalent to 163 /8s, 76 /16s and 17 /24s Percentage of available address space announced: 74.0 Percentage of allocated address space announced: 74.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 182096 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133387 Total APNIC prefixes after maximum aggregation: 38870 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 139137 Unique aggregates announced from the APNIC address blocks: 56770 APNIC Region origin ASes present in the Internet Routing Table: 5035 APNIC Prefixes per ASN: 27.63 APNIC Region origin ASes announcing only one prefix: 1204 APNIC Region transit ASes present in the Internet Routing Table: 872 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 45 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1385 Number of APNIC addresses announced to Internet: 747587072 Equivalent to 44 /8s, 143 /16s and 70 /24s Percentage of available APNIC address space announced: 87.4 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, 131072-135580 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: 178405 Total ARIN prefixes after maximum aggregation: 87876 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 180813 Unique aggregates announced from the ARIN address blocks: 84713 ARIN Region origin ASes present in the Internet Routing Table: 16543 ARIN Prefixes per ASN: 10.93 ARIN Region origin ASes announcing only one prefix: 6081 ARIN Region transit ASes present in the Internet Routing Table: 1726 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 402 Number of ARIN addresses announced to Internet: 1064773152 Equivalent to 63 /8s, 119 /16s and 38 /24s Percentage of available ARIN address space announced: 56.3 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, 393216-394239 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: 131149 Total RIPE prefixes after maximum aggregation: 65580 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 137384 Unique aggregates announced from the RIPE address blocks: 84757 RIPE Region origin ASes present in the Internet Routing Table: 17947 RIPE Prefixes per ASN: 7.65 RIPE Region origin ASes announcing only one prefix: 8171 RIPE Region transit ASes present in the Internet Routing Table: 2987 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3613 Number of RIPE addresses announced to Internet: 693973636 Equivalent to 41 /8s, 93 /16s and 50 /24s Percentage of available RIPE address space announced: 100.9 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, 196608-202239 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: 59161 Total LACNIC prefixes after maximum aggregation: 11164 LACNIC Deaggregation factor: 5.30 Prefixes being announced from the LACNIC address blocks: 69111 Unique aggregates announced from the LACNIC address blocks: 32165 LACNIC Region origin ASes present in the Internet Routing Table: 2429 LACNIC Prefixes per ASN: 28.45 LACNIC Region origin ASes announcing only one prefix: 630 LACNIC Region transit ASes present in the Internet Routing Table: 499 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1636 Number of LACNIC addresses announced to Internet: 168062720 Equivalent to 10 /8s, 4 /16s and 111 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12783 Total AfriNIC prefixes after maximum aggregation: 3016 AfriNIC Deaggregation factor: 4.24 Prefixes being announced from the AfriNIC address blocks: 13978 Unique aggregates announced from the AfriNIC address blocks: 5137 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 18.99 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 162 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 108 Number of AfriNIC addresses announced to Internet: 64834816 Equivalent to 3 /8s, 221 /16s and 77 /24s Percentage of available AfriNIC address space announced: 64.4 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 4766 2920 11557 912 Korea Telecom 17974 2792 904 78 PT Telekomunikasi Indonesia 7545 2555 336 128 TPG Telecom Limited 4755 2004 422 212 TATA Communications formerly 4538 1760 4190 71 China Education and Research 9829 1660 1326 39 National Internet Backbone 9808 1570 8717 28 Guangdong Mobile Communicatio 4808 1442 2244 447 CNCGROUP IP network China169 9583 1407 116 575 Sify Limited 9498 1320 334 94 BHARTI Airtel Ltd. 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 3017 2956 143 Cox Communications Inc. 6389 2842 3688 51 BellSouth.net Inc. 3356 2560 10700 489 Level 3 Communications, Inc. 18566 2039 379 182 MegaPath Corporation 20115 1876 1832 430 Charter Communications 6983 1754 866 245 EarthLink, Inc. 4323 1616 1020 407 tw telecom holdings, inc. 30036 1517 309 509 Mediacom Communications Corp 701 1409 11276 693 MCI Communications Services, 22561 1341 412 243 CenturyTel Internet Holdings, 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 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1957 303 365 TELLCOM ILETISIM HIZMETLERI A 20940 1793 699 1326 Akamai International B.V. 6849 1212 356 24 JSC "Ukrtelecom" 8402 1124 544 15 OJSC "Vimpelcom" 31148 1046 45 21 Freenet Ltd. 13188 1034 96 71 TOV "Bank-Inform" 12479 902 863 85 France Telecom Espana SA 8551 886 373 48 Bezeq International-Ltd 6830 855 2345 453 Liberty Global Operations B.V 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 3197 520 192 Telmex Colombia S.A. 28573 2339 2179 122 NET Servi�os de Comunica��o S 7303 1694 1087 238 Telecom Argentina S.A. 6147 1625 374 30 Telefonica del Peru S.A.A. 8151 1590 3187 454 Uninet S.A. de C.V. 6503 1237 421 57 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 982 2325 35 Tim Celular S.A. 3816 923 418 154 COLOMBIA TELECOMUNICACIONES S 18881 866 1036 22 Global Village Telecom 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 8452 1703 958 13 TE-AS 24863 964 284 27 Link Egypt (Link.NET) 36903 492 248 93 Office National des Postes et 36992 417 1229 32 ETISALAT MISR 37492 302 155 72 Orange Tunisie 24835 300 144 9 Vodafone Data 3741 249 857 208 Internet Solutions 29571 231 21 12 Cote d'Ivoire Telecom 36947 198 807 13 Telecom Algeria 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3197 520 192 Telmex Colombia S.A. 22773 3017 2956 143 Cox Communications Inc. 4766 2920 11557 912 Korea Telecom 6389 2842 3688 51 BellSouth.net Inc. 17974 2792 904 78 PT Telekomunikasi Indonesia 3356 2560 10700 489 Level 3 Communications, Inc. 7545 2555 336 128 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2339 2179 122 NET Servi�os de Comunica��o S 18566 2039 379 182 MegaPath Corporation 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 3017 2874 Cox Communications Inc. 6389 2842 2791 BellSouth.net Inc. 17974 2792 2714 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2555 2427 TPG Telecom Limited 28573 2339 2217 NET Servi�os de Comunica��o S 3356 2560 2071 Level 3 Communications, Inc. 4766 2920 2008 Korea Telecom 18566 2039 1857 MegaPath Corporation 4755 2004 1792 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 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:12 /10:34 /11:94 /12:262 /13:508 /14:998 /15:1719 /16:12953 /17:7200 /18:12211 /19:25344 /20:35909 /21:38551 /22:58855 /23:51392 /24:291715 /25:1130 /26:1129 /27:708 /28:14 /29:11 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2225 3017 Cox Communications Inc. 18566 1995 2039 MegaPath Corporation 6389 1657 2842 BellSouth.net Inc. 6983 1401 1754 EarthLink, Inc. 30036 1362 1517 Mediacom Communications Corp 34984 1283 1957 TELLCOM ILETISIM HIZMETLERI A 6147 1171 1625 Telefonica del Peru S.A.A. 10620 1131 3197 Telmex Colombia S.A. 11492 1106 1173 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1484 2:670 4:93 5:1743 6:23 8:1414 12:1825 13:9 14:1308 15:17 16:2 17:44 18:21 20:48 23:1202 24:1718 27:1880 31:1526 32:38 33:2 34:5 35:3 36:117 37:1898 38:1019 39:5 40:252 41:3001 42:267 43:1245 44:25 45:441 46:2110 47:38 49:844 50:800 52:12 54:73 55:4 56:8 57:37 58:1221 59:674 60:469 61:1751 62:1327 63:1915 64:4424 65:2251 66:4090 67:2069 68:1078 69:3270 70:960 71:445 72:1955 74:2658 75:323 76:403 77:1457 78:1188 79:801 80:1299 81:1345 82:815 83:688 84:710 85:1372 86:395 87:1075 88:509 89:1821 90:151 91:5979 92:831 93:2212 94:1984 95:2091 96:430 97:355 98:1059 99:48 100:68 101:815 103:7218 104:1580 105:62 106:244 107:931 108:621 109:2024 110:1088 111:1491 112:782 113:1065 114:810 115:1260 116:1364 117:999 118:1752 119:1446 120:453 121:1037 122:2216 123:1753 124:1509 125:1588 128:541 129:379 130:386 131:1178 132:488 133:174 134:418 135:109 136:307 137:326 138:629 139:151 140:242 141:421 142:657 143:517 144:572 145:112 146:715 147:589 148:1120 149:432 150:572 151:606 152:492 153:242 154:441 155:744 156:407 157:462 158:318 159:985 160:376 161:646 162:1954 163:419 164:670 165:682 166:288 167:805 168:1282 169:162 170:1468 171:240 172:41 173:1529 174:706 175:676 176:1353 177:3771 178:2067 179:880 180:1940 181:1666 182:1731 183:619 184:740 185:3301 186:2644 187:1765 188:2022 189:1562 190:7639 191:950 192:8266 193:5582 194:4124 195:3657 196:1715 197:1086 198:5531 199:5531 200:6522 201:3043 202:9468 203:9104 204:4692 205:2840 206:3098 207:2980 208:3939 209:3942 210:3515 211:1859 212:2461 213:2289 214:855 215:71 216:5571 217:1802 218:685 219:455 220:1442 221:787 222:466 223:666 End of report From ag4ve.us at gmail.com Fri Apr 17 18:44:28 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 17 Apr 2015 14:44:28 -0400 Subject: rack cable length Message-ID: This is probably a stupid question, but.... We've got a few racks in a colo. The racks don't have any decent cable management (square metal holes to attach velcro to). We either order cable too long and end up with lots of loops which get in the way (no place to loop lots of excess really) or too short to run along the side (which is worse). It appears others using the same racks have figured this out, but... Do y'all just order 10 of each size per rack in every color you need or is there a better way to figure this out? I'm guessing something like 24 inches + 1.75 inchex x Us) + 24 inches and round up to standard length...? From Daniel.Jameson at tdstelecom.com Fri Apr 17 18:59:10 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Fri, 17 Apr 2015 18:59:10 +0000 Subject: rack cable length In-Reply-To: References: Message-ID: Cables should be within 2 feet of the total distance, if you order a stack several sizes too long then add something like above/below the switch: http://www.chatsworth.com/products/cable-management/horizontal-cable-management/ Slack should never be stored in the vertical, only in the horizontal. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of shawn wilson Sent: Friday, April 17, 2015 1:44 PM To: North American Network Operators Group Subject: rack cable length This is probably a stupid question, but.... We've got a few racks in a colo. The racks don't have any decent cable management (square metal holes to attach velcro to). We either order cable too long and end up with lots of loops which get in the way (no place to loop lots of excess really) or too short to run along the side (which is worse). It appears others using the same racks have figured this out, but... Do y'all just order 10 of each size per rack in every color you need or is there a better way to figure this out? I'm guessing something like 24 inches + 1.75 inchex x Us) + 24 inches and round up to standard length...? From rafael at gav.ufsc.br Fri Apr 17 19:00:17 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 17 Apr 2015 14:00:17 -0500 Subject: rack cable length In-Reply-To: References: Message-ID: Hi Shawn, If you don't leave slack, you can't really pull the server out of the RU for maintenance (hot swaps, etc). Your best choice is to purchase cable management trays if that makes sense (Dell servers usually come with those). Otherwise you just need to deal with the loops and whatnot the best way you can. If your colo hardware is really random (dells, HPs, supermicros) then it gets worse, but if your hardware is homogeneous then you can come up with some way of attaching brackets to the side of the rack that could help you avoid a rats nest in the back of your rack (granted you can't find cable management trays or they are too expensive to justify the investment). On Fri, Apr 17, 2015 at 1:44 PM, shawn wilson wrote: > This is probably a stupid question, but.... > > We've got a few racks in a colo. The racks don't have any decent cable > management (square metal holes to attach velcro to). We either order > cable too long and end up with lots of loops which get in the way (no > place to loop lots of excess really) or too short to run along the > side (which is worse). It appears others using the same racks have > figured this out, but... > > Do y'all just order 10 of each size per rack in every color you need > or is there a better way to figure this out? I'm guessing something > like 24 inches + 1.75 inchex x Us) + 24 inches and round up to > standard length...? > From jmcleod at musfiber.net Fri Apr 17 19:17:34 2015 From: jmcleod at musfiber.net (Joe McLeod) Date: Fri, 17 Apr 2015 19:17:34 +0000 Subject: rack cable length In-Reply-To: References: Message-ID: Or you build the cable to fit the span. I must be getting old. Joe -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rafael Possamai Sent: Friday, April 17, 2015 3:00 PM To: North American Network Operators Group Subject: Re: rack cable length Hi Shawn, If you don't leave slack, you can't really pull the server out of the RU for maintenance (hot swaps, etc). Your best choice is to purchase cable management trays if that makes sense (Dell servers usually come with those). Otherwise you just need to deal with the loops and whatnot the best way you can. If your colo hardware is really random (dells, HPs, supermicros) then it gets worse, but if your hardware is homogeneous then you can come up with some way of attaching brackets to the side of the rack that could help you avoid a rats nest in the back of your rack (granted you can't find cable management trays or they are too expensive to justify the investment). On Fri, Apr 17, 2015 at 1:44 PM, shawn wilson wrote: > This is probably a stupid question, but.... > > We've got a few racks in a colo. The racks don't have any decent cable > management (square metal holes to attach velcro to). We either order > cable too long and end up with lots of loops which get in the way (no > place to loop lots of excess really) or too short to run along the > side (which is worse). It appears others using the same racks have > figured this out, but... > > Do y'all just order 10 of each size per rack in every color you need > or is there a better way to figure this out? I'm guessing something > like 24 inches + 1.75 inchex x Us) + 24 inches and round up to > standard length...? > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From bob at FiberInternetCenter.com Fri Apr 17 19:22:46 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 17 Apr 2015 12:22:46 -0700 Subject: rack cable length In-Reply-To: References: Message-ID: You must build them if you want the professional look. No way around that - unless you want to take up rack space with some sort of cable management wrapping system and that becomes a pain to make future changes or replace cables. Thank You Bob Evans CTO > Or you build the cable to fit the span. I must be getting old. > > Joe > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rafael Possamai > Sent: Friday, April 17, 2015 3:00 PM > To: North American Network Operators Group > Subject: Re: rack cable length > > Hi Shawn, > > If you don't leave slack, you can't really pull the server out of the RU > for maintenance (hot swaps, etc). Your best choice is to purchase cable > management trays if that makes sense (Dell servers usually come with > those). Otherwise you just need to deal with the loops and whatnot the > best way you can. If your colo hardware is really random (dells, HPs, > supermicros) then it gets worse, but if your hardware is homogeneous then > you can come up with some way of attaching brackets to the side of the > rack that could help you avoid a rats nest in the back of your rack > (granted you can't find cable management trays or they are too expensive > to justify the investment). > > > > On Fri, Apr 17, 2015 at 1:44 PM, shawn wilson wrote: > >> This is probably a stupid question, but.... >> >> We've got a few racks in a colo. The racks don't have any decent cable >> management (square metal holes to attach velcro to). We either order >> cable too long and end up with lots of loops which get in the way (no >> place to loop lots of excess really) or too short to run along the >> side (which is worse). It appears others using the same racks have >> figured this out, but... >> >> Do y'all just order 10 of each size per rack in every color you need >> or is there a better way to figure this out? I'm guessing something >> like 24 inches + 1.75 inchex x Us) + 24 inches and round up to >> standard length...? >> > > > -- > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > From lists at mtin.net Fri Apr 17 19:23:05 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Fri, 17 Apr 2015 15:23:05 -0400 Subject: rack cable length In-Reply-To: References: Message-ID: <2E339240-2EDB-4911-B5F8-5E3039B7D9B5@mtin.net> Copper and fiber patch panels are key. This way you can control the length from the patch to the device (router, switch,server). Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Apr 17, 2015, at 2:44 PM, shawn wilson wrote: > > This is probably a stupid question, but.... > > We've got a few racks in a colo. The racks don't have any decent cable > management (square metal holes to attach velcro to). We either order > cable too long and end up with lots of loops which get in the way (no > place to loop lots of excess really) or too short to run along the > side (which is worse). It appears others using the same racks have > figured this out, but... > > Do y'all just order 10 of each size per rack in every color you need > or is there a better way to figure this out? I'm guessing something > like 24 inches + 1.75 inchex x Us) + 24 inches and round up to > standard length...? > From ag4ve.us at gmail.com Fri Apr 17 19:32:46 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 17 Apr 2015 15:32:46 -0400 Subject: rack cable length In-Reply-To: <2E339240-2EDB-4911-B5F8-5E3039B7D9B5@mtin.net> References: <2E339240-2EDB-4911-B5F8-5E3039B7D9B5@mtin.net> Message-ID: On Fri, Apr 17, 2015 at 3:23 PM, Justin Wilson - MTIN wrote: > Copper and fiber patch panels are key. This way you can control the length from the patch to the device (router, switch,server). > Yeah, I am talking about just the runs in the rack - I don't see a(nother) patch panel helping here. From ag4ve.us at gmail.com Fri Apr 17 19:36:11 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 17 Apr 2015 15:36:11 -0400 Subject: rack cable length In-Reply-To: References: Message-ID: On Fri, Apr 17, 2015 at 3:22 PM, Bob Evans wrote: > You must build them if you want the professional look. No way around that > - unless you want to take up rack space with some sort of cable management > wrapping system and that becomes a pain to make future changes or replace > cables. > >> Or you build the cable to fit the span. I must be getting old. >> I've found that the pre-crimped cables tend to hold up better than those you do yourself...? I can go fairly quick once I'm on a roll but I wonder if this is the right way to go here. From brandon at rd.bbc.co.uk Fri Apr 17 19:56:18 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 17 Apr 2015 20:56:18 +0100 (BST) Subject: rack cable length Message-ID: <201504171956.UAA14568@sunf10.rd.bbc.co.uk> > From: "Bob Evans" > You must build them if you want the professional look. No way around that > - unless you want to take up rack space with some sort of cable management > wrapping system and that becomes a pain to make future changes or replace > cables. Re lacing is as much a pain (if you want to keep it looking professional) brandon From bill at herrin.us Fri Apr 17 20:09:25 2015 From: bill at herrin.us (William Herrin) Date: Fri, 17 Apr 2015 16:09:25 -0400 Subject: rack cable length In-Reply-To: References: Message-ID: On Fri, Apr 17, 2015 at 3:17 PM, Joe McLeod wrote: > Or you build the cable to fit the span. I must be getting old. There's a "best of both worlds" version of this: buy lots of the short-length cables (1 to 6 feet) and "cut down" longer cables where the distance exceeds the short cables I can buy. I typically buy 25' cables each of which turns in to a pair of shorter cables with one manufactured and one field-terminated end. I end up with cables that are "just right" and well organized. Harder to do with power cables but still somewhat functional. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bobb.harley at gmail.com Fri Apr 17 20:14:02 2015 From: bobb.harley at gmail.com (Harley H) Date: Fri, 17 Apr 2015 16:14:02 -0400 Subject: 192.0.1.0/24? Message-ID: Does anyone know the status of this netblock? I've come across a malware sample configured to callback to an IP in that range but it does not appear to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any whois information. Thanks, Harley From tfarrell at riotgames.com Fri Apr 17 20:17:58 2015 From: tfarrell at riotgames.com (Trent Farrell) Date: Fri, 17 Apr 2015 13:17:58 -0700 Subject: 192.0.1.0/24? In-Reply-To: References: Message-ID: Jump the slightest bit ahead in the library: https://tools.ietf.org/html/rfc5737 On Fri, Apr 17, 2015 at 1:14 PM, Harley H wrote: > Does anyone know the status of this netblock? I've come across a malware > sample configured to callback to an IP in that range but it does not appear > to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any > whois information. > > Thanks, > Harley > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro From josh at imaginenetworksllc.com Fri Apr 17 20:18:38 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 17 Apr 2015 16:18:38 -0400 Subject: 192.0.1.0/24? In-Reply-To: References: Message-ID: No one? http://whois.arin.net/rest/net/NET-192-0-0-0-0/pft http://www.dslreports.com/forum/r28692406-Outgoing-traffic-to-192.0.1.0-port-1000- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Apr 17, 2015 at 4:14 PM, Harley H wrote: > Does anyone know the status of this netblock? I've come across a malware > sample configured to callback to an IP in that range but it does not appear > to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any > whois information. > > Thanks, > Harley > From bobb.harley at gmail.com Fri Apr 17 20:26:42 2015 From: bobb.harley at gmail.com (Harley H) Date: Fri, 17 Apr 2015 16:26:42 -0400 Subject: 192.0.1.0/24? In-Reply-To: References: Message-ID: It is mentioned in RFC 1166 as "BBN-TEST-C". I suppose it's still not publicly allocated. On Fri, Apr 17, 2015 at 4:18 PM, Josh Luthman wrote: > No one? > > http://whois.arin.net/rest/net/NET-192-0-0-0-0/pft > > > http://www.dslreports.com/forum/r28692406-Outgoing-traffic-to-192.0.1.0-port-1000- > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Fri, Apr 17, 2015 at 4:14 PM, Harley H wrote: > >> Does anyone know the status of this netblock? I've come across a malware >> sample configured to callback to an IP in that range but it does not >> appear >> to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any >> whois information. >> >> Thanks, >> Harley >> > > From bmanning at karoshi.com Fri Apr 17 20:45:11 2015 From: bmanning at karoshi.com (manning) Date: Fri, 17 Apr 2015 13:45:11 -0700 Subject: 192.0.1.0/24? In-Reply-To: References: Message-ID: nothing that is authoritative (anymore)… 1996-2000 last century, 192.0.0.0/24 and 192.0.1.0/24 were identified as usable address blocks, post-CIDR testing/evaluation. they were both earmarked for use in the (then) four new root servers (which became J, K, L, and M)… they were then supposed to be used as the blocks for the root zone distribution masters. ICANN emerged and claimed them for itself, at one point using them for internal ICANN networking. I lost interest/control at that point and don;t know what happened after that. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 17April2015Friday, at 13:26, Harley H wrote: > It is mentioned in RFC 1166 as "BBN-TEST-C". I suppose it's still not > publicly allocated. > > On Fri, Apr 17, 2015 at 4:18 PM, Josh Luthman > wrote: > >> No one? >> >> http://whois.arin.net/rest/net/NET-192-0-0-0-0/pft >> >> >> http://www.dslreports.com/forum/r28692406-Outgoing-traffic-to-192.0.1.0-port-1000- >> >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> On Fri, Apr 17, 2015 at 4:14 PM, Harley H wrote: >> >>> Does anyone know the status of this netblock? I've come across a malware >>> sample configured to callback to an IP in that range but it does not >>> appear >>> to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any >>> whois information. >>> >>> Thanks, >>> Harley >>> >> >> From mdavids at forfun.net Fri Apr 17 21:08:24 2015 From: mdavids at forfun.net (Marco Davids) Date: Fri, 17 Apr 2015 23:08:24 +0200 Subject: 192.0.1.0/24? In-Reply-To: References: Message-ID: <55317648.30703@forfun.net> Wasn't (part) of this space assigned to RFC6333? Carrier Grade NAT and stuff... https://tools.ietf.org/html/rfc6333 ? -- Marco manning schreef op 17-04-15 om 22:45: > nothing that is authoritative (anymore)… 1996-2000 > > last century, 192.0.0.0/24 and 192.0.1.0/24 were identified as usable address blocks, post-CIDR testing/evaluation. > they were both earmarked for use in the (then) four new root servers (which became J, K, L, and M)… they were > then supposed to be used as the blocks for the root zone distribution masters. > > ICANN emerged and claimed them for itself, at one point using them for internal ICANN networking. > I lost interest/control at that point and don;t know what happened after that. > > > manning > bmanning at karoshi.com > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > > > On 17April2015Friday, at 13:26, Harley H wrote: > >> It is mentioned in RFC 1166 as "BBN-TEST-C". I suppose it's still not >> publicly allocated. >> >> On Fri, Apr 17, 2015 at 4:18 PM, Josh Luthman >> wrote: >> >>> No one? >>> >>> http://whois.arin.net/rest/net/NET-192-0-0-0-0/pft >>> >>> >>> http://www.dslreports.com/forum/r28692406-Outgoing-traffic-to-192.0.1.0-port-1000- >>> >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> >>> On Fri, Apr 17, 2015 at 4:14 PM, Harley H wrote: >>> >>>> Does anyone know the status of this netblock? I've come across a malware >>>> sample configured to callback to an IP in that range but it does not >>>> appear >>>> to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any >>>> whois information. >>>> >>>> Thanks, >>>> Harley >>>> >>> >>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4219 bytes Desc: S/MIME-cryptografische ondertekening URL: From mdavids at forfun.net Fri Apr 17 21:13:11 2015 From: mdavids at forfun.net (Marco Davids) Date: Fri, 17 Apr 2015 23:13:11 +0200 Subject: 192.0.1.0/24? In-Reply-To: <55317648.30703@forfun.net> References: <55317648.30703@forfun.net> Message-ID: <55317767.4040207@forfun.net> Marco Davids schreef op 17-04-15 om 23:08: > https://tools.ietf.org/html/rfc6333 ? Oh wait, that's 192.0.0.0/29, not 192.0.1.0/24... -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4219 bytes Desc: S/MIME-cryptografische ondertekening URL: From cidr-report at potaroo.net Fri Apr 17 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Apr 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201504172200.t3HM00Gd091056@wattle.apnic.net> This report has been generated at Fri Apr 17 21:14:32 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-04-15 546760 299609 11-04-15 546327 299928 12-04-15 546408 300189 13-04-15 546569 300375 14-04-15 546665 301485 15-04-15 547387 301191 16-04-15 547407 301800 17-04-15 547852 301699 AS Summary 50306 Number of ASes in routing system 20075 Number of ASes announcing only one prefix 3203 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120958464 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 17Apr15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 547968 300437 247531 45.2% All ASes AS22773 3018 172 2846 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2841 68 2773 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2792 78 2714 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 21 2452 99.2% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2337 289 2048 87.6% NET Servi�os de Comunica��o S.A.,BR AS4755 2002 267 1735 86.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2920 1338 1582 54.2% KIXS-AS-KR Korea Telecom,KR AS6983 1753 248 1505 85.9% ITCDELTA - Earthlink, Inc.,US AS9808 1570 67 1503 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS7303 1694 288 1406 83.0% Telecom Argentina S.A.,AR AS20115 1876 494 1382 73.7% CHARTER-NET-HKY-NC - Charter Communications,US AS10620 3203 1837 1366 42.6% Telmex Colombia S.A.,CO AS6147 1625 266 1359 83.6% Telefonica del Peru S.A.A.,PE AS7545 2602 1286 1316 50.6% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1623 409 1214 74.8% TWTC - tw telecom holdings, inc.,US AS9498 1320 109 1211 91.7% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2038 868 1170 57.4% MEGAPATH5-US - MegaPath Corporation,US AS7552 1145 56 1089 95.1% VIETEL-AS-AP Viettel Corporation,VN AS22561 1341 253 1088 81.1% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS8402 1109 24 1085 97.8% CORBINA-AS OJSC "Vimpelcom",RU AS3356 2564 1495 1069 41.7% LEVEL3 - Level 3 Communications, Inc.,US AS6849 1209 209 1000 82.7% UKRTELNET JSC UKRTELECOM,UA AS8151 1594 636 958 60.1% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS8452 1875 993 882 47.0% TE-AS TE-AS,EG AS38285 984 115 869 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 866 24 842 97.2% Global Village Telecom,BR AS4538 1778 957 821 46.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 982 164 818 83.3% Tim Celular S.A.,BR AS4780 1086 300 786 72.4% SEEDNET Digital United Inc.,TW Total 55219 13414 41805 75.7% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.116.0/22 AS54632 -Reserved AS-,ZZ 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.96.0/21 AS54632 -Reserved AS-,ZZ 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.114.136.0/22 AS33866 -Reserved AS-,ZZ 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.174.216.0/22 AS30479 NCSERV-COM - NCServ, LLC.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.83.88.0/22 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.90.0/23 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.91.0/24 AS12910 -Reserved AS-,ZZ 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 17 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Apr 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201504172200.t3HM01w6091074@wattle.apnic.net> BGP Update Report Interval: 09-Apr-15 -to- 16-Apr-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 291648 6.3% 2430.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS61894 215904 4.6% 71968.0 -- FreeBSD Brasil LTDA,BR 3 - AS9829 194409 4.2% 118.0 -- BSNL-NIB National Internet Backbone,IN 4 - AS22059 97428 2.1% 16238.0 -- APVIO-1 - Apvio, Inc.,US 5 - AS46230 86863 1.9% 3102.2 -- DUDROP - Dignitas Technology Inc,US 6 - AS36947 86280 1.9% 750.3 -- ALGTEL-AS,DZ 7 - AS3709 72128 1.6% 2671.4 -- NET-CITY-SA - City of San Antonio,US 8 - AS21669 66710 1.4% 66710.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 9 - AS28573 47228 1.0% 15.7 -- NET Servi�os de Comunica��o S.A.,BR 10 - AS48159 41585 0.9% 118.1 -- TIC-AS Telecommunication Infrastructure Company,IR 11 - AS25563 34340 0.7% 11446.7 -- WEBLAND-AS Webland AG, Autonomous System,CH 12 - AS8402 29491 0.6% 56.8 -- CORBINA-AS OJSC "Vimpelcom",RU 13 - AS4755 27982 0.6% 14.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 14 - AS33529 24599 0.5% 984.0 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 15 - AS28661 24411 0.5% 387.5 -- HOTLINK INTERNET LTDA,BR 16 - AS38197 24034 0.5% 44.3 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 17 - AS45671 20851 0.5% 251.2 -- SAU-NET-AU Servers Australia Pty Ltd,AU 18 - AS42081 18198 0.4% 4549.5 -- SPEEDY-NET-AS Speedy net EAD,BG 19 - AS9583 18183 0.4% 13.8 -- SIFY-AS-IN Sify Limited,IN 20 - AS24197 17350 0.4% 327.4 -- BIGNET-AS-ID Elka Prakarsa Utama, PT,ID TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 215904 4.6% 71968.0 -- FreeBSD Brasil LTDA,BR 2 - AS21669 66710 1.4% 66710.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 3 - AS22059 97428 2.1% 16238.0 -- APVIO-1 - Apvio, Inc.,US 4 - AS197914 15599 0.3% 15599.0 -- STOCKHO-AS Stockho Hosting SARL,FR 5 - AS18135 15521 0.3% 15521.0 -- BTV BTV Cable television,JP 6 - AS25563 34340 0.7% 11446.7 -- WEBLAND-AS Webland AG, Autonomous System,CH 7 - AS393588 9567 0.2% 9567.0 -- MUBEA-FLO - Mubea,US 8 - AS46336 8522 0.2% 8522.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 9 - AS33356 13327 0.3% 6663.5 -- CTWS - Eagle-Tech Systems,US 10 - AS42081 18198 0.4% 4549.5 -- SPEEDY-NET-AS Speedy net EAD,BG 11 - AS13483 11041 0.2% 3680.3 -- INFOR-AS13483 - INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,US 12 - AS20386 3224 0.1% 3224.0 -- MOVE-VAN - Move Sales, Inc.,US 13 - AS46230 86863 1.9% 3102.2 -- DUDROP - Dignitas Technology Inc,US 14 - AS46358 6201 0.1% 3100.5 -- UAT - University of Advancing Technology,US 15 - AS3709 72128 1.6% 2671.4 -- NET-CITY-SA - City of San Antonio,US 16 - AS23752 291648 6.3% 2430.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 17 - AS31863 11932 0.3% 2386.4 -- DACEN-2 - Centrilogic, Inc.,US 18 - AS58904 6993 0.1% 2331.0 -- KOONK-AS-IN KOONK TECHNOLOGIES PRIVATE LIMITED,IN 19 - AS202118 2031 0.0% 2031.0 -- GO-HOSTING Go Hosting S.P.R.L.,BE 20 - AS59846 1872 0.0% 1872.0 -- FGC-AS FGC UES JSC,RU TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 215875 4.5% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 146390 3.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 144363 3.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 105.96.0.0/22 84267 1.8% AS36947 -- ALGTEL-AS,DZ 5 - 209.212.8.0/24 66710 1.4% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 6 - 64.34.125.0/24 48819 1.0% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 76.191.107.0/24 48605 1.0% AS22059 -- APVIO-1 - Apvio, Inc.,US 8 - 69.194.4.0/24 24504 0.5% AS33529 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 9 - 130.0.192.0/21 15599 0.3% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 10 - 42.83.48.0/20 15521 0.3% AS18135 -- BTV BTV Cable television,JP 11 - 67.59.81.0/24 13321 0.3% AS33356 -- CTWS - Eagle-Tech Systems,US 12 - 92.43.216.0/21 11656 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 13 - 91.193.202.0/24 11603 0.2% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 14 - 185.84.192.0/22 11483 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - 178.174.96.0/19 11201 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 16 - 192.58.232.0/24 9662 0.2% AS6629 -- NOAA-AS - NOAA,US 17 - 66.19.194.0/24 9583 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 18 - 192.58.137.0/24 9567 0.2% AS393588 -- MUBEA-FLO - Mubea,US 19 - 88.87.160.0/19 9034 0.2% AS47680 -- NHCS EOBO Limited,IE 20 - 50.200.112.0/24 8522 0.2% AS46336 -- GOODVILLE - Goodville Mutual Casualty Company,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From blair.trosper at gmail.com Fri Apr 17 22:08:16 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Fri, 17 Apr 2015 17:08:16 -0500 Subject: AWS Contact Message-ID: Weird issues with console and various service...can someone contact me off list? From cra at WPI.EDU Fri Apr 17 22:19:03 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 17 Apr 2015 18:19:03 -0400 Subject: 192.0.1.0/24? In-Reply-To: <55317767.4040207@forfun.net> References: <55317648.30703@forfun.net> <55317767.4040207@forfun.net> Message-ID: <20150417221903.GC12833@angus.ind.WPI.EDU> On Fri, Apr 17, 2015 at 11:13:11PM +0200, Marco Davids wrote: > Marco Davids schreef op 17-04-15 om 23:08: > > > https://tools.ietf.org/html/rfc6333 ? > > Oh wait, that's 192.0.0.0/29, not 192.0.1.0/24... 192.0.1.0/24 sounds vaguely like something really old HP JetDirects used as a "default IP" when they weren't configured yet, or when BOOTP failed. Or maybe it was 192.0.0.192: http://www.sprint.net.au/~terbut/usefulbox/hpjetdirectexplus.htm From dougb at dougbarton.us Fri Apr 17 23:52:28 2015 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 17 Apr 2015 16:52:28 -0700 Subject: 192.0.1.0/24? In-Reply-To: References: Message-ID: <55319CBC.6060205@dougbarton.us> Harley is correct that 192.0.1/24 is mentioned in 1166, but AFAICS after cursory examination it has fallen through the cracks since then. (Note, this is not the same as 192.0.2/24, which has been updated in several RFCs recently, including 6303 by Mark Andrews (cc'ed for his information). I've also cc'ed Leo and Michelle from ICANN so that hopefully they can see about getting some whois info set up for that network. Michelle, let me know if it would be easier for you if I opened a ticket for this request. Doug On 4/17/15 1:26 PM, Harley H wrote: > It is mentioned in RFC 1166 as "BBN-TEST-C". I suppose it's still not > publicly allocated. > >> On Fri, Apr 17, 2015 at 4:14 PM, Harley H wrote: >> >>> Does anyone know the status of this netblock? I've come across a malware >>> sample configured to callback to an IP in that range but it does not >>> appear >>> to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any >>> whois information. >>> >>> Thanks, >>> Harley -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mdavids at forfun.net Fri Apr 17 23:54:50 2015 From: mdavids at forfun.net (Marco Davids) Date: Sat, 18 Apr 2015 01:54:50 +0200 Subject: 192.0.1.0/24? In-Reply-To: <55319CBC.6060205@dougbarton.us> References: <55319CBC.6060205@dougbarton.us> Message-ID: <55319D4A.8010908@forfun.net> Doug Barton schreef op 18-04-15 om 01:52: > Harley is correct that 192.0.1/24 is mentioned in 1166, but AFAICS after > cursory examination it has fallen through the cracks since then. It has been seen in the wild a few times though (for whatever reason...) https://stat.ripe.net/192.0.1.0%2F24#tabId=routing -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4219 bytes Desc: S/MIME-cryptografische ondertekening URL: From mark.tinka at seacom.mu Sat Apr 18 04:58:47 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 18 Apr 2015 06:58:47 +0200 Subject: Peering and Network Cost In-Reply-To: <55310511.5060308@netassist.ua> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> Message-ID: <5531E487.8050001@seacom.mu> On 17/Apr/15 15:05, Max Tulyev wrote: > One more interesting thing. > > If you buy IP transit, mostly you are paying by exact bandwidth, per > megabit. If you buy IX peering port, you are paying for port. This means > Tranist ports are overloaded or close to it, while IX ports usually > always have some extra free capacity. > > In practice, this mean if your customer download some file using IX way, > speed will be much higher that same file reachable by IP transit. This depends entirely on how you run your network. If you run links hot, you can't guarantee anything (keeping in mind that your less congested exchange point ports does not mean other exchange point members are in the same position also). We, for example, buy transit or peer with a minimum of 10Gbps port, with the ability to push traffic at line rate if needed. We do not allow ports to run hot (typically upgrading them anywhere from between 50% - 70% utilization). I appreciate that not everyone can be in this position, while others can be even more aggressive with their "over-engineering", but this kind of information is hard to quantify reliably. There is also backhaul from the interconnect point into the backbone to think about, but that follows a similar strategy. Mark. From r.engehausen at gmail.com Sat Apr 18 16:01:26 2015 From: r.engehausen at gmail.com (Roy) Date: Sat, 18 Apr 2015 09:01:26 -0700 Subject: Historical records of POCs Message-ID: <55327FD6.9070306@gmail.com> Is there an archive of POCs for some of the early netblocks (1985 or so)? We are trying to figure out some corporate history. From ag4ve.us at gmail.com Sat Apr 18 17:04:11 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 18 Apr 2015 13:04:11 -0400 Subject: Historical records of POCs In-Reply-To: <55327FD6.9070306@gmail.com> References: <55327FD6.9070306@gmail.com> Message-ID: Asked archive.org? On Apr 18, 2015 12:03 PM, "Roy" wrote: > > Is there an archive of POCs for some of the early netblocks (1985 or so)? > We are trying to figure out some corporate history. > From sean at donelan.com Sun Apr 19 00:09:32 2015 From: sean at donelan.com (Sean Donelan) Date: Sat, 18 Apr 2015 20:09:32 -0400 (EDT) Subject: Historical records of POCs In-Reply-To: <55327FD6.9070306@gmail.com> References: <55327FD6.9070306@gmail.com> Message-ID: ARIN has the early archives from its predecessors, i.e SRI-NIC. I think some documents may still be paper, so there may be some gaps. Contact hostmaster at arin.net registration services, and provide as much detail as possible so they can check their archives. You can also check the RFCs "Assigned Numbers" (various numbers) for early network assignments made directly by IANA. On Sat, 18 Apr 2015, Roy wrote: > Is there an archive of POCs for some of the early netblocks (1985 or so)? We > are trying to figure out some corporate history. > From owen at delong.com Sun Apr 19 02:30:36 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Apr 2015 19:30:36 -0700 Subject: Historical records of POCs In-Reply-To: References: <55327FD6.9070306@gmail.com> Message-ID: Also there is the ARIN whowas service. Requires jumping through some additional hoops, but at least it is available. Owen > On Apr 18, 2015, at 17:09 , Sean Donelan wrote: > > > ARIN has the early archives from its predecessors, i.e SRI-NIC. I think some documents may still be paper, so there may be some gaps. > > Contact hostmaster at arin.net registration services, and provide as > much detail as possible so they can check their archives. > > You can also check the RFCs "Assigned Numbers" (various numbers) for early network assignments made directly by IANA. > > > On Sat, 18 Apr 2015, Roy wrote: >> Is there an archive of POCs for some of the early netblocks (1985 or so)? We are trying to figure out some corporate history. >> From baldur.norddahl at gmail.com Sun Apr 19 09:23:53 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 19 Apr 2015 11:23:53 +0200 Subject: Peering and Network Cost In-Reply-To: <5531E487.8050001@seacom.mu> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> Message-ID: So why is IX peering so expensive? Again if I look at my local IX (dix.dk) they have about 40 networks connected. Each network pays minimum 5800 USD a year. That gives them a budget of 240000+ USD a year. But the only service is running an old layer 2 switch. Why do these guys deserve to be paid that much for so little? Recently we had a competitor show up in the form of Netnod. However the pricing is almost exactly the same, although Netnod tries to deliver slightly more service. Seems to me that this an unsound market. The 40 dix particants should donate 1000 USD once and get a new layer 2 switch. Why does that not happen? Does not look like it is a local phenomenon either. IX'es all over are way more expensive than they should be. Regards Baldur From wwaites at tardis.ed.ac.uk Sun Apr 19 10:09:09 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sun, 19 Apr 2015 11:09:09 +0100 (BST) Subject: Peering and Network Cost In-Reply-To: References: <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> Message-ID: <20150419.110909.1471902622528808090.wwaites@tardis.ed.ac.uk> On Sun, 19 Apr 2015 11:23:53 +0200, Baldur Norddahl said: > So why is IX peering so expensive? > But the only service is running an old layer 2 switch. > The 40 dix particants should donate 1000 USD once and get a new > layer 2 switch. Why does that not happen? This is something like how TORIX was operated at the beginning. The switch was donated by Cisco and rack space by a member with a cage at a convenient spot at 151 Front -- I think this was jlixfeld at look.ca. Fees were a $1/port/year peppercorn. It has been a long time since I was in any way involved in that, but today for a 1Gbps port TORIX charges $1200/year which is more but still not as much as you say for other IXPs. It would be interesting to hear from someone who was involved in TORIX at the time how this transition from $1 to $1200 went and the reasoning behind it. My guess would be moving to its own space and having to pay rent was a major part of it, and possibly acquiring staff? Also note that the LINX exchanges do not charge for the first 1Gbps port (or the n-th at the regional exchanges) though there is a membership fee which makes it roughly equivalent to what TORIX does today. >From that point of view you guys in Denmark seem to be paying somewhat over the odds. Cheers, -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh http://www.hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From nanog at ics-il.net Sun Apr 19 12:49:20 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 19 Apr 2015 07:49:20 -0500 (CDT) Subject: Peering and Network Cost In-Reply-To: Message-ID: <23627332.1847.1429447739493.JavaMail.mhammett@ThunderFuck> There is a revenue floor where it doesn't matter how much or how little service is provided, simply having a customer period requires a certain amount of revenue. Route servers, IXP Manager, AS112, route collectors, DNS, etc. all cost money. Maintenance costs money. The organization itself costs money. Upgrades cost money. Racks cost money. Power costs money. I'm sure I've left some things out. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Sunday, April 19, 2015 4:23:53 AM Subject: Re: Peering and Network Cost So why is IX peering so expensive? Again if I look at my local IX (dix.dk) they have about 40 networks connected. Each network pays minimum 5800 USD a year. That gives them a budget of 240000+ USD a year. But the only service is running an old layer 2 switch. Why do these guys deserve to be paid that much for so little? Recently we had a competitor show up in the form of Netnod. However the pricing is almost exactly the same, although Netnod tries to deliver slightly more service. Seems to me that this an unsound market. The 40 dix particants should donate 1000 USD once and get a new layer 2 switch. Why does that not happen? Does not look like it is a local phenomenon either. IX'es all over are way more expensive than they should be. Regards Baldur From jayhanke at gmail.com Sun Apr 19 14:00:30 2015 From: jayhanke at gmail.com (Jay Hanke) Date: Sun, 19 Apr 2015 09:00:30 -0500 Subject: Peering and Network Cost In-Reply-To: <23627332.1847.1429447739493.JavaMail.mhammett@ThunderFuck> References: <23627332.1847.1429447739493.JavaMail.mhammett@ThunderFuck> Message-ID: Getting networks to connect to an ix is Uber expensive in relation to the overall costs. Specifically before critical mass is reached. Getting the first X gig of traffic is a hard problem that takes money to fix. On Apr 19, 2015 7:51 AM, "Mike Hammett" wrote: > There is a revenue floor where it doesn't matter how much or how little > service is provided, simply having a customer period requires a certain > amount of revenue. > > Route servers, IXP Manager, AS112, route collectors, DNS, etc. all cost > money. > > Maintenance costs money. The organization itself costs money. Upgrades > cost money. Racks cost money. Power costs money. > > I'm sure I've left some things out. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Baldur Norddahl" > To: nanog at nanog.org > Sent: Sunday, April 19, 2015 4:23:53 AM > Subject: Re: Peering and Network Cost > > So why is IX peering so expensive? > > Again if I look at my local IX (dix.dk) they have about 40 networks > connected. Each network pays minimum 5800 USD a year. That gives them a > budget of 240000+ USD a year. > > But the only service is running an old layer 2 switch. > > Why do these guys deserve to be paid that much for so little? > > Recently we had a competitor show up in the form of Netnod. However the > pricing is almost exactly the same, although Netnod tries to deliver > slightly more service. > > Seems to me that this an unsound market. The 40 dix particants should > donate 1000 USD once and get a new layer 2 switch. Why does that not > happen? > > Does not look like it is a local phenomenon either. IX'es all over are way > more expensive than they should be. > > Regards > > Baldur > > From colin.bodor at imperium.ca Sat Apr 18 17:22:48 2015 From: colin.bodor at imperium.ca (Colin Bodor) Date: Sat, 18 Apr 2015 17:22:48 +0000 Subject: Historical records of POCs In-Reply-To: References: <55327FD6.9070306@gmail.com> Message-ID: Maybe https://arin.net/resources/whowas/index.html would work? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of shawn wilson Sent: Saturday, April 18, 2015 11:04 AM To: Roy Cc: North American Network Operators Group Subject: Re: Historical records of POCs Asked archive.org? On Apr 18, 2015 12:03 PM, "Roy" wrote: > > Is there an archive of POCs for some of the early netblocks (1985 or so)? > We are trying to figure out some corporate history. > From mark.tinka at seacom.mu Sun Apr 19 21:34:10 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 19 Apr 2015 23:34:10 +0200 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> Message-ID: <55341F52.2040005@seacom.mu> On 19/Apr/15 11:23, Baldur Norddahl wrote: > So why is IX peering so expensive? > > Again if I look at my local IX (dix.dk) they have about 40 networks > connected. Each network pays minimum 5800 USD a year. That gives them a > budget of 240000+ USD a year. > > But the only service is running an old layer 2 switch. The age of the Ethernet switch has little to do with its performance, unless it has everything to do with its performance. > > Why do these guys deserve to be paid that much for so little? The exchange point operator do not typically interfere with what the members do. That said, while it is not their job to grow your peering traffic, it would make thier exchange point more successful if they managed to grow their membership. > > Recently we had a competitor show up in the form of Netnod. However the > pricing is almost exactly the same, although Netnod tries to deliver > slightly more service. > > Seems to me that this an unsound market. The 40 dix particants should > donate 1000 USD once and get a new layer 2 switch. Why does that not happen? Unless it is the case, the old switch should not prevent growth of the exchange point, unless, of course, it currently does. > > Does not look like it is a local phenomenon either. IX'es all over are way > more expensive than they should be. Most exchange point operators have staff that run the network, find members, e.t.c. These salaries need to be paid. If a member is unable to extract the most value from their peering setup, there is very little an exchange point can do about that. In short, it's not for everyone, despite its good intentions. Mark. From merlyn at geeks.org Mon Apr 20 02:26:50 2015 From: merlyn at geeks.org (Doug McIntyre) Date: Sun, 19 Apr 2015 21:26:50 -0500 Subject: Cisco Routers Vulnerability In-Reply-To: <2e048634d4280f40836c95f1aa842903@mail.dessus.com> References: <552C3B4B.9010804@foobar.org> <2e048634d4280f40836c95f1aa842903@mail.dessus.com> Message-ID: <20150420022650.GA6028@geeks.org> On Mon, Apr 13, 2015 at 05:03:02PM -0600, Keith Medcalf wrote: > >> It's reported by different customers in different locations so I don't > >> think it's password compromised > > >Have you checked? If the routers had vty access open (ssh or telnet) and > >the passwords were easy to guess, then it's more likely that this was a > >password compromise. You can test this out by getting a copy of one of > >the configs and decrypting the access password. Or by asking your customers > >whether their passwords were dictionary or simple words. > > or if mayhaps the passwords were listed on the list of passwords discussed a few days ago: ... for some reason this brings up following memory of long ago. Had several people notify us in a short period that they all had been watching hackers try the "default cisco password" on several of our downstream customer's gear. Perked my interest when it got to me, umm, what default cisco password? Oh, the hackers were so successful getting in to tons of places that the researchers were watching the hackers connect to everywhere in addition to my downstreams with cisco/cisco that they had assumed it was the default.. (of course, this was long before Cisco shipped some piece of gear that actually did have default passwords (don't remember what any longer first started that)). From ag4ve.us at gmail.com Mon Apr 20 03:15:05 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 19 Apr 2015 23:15:05 -0400 Subject: rack cable length In-Reply-To: References: Message-ID: Ok I've got a few comments offlist too and they all seem to draw the same conclusion - crimp your own length. Thanks all for the input. On Apr 17, 2015 4:11 PM, "William Herrin" wrote: > On Fri, Apr 17, 2015 at 3:17 PM, Joe McLeod wrote: > > Or you build the cable to fit the span. I must be getting old. > > There's a "best of both worlds" version of this: buy lots of the > short-length cables (1 to 6 feet) and "cut down" longer cables where > the distance exceeds the short cables I can buy. > > I typically buy 25' cables each of which turns in to a pair of shorter > cables with one manufactured and one field-terminated end. I end up > with cables that are "just right" and well organized. > > Harder to do with power cables but still somewhat functional. > > -Bill > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From jason at lixfeld.ca Mon Apr 20 03:33:30 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Sun, 19 Apr 2015 23:33:30 -0400 Subject: Peering and Network Cost In-Reply-To: <20150419.110909.1471902622528808090.wwaites@tardis.ed.ac.uk> References: <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> <20150419.110909.1471902622528808090.wwaites@tardis.ed.ac.uk> Message-ID: <395F9B21-7060-484F-9839-62AED2F4D772@lixfeld.ca> > On Apr 19, 2015, at 6:09 AM, William Waites wrote: > > On Sun, 19 Apr 2015 11:23:53 +0200, Baldur Norddahl said: > >> So why is IX peering so expensive? > >> But the only service is running an old layer 2 switch. > >> The 40 dix particants should donate 1000 USD once and get a new >> layer 2 switch. Why does that not happen? > > This is something like how TORIX was operated at the beginning. The > switch was donated by Cisco and rack space by a member with a cage at > a convenient spot at 151 Front -- I think this was jlixfeld at > look.ca. Fees were a $1/port/year peppercorn. > > It has been a long time since I was in any way involved in that, but > today for a 1Gbps port TORIX charges $1200/year which is more but still > not as much as you say for other IXPs. It would be interesting to hear > from someone who was involved in TORIX at the time how this transition > from $1 to $1200 went and the reasoning behind it. My guess would be > moving to its own space and having to pay rent was a major part of it, > and possibly acquiring staff? To be clear, we asked for $1/port/year, but we never really bothered to pay attention to who actually paid :) Instead of addressing your questions directly, how about a brief and much abridged history of TorIX? ;) The recollection of Mr. Waites on our humble beginnings is pretty much bang-on. For the first 7 or so years, we were really ad-hoc, but we eventually decided that we needed to incorporate. That decision was simply due to the fact that we didn?t think we?d be taken very seriously by larger players (larger eyeball networks or large content networks (either nationally or internationally)) unless we moved away from an ad-hoc collection of nothing and no-one, and into an actual legal entity. Along with feedback from the participates of our little IX, those of us who made up the organizing body of this ad-hoc TorIX decided that while a legal organization was an important next step in our evolution, incorporating with non-profit status (as opposed to a full-blown commercial IX) was the most appropriate method of becoming legit. Bill Campbell (former owner Hostopia, former owner Internet Direct (later became Look)) put up 100% of the money to incorporate TorIX in early 2004. Second, up until about 2008?ish, whenever we needed gear, we?d usually have to pass the hat when we needed a GigE switch or something a little more high test than someone?s decommissioned FastE kit. The problem with passing the hat is that it rarely makes everyone happy because there?s always someone who gets left out. The cash in the hat would only give us enough to buy a 12 port switch, but inevitably, a few more than 12 participants all donated towards buying the switch. The last ones to offer up the cash had to be dropped until the next time the hat got passed around. We didn?t think asking all our participants to drop money into the hat was an appropriate course of action. Not everyone would contribute, for a multitude of reasons, but everyone would still expect the same level of service. Needless to say, it got messy. It was an inevitable part of our growth, sure. It might still be inevitable for any budding IX. After our incorporation, there were many offers from folks with skids of decommissioned 6500s, 6704s and SUP720s. These extremely generous donations made it possible for us to turn up our first 10G port, but it resulted in other challenges: who would be allowed to occupy the other three ports? Do we charge for them? We got the ports for free so HTF do we figure this one out, guys? These sorts of dilemmas would cause strife, so around 2008, the serving Board at the time decided that the next step in our evolution was to make the organization completely self-sufficient by introducing a reasonable port fee structure. Port fees could let us get space where we felt we needed it. We could buy our own gear so anyone would always be able to have any speed port they wanted. We could pay for the support contracts, hire lawyers and accountants, and also contribute to community initiatives like sponsoring the Canadian ISP Summit, NANOG and ARIN. We strive to keep our port fees low. 99% of folks never thought our port fees were too high. In fact, I can remember a few folks who laughed when we introduced port fees asking if they could pay for 5 years up front because the port fees were so cheap they were a joke. The Board introduced a reduced port fee structure across the board for 2015. Everyone[1] who contributes to TorIX still does so in a volunteer capacity; Board members, the operations group, even our book keeper :) [1]In 2014, the Board voted in favour of a motion to hire an Executive Director to further drive the growth of TorIX. In March, the Board announced that Bill Sandiford had accepted the role. In the 18 year history of TorIX, the Executive Director role is the first ever paid position at TorIX. From hank at efes.iucc.ac.il Mon Apr 20 05:02:13 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 20 Apr 2015 08:02:13 +0300 Subject: Historical records of POCs In-Reply-To: References: <55327FD6.9070306@gmail.com> Message-ID: <5.1.1.6.2.20150420075946.051d9ef8@efes.iucc.ac.il> At 17:22 18/04/2015 +0000, Colin Bodor wrote: >Maybe https://arin.net/resources/whowas/index.html would work? As per a question I asked 2 years ago and the response I received from ARIN - "I have confirmed that Whowas reports only go back to conversion in 2002 (when Org IDs were created and associated with IP resources)." Regards, Hank >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of shawn wilson >Sent: Saturday, April 18, 2015 11:04 AM >To: Roy >Cc: North American Network Operators Group >Subject: Re: Historical records of POCs > >Asked archive.orgB???\?N?MHL??03 PM, "Roy" wrote: > > > > > Is there an archive of POCs for some of the early netblocks (1985 or > so)B?vR&RG'???rF?f?wW&R?WB6??R6?'?&@e history. > > From woody at pch.net Mon Apr 20 06:32:01 2015 From: woody at pch.net (Bill Woodcock) Date: Sun, 19 Apr 2015 23:32:01 -0700 Subject: Peering and Network Cost In-Reply-To: <55341F52.2040005@seacom.mu> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> <55341F52.2040005@seacom.mu> Message-ID: > On Apr 19, 2015, at 2:34 PM, Mark Tinka wrote: > > The age of the Ethernet switch has little to do with its performance, > unless it has everything to do with its performance. Mark, you realize that this is what NANOG will make sure is engraved on your headstone, right? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mark.tinka at seacom.mu Mon Apr 20 06:36:57 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 20 Apr 2015 08:36:57 +0200 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> <55341F52.2040005@seacom.mu> Message-ID: <55349E89.4060109@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/Apr/15 08:32, Bill Woodcock wrote: > > Mark, you realize that this is what NANOG will make sure is engraved on your headstone, right? Only if I expire :-)... Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJVNJ6JAAoJEGcZuYTeKm+GvuwP/1RNI91Ef3Et5LiQ0py9NyiT 7c2PXLlIa2FBqFiJ2rczsq96uVS8FqsHm0Vklk1e1G7cNsekrGB0Xr1IIS2Be3jC +NPurzflUYQ69LnDnXN5WMzPeUgHGNWOXGySd3WVrVSGdiXS9u24tIk1uCOZM5mZ YSK9yVezpCcYaynQFKBvyrNlVibr7jFS51/sVuxMstEVsySJacp3hNQCgTFMu2YJ k36kxV9VhvKiRVcMT9sfWo59dYS+jE3m90yGhQrgLT1OOfonyuZrVMKFDV4ZqjRK T3qt5svOL+4VXnd4ZUvOG8dHXB5N/ubcYXwXrv4J6iCFFwLKKvFwr49q8DETn52v 5F7W018ebQedYqZjdUxYiDD6xbmfVecDup0hjt9LUotv9ZueTvlf3cIK/VtLmzqd CHv8BO/H7bjoEehKp5Bs2wuvY6C8C6zUoYDOSzrF367oNX9IoLAyp2EMyv0K/lT5 qH6z+hYAa8BD1tstdjSWTwq8YJYjAtA3RYISJCrLDXBQJY8DrLequisYV7sV3HPq tlLvtbeojJBb3VvhYZftH6UQ+zIdj3DVTa85tHZZs6IWbRdCMUKBHtjTnaDRJx7A FGj9xDRJR23ssDHnZ0QCHPJdYrmjFe0t0euFGfu/jxbCng8y3MI72jvkE5i2npMc ty8NRJng8qYfGem5D1lK =rkAw -----END PGP SIGNATURE----- From randy at iij.ad.jp Mon Apr 20 06:51:41 2015 From: randy at iij.ad.jp (Randy Bush) Date: Mon, 20 Apr 2015 15:51:41 +0900 Subject: dns on fios/frontier Message-ID: anyone on fios/frontier can please run a quickie and see if you can get to http://psg.com/? have a net friend who can not from multiple hosts on their home lan and he has rebooted router. called support and they showed their sunday best "the web site is down." sigh. randy From randy at psg.com Mon Apr 20 06:54:10 2015 From: randy at psg.com (Randy Bush) Date: Mon, 20 Apr 2015 15:54:10 +0900 Subject: dns on fios/frontier Message-ID: [ reposted from subscribed address ] anyone on fios/frontier can please run a quickie and see if you can get to http://psg.com/? have a net friend who can not from multiple hosts on their home lan and he has rebooted router. called support and they showed their sunday best "the web site is down." sigh. randy From colinj at gt86car.org.uk Mon Apr 20 08:41:14 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 20 Apr 2015 09:41:14 +0100 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: <8B0049AA-0955-4644-9659-1BADB73C3119@gt86car.org.uk> works fine from uk folks Col > On 20 Apr 2015, at 07:51, Randy Bush wrote: > > anyone on fios/frontier can please run a quickie and see if you can get > to http://psg.com/? have a net friend who can not from multiple hosts > on their home lan and he has rebooted router. called support and they > showed their sunday best "the web site is down." sigh. > > randy From randy at psg.com Mon Apr 20 09:15:41 2015 From: randy at psg.com (Randy Bush) Date: Mon, 20 Apr 2015 18:15:41 +0900 Subject: dns on fios/frontier In-Reply-To: <8B0049AA-0955-4644-9659-1BADB73C3119@gt86car.org.uk> References: <8B0049AA-0955-4644-9659-1BADB73C3119@gt86car.org.uk> Message-ID: > works fine from uk folks >> anyone on fios/frontier can please run a quickie ... ^^^^^^^^^^^^^^^^^^^^^^^ darned cool that you have frontier fios in the uk. glad frontier's local uk caches resolve. sigh randy From dave-nanog at pooserville.com Mon Apr 20 12:21:22 2015 From: dave-nanog at pooserville.com (Dave Pooser) Date: Mon, 20 Apr 2015 07:21:22 -0500 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: On 4/20/15, 1:54 AM, "Randy Bush" wrote: >[ reposted from subscribed address ] > >anyone on fios/frontier can please run a quickie and see if you can get >to http://psg.com/? Works fine from FIOS in Dallas, TX: traceroute to psg.com (147.28.0.62), 64 hops max, 52 byte packets 1 wireless_broadband_router.home (192.168.74.1) 0.955 ms 0.556 ms 0.466 ms 2 lo0-100.dllstx-vfttp-305.verizon-gni.net (108.19.21.1) 8.485 ms 6.878 ms 7.740 ms 3 t0-11-0-4.dllstx-lcr-21.verizon-gni.net (100.41.202.110) 9.509 ms 9.147 ms t0-7-4-0.dllstx-lcr-22.verizon-gni.net (130.81.218.82) 12.641 ms 4 * * * 5 0.ae2.br2.dfw13.alter.net (140.222.225.53) 11.300 ms 10.578 ms 9.156 ms 6 sl-st31-dal-.sprintlink.net (144.232.25.125) 12.739 ms 12.290 ms 12.203 ms 7 144.232.12.195 (144.232.12.195) 9.740 ms 144.232.11.207 (144.232.11.207) 13.921 ms 144.232.12.195 (144.232.12.195) 10.403 ms 8 144.232.12.138 (144.232.12.138) 27.853 ms 24.854 ms 24.937 ms 9 144.232.1.101 (144.232.1.101) 36.967 ms 35.642 ms 37.945 ms 10 144.232.10.186 (144.232.10.186) 39.913 ms 39.716 ms 39.950 ms 11 144.232.10.191 (144.232.10.191) 72.407 ms 72.032 ms 69.433 ms 12 sl-gw20-sea-11-0-0.sprintlink.net (144.232.8.60) 70.467 ms sl-gw20-sea-5-0-0.sprintlink.net (144.232.20.218) 67.034 ms 66.585 ms 13 144.232.9.62 (144.232.9.62) 69.903 ms 67.101 ms 67.374 ms 14 psg.com (147.28.0.62) 62.188 ms 64.435 ms 67.417 ms -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com From morrowc.lists at gmail.com Mon Apr 20 15:41:37 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 20 Apr 2015 11:41:37 -0400 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: On Mon, Apr 20, 2015 at 8:21 AM, Dave Pooser wrote: > On 4/20/15, 1:54 AM, "Randy Bush" wrote: > >>[ reposted from subscribed address ] >> >>anyone on fios/frontier can please run a quickie and see if you can get >>to http://psg.com/? > in the other message you make clear 'a frontier customer on the fios infrastructure'... you do mean that, not 'a frontier customer OR a verizon fios customer' right? (they don't share, necessarily, the same DNS or transit paths/equipment) From mhuff at ox.com Mon Apr 20 15:49:20 2015 From: mhuff at ox.com (Matthew Huff) Date: Mon, 20 Apr 2015 15:49:20 +0000 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: <75d4178eb0694935bf03997fe7600b13@pur-vm-exch13n1.ox.com> Well, There are frontier users and there are fios users, and now there are frontier fios users (users that were customers of Verizon, but Verizon sold off part their infrastructure to frontier). ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC?????? | Phone: 914-460-4039 aim: matthewbhuff??????? | Fax:?? 914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Morrow Sent: Monday, April 20, 2015 11:42 AM To: Dave Pooser Cc: North American Network Operators' Group Subject: Re: dns on fios/frontier On Mon, Apr 20, 2015 at 8:21 AM, Dave Pooser wrote: > On 4/20/15, 1:54 AM, "Randy Bush" wrote: > >>[ reposted from subscribed address ] >> >>anyone on fios/frontier can please run a quickie and see if you can get >>to http://psg.com/? > in the other message you make clear 'a frontier customer on the fios infrastructure'... you do mean that, not 'a frontier customer OR a verizon fios customer' right? (they don't share, necessarily, the same DNS or transit paths/equipment) From dave-nanog at pooserville.com Mon Apr 20 16:01:42 2015 From: dave-nanog at pooserville.com (Dave Pooser) Date: Mon, 20 Apr 2015 11:01:42 -0500 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: >in the other message you make clear 'a frontier customer on the fios >infrastructure'... you do mean that, not 'a frontier customer OR a >verizon fios customer' right? Ah. Obviously, that's not how I read it. ;-) But yes, I'm a bog-standard Verizon FIOS customer with no frontier connection at all. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com From Marla.Azinger at FTR.com Mon Apr 20 16:10:08 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 20 Apr 2015 16:10:08 +0000 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: Looking into this and getting it to the right crew at Frontier. Marla -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Morrow Sent: Monday, April 20, 2015 8:42 AM To: Dave Pooser Cc: North American Network Operators' Group Subject: Re: dns on fios/frontier On Mon, Apr 20, 2015 at 8:21 AM, Dave Pooser wrote: > On 4/20/15, 1:54 AM, "Randy Bush" wrote: > >>[ reposted from subscribed address ] >> >>anyone on fios/frontier can please run a quickie and see if you can >>get to http://psg.com/? > in the other message you make clear 'a frontier customer on the fios infrastructure'... you do mean that, not 'a frontier customer OR a verizon fios customer' right? (they don't share, necessarily, the same DNS or transit paths/equipment) From kemp at network-services.uoregon.edu Mon Apr 20 18:23:34 2015 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 20 Apr 2015 11:23:34 -0700 Subject: route-views.sfmix.routeviews.org is online Message-ID: <55354426.1020509@network-services.uoregon.edu> Just started on SFMIX. (We're also working on getting into PHLIX, FLIX, and CoreSite...) -- John Kemp RouteViews Engineer NOC: noc at routeviews.org MAIL: help at routeviews.org WWW: http://www.routeviews.org From randy at psg.com Mon Apr 20 18:42:46 2015 From: randy at psg.com (Randy Bush) Date: Tue, 21 Apr 2015 03:42:46 +0900 Subject: dns on fios/frontier In-Reply-To: <5534C808.507@foobar.org> References: <5534C808.507@foobar.org> Message-ID: [ excuse abnormal cluelessness even for me. overwhelmed by mucous and it is the middle of the night here ] >> anyone on fios/frontier can please run a quickie and see if you can get >> to http://psg.com/? have a net friend who can not from multiple hosts >> on their home lan and he has rebooted router. called support and they >> showed their sunday best "the web site is down." sigh. > https://atlas.ripe.net/probes/13318/ two things. so how did you find it? i was wondering if i could find a useful atlas probe or nlring node, and how to find them. secondly, i gotta snark that the ui maximizes the eurocracy to do a seemingly simple dig @probe psg.com. a and ping psg.com and it does not even serve coffee during the hour the dig and ping are "running." (quaint use of the gerund). i am not great at json, but looks to me as if it is a dns failure [{"from":"74.106.249.162","fw":4680,"group_id":1964819,"lts":163,"msm_id":1964820,"msm_name":"Tdig","prb_id":13318,"resultset":[{"af":4,"dst_addr":"10.0.0.13","lts":163,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":61959,"NSCOUNT":3,"QDCOUNT":1,"abuf":"8geBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMAAIAAQAADhAABgNyaXDADMAMABwAAQAADhAAECABBBgAAQAAAAAAAAAAAGLAYQABAAEAApzNAASTHAAnwGEAHAABAAGYeQAQIAEEGAABAAAAAAAAAAAAOQ==","rt":175.454,"size":175},"src_addr":"10.0.1.100","subid":1,"submax":3,"time":1429553733},{"af":4,"dst_addr":"38.103.8.115","lts":164,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":10350,"NSCOUNT":3,"QDCOUNT":1,"abuf":"KG6BgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAAYDcmlwwAzADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMABwAAQAADhAAECABBBgAAQAAAAAAAAAAAGLANQABAAEAAMIIAASTHAAnwDUAHAABAADCCAAQIAEEGAABAAAAAAAAAAAAOQ==","rt":370.067,"size":175},"src_addr":"10.0.1.100","subid":2,"submax":3,"time":1429553734},{"af":6,"dst_addr":"2001:550:102:301::13","lts":165,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":47682,"NSCOUNT":3,"QDCOUNT":1,"abuf":"ukKBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADg4ABJMcAD7ADAACAAEAAA4OABIEbmxucwdnbG9ibml4A25ldADADAACAAEAAA4OAAYDcmlwwAzADAACAAEAAA4OAALADMAMABwAAQAADg4AECABBBgAAQAAAAAAAAAAAGLAUwABAAEAApzLAASTHAAnwFMAHAABAAGYdwAQIAEEGAABAAAAAAAAAAAAOQ==","rt":1.345,"size":175},"src_addr":"2001:550:102:301::1001","subid":3,"submax":3,"time":1429553735}],"timestamp":1429553733,"type":"dns"}] looks pingable [{"af":4,"avg":77.5353333333,"dst_addr":"147.28.0.62","dst_name":"147.28.0.62","dup":0,"from":"74.106.249.162","fw":4680,"group_id":1964819,"lts":166,"max":78.025,"min":77.132,"msm_id":1964819,"msm_name":"Ping","prb_id":13318,"proto":"ICMP","rcvd":3,"result":[{"rtt":78.025},{"rtt":77.449},{"rtt":77.132}],"sent":3,"size":48,"src_addr":"10.0.1.100","step":240,"timestamp":1429553736,"ttl":239,"type":"ping"}] http://dnsviz.net/d/psg.com/dnssec/ thinks the dnssec glorp is fine. randy From randy at psg.com Mon Apr 20 18:44:34 2015 From: randy at psg.com (Randy Bush) Date: Tue, 21 Apr 2015 03:44:34 +0900 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: > in the other message you make clear 'a frontier customer on the fios > infrastructure'... you do mean that, not 'a frontier customer OR a > verizon fios customer' right? end user with the problem said verizon/frontier. and they are very end user. debugging with them is a joy. randy From randy at psg.com Mon Apr 20 18:47:47 2015 From: randy at psg.com (Randy Bush) Date: Tue, 21 Apr 2015 03:47:47 +0900 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: > Looking into this and getting it to the right crew at Frontier. thanks, marla. the atlas probe nick found *seemed* to be able to ping, but not resolve dns. can i claim abuse when an old geek asks for ping or dig and gets back jason web glorp? it may be restful, but not on these old eyes. :) randy From nick at foobar.org Mon Apr 20 18:48:49 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 20 Apr 2015 19:48:49 +0100 Subject: dns on fios/frontier In-Reply-To: References: <5534C808.507@foobar.org> Message-ID: <55354A11.8020302@foobar.org> On 20/04/2015 19:42, Randy Bush wrote: > [ excuse abnormal cluelessness even for me. overwhelmed by mucous and > it is the middle of the night here ] > >>> anyone on fios/frontier can please run a quickie and see if you can get >>> to http://psg.com/? have a net friend who can not from multiple hosts >>> on their home lan and he has rebooted router. called support and they >>> showed their sunday best "the web site is down." sigh. >> https://atlas.ripe.net/probes/13318/ > > two things. > > so how did you find it? erm, google: https://www.google.com/search?q=ripe+atlas+fios > i was wondering if i could find a useful atlas > probe or nlring node, and how to find them. you can specify an asn within the ripe atlas ui. > secondly, i gotta snark that the ui maximizes the eurocracy to do a > seemingly simple > dig @probe psg.com. a > and > ping psg.com > and it does not even serve coffee during the hour the dig and ping are > "running." (quaint use of the gerund). talk to the atlas people about this. It's a tool written for high flexibility, but probably compressing this into a simple UI is difficult. The JSON interface is good though. Nick From robert at ripe.net Mon Apr 20 18:57:58 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 20 Apr 2015 20:57:58 +0200 Subject: dns on fios/frontier In-Reply-To: References: <5534C808.507@foobar.org> Message-ID: <55354C36.8020007@ripe.net> >>> anyone on fios/frontier can please run a quickie and see if you can get >>> to http://psg.com/? have a net friend who can not from multiple hosts >>> on their home lan and he has rebooted router. called support and they >>> showed their sunday best "the web site is down." sigh. >> https://atlas.ripe.net/probes/13318/ > > two things. > > so how did you find it? i was wondering if i could find a useful atlas > probe or nlring node, and how to find them. https://atlas.ripe.net/docs/rest/#probe or more specifically: https://atlas.ripe.net/api/v1/probe/?tags=fios (it gives exactly one result at the moment -- the above mentioned one. It's useful if people actually tag their probes...) About Ring: we're not authoritative -- I believe http://map.ring.nlnog.net/ is. > secondly, i gotta snark that the ui maximizes the eurocracy to do a > seemingly simple > dig @probe psg.com. a > and > ping psg.com > and it does not even serve coffee during the hour the dig and ping are > "running." (quaint use of the gerund). I'd like to draw attention to the "one-off measurement" feature, which responds within 10-30 seconds or so. Indeed, it serves no coffee :-( > i am not great at json, but looks to me as if it is a dns failure > > [{"from":"74.106.249.162","fw":4680,"group_id":1964819,"lts":163,"msm_id":1964820,"msm_name":"Tdig","prb_id":13318,"resultset":[{"af":4,"dst_addr":"10.0.0.13","lts":163,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":61959,"NSCOUNT":3,"QDCOUNT":1,"abuf":"8geBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMAAIAAQAADhAABgNyaXDADMAMABwAAQAADhAAECABBBgAAQAAAAAAAAAAAGLAYQABAAEAApzNAASTHAAnwGEAHAABAAGYeQAQIAEEGAABAAAAAAAAAAAAOQ==","rt":175.454,"size":175},"src_addr":"10.0.1.100","subid":1,"submax":3,"time":1429553733},{"af":4,"dst_addr":"38.103.8.115","lts":164,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":10350,"NSCOUNT":3,"QDCOUNT":1,"abuf":"KG6BgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAAYDcmlwwAzADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMABwAAQAADhAAECABBBgAAQAAAAAAAAAAAGLANQABAAEAAMIIAASTHAAnwDUAHAABAADCCAAQIAEEGAABAAAAAAAAAAAAOQ==","rt":370.067,"size":175},"src_addr":" 1 > 0.0.1.100","subid":2,"submax":3,"time":1429553734},{"af":6,"dst_addr":"2001:550:102:301::13","lts":165,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":47682,"NSCOUNT":3,"QDCOUNT":1,"abuf":"ukKBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADg4ABJMcAD7ADAACAAEAAA4OABIEbmxucwdnbG9ibml4A25ldADADAACAAEAAA4OAAYDcmlwwAzADAACAAEAAA4OAALADMAMABwAAQAADg4AECABBBgAAQAAAAAAAAAAAGLAUwABAAEAApzLAASTHAAnwFMAHAABAAGYdwAQIAEEGAABAAAAAAAAAAAAOQ==","rt":1.345,"size":175},"src_addr":"2001:550:102:301::1001","subid":3,"submax":3,"time":1429553735}],"timestamp":1429553733,"type":"dns"}] No, it's ok, see https://atlas.ripe.net/measurements/1964820/#!map > looks pingable > > [{"af":4,"avg":77.5353333333,"dst_addr":"147.28.0.62","dst_name":"147.28.0.62","dup":0,"from":"74.106.249.162","fw":4680,"group_id":1964819,"lts":166,"max":78.025,"min":77.132,"msm_id":1964819,"msm_name":"Ping","prb_id":13318,"proto":"ICMP","rcvd":3,"result":[{"rtt":78.025},{"rtt":77.449},{"rtt":77.132}],"sent":3,"size":48,"src_addr":"10.0.1.100","step":240,"timestamp":1429553736,"ttl":239,"type":"ping"}] Yep. Cheers, Robert > http://dnsviz.net/d/psg.com/dnssec/ thinks the dnssec glorp is fine. > > randy > From job at instituut.net Mon Apr 20 19:01:25 2015 From: job at instituut.net (Job Snijders) Date: Mon, 20 Apr 2015 21:01:25 +0200 Subject: dns on fios/frontier In-Reply-To: References: <5534C808.507@foobar.org> Message-ID: <20150420190124.GI46034@Vurt.local> On Tue, Apr 21, 2015 at 03:42:46AM +0900, Randy Bush wrote: > so how did you find it? i was wondering if i could find a useful > atlas probe or nlring node, and how to find them. There are no RING nodes in any of the verizon networks :-( From job at instituut.net Mon Apr 20 19:02:32 2015 From: job at instituut.net (Job Snijders) Date: Mon, 20 Apr 2015 21:02:32 +0200 Subject: dns on fios/frontier In-Reply-To: <55354C36.8020007@ripe.net> References: <5534C808.507@foobar.org> <55354C36.8020007@ripe.net> Message-ID: <20150420190232.GJ46034@Vurt.local> On Mon, Apr 20, 2015 at 08:57:58PM +0200, Robert Kisteleki wrote: > About Ring: we're not authoritative -- I believe http://map.ring.nlnog.net/ is. I recommend our API: https://ring.nlnog.net/api/1.0/nodes From randy at psg.com Mon Apr 20 19:04:56 2015 From: randy at psg.com (Randy Bush) Date: Tue, 21 Apr 2015 04:04:56 +0900 Subject: dns on fios/frontier In-Reply-To: <55354C36.8020007@ripe.net> References: <5534C808.507@foobar.org> <55354C36.8020007@ripe.net> Message-ID: > I'd like to draw attention to the "one-off measurement" feature, which > responds within 10-30 seconds or so. i clicked that button. maybe ten mins. > Indeed, it serves no coffee :-( that is a serious issue. >> i am not great at json, but looks to me as if it is a dns failure >> >> [{"from":"74.106.249.162","fw":4680,"group_id":1964819,"lts":163,"msm_id":1964820,"msm_name":"Tdig","prb_id":13318,"resultset":[{"af":4,"dst_addr":"10.0.0.13","lts":163,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":61959,"NSCOUNT":3,"QDCOUNT":1,"abuf":"8geBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMAAIAAQAADhAABgNyaXDADMAMABwAAQAADhAAECABBBgAAQAAAAAAAAAAAGLAYQABAAEAApzNAASTHAAnwGEAHAABAAGYeQAQIAEEGAABAAAAAAAAAAAAOQ==","rt":175.454,"size":175},"src_addr":"10.0.1.100","subid":1,"submax":3,"time":1429553733},{"af":4,"dst_addr":"38.103.8.115","lts":164,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":10350,"NSCOUNT":3,"QDCOUNT":1,"abuf":"KG6BgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADhAABJMcAD7ADAACAAEAAA4QAAYDcmlwwAzADAACAAEAAA4QAALADMAMAAIAAQAADhAAEgRubG5zB2dsb2JuaXgDbmV0AMAMABwAAQAADhAAECABBBgAAQAAAAAAAAAAAGLANQABAAEAAMIIAASTHAAnwDUAHAABAADCCAAQIAEEGAABAAAAAAAAAAAAOQ==","rt":370.067,"size":175},"src_addr":" > 1 >> 0.0.1.100","subid":2,"submax":3,"time":1429553734},{"af":6,"dst_addr":"2001:550:102:301::13","lts":165,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":3,"ID":47682,"NSCOUNT":3,"QDCOUNT":1,"abuf":"ukKBgAABAAEAAwADA3BzZwNjb20AAAEAAcAMAAEAAQAADg4ABJMcAD7ADAACAAEAAA4OABIEbmxucwdnbG9ibml4A25ldADADAACAAEAAA4OAAYDcmlwwAzADAACAAEAAA4OAALADMAMABwAAQAADg4AECABBBgAAQAAAAAAAAAAAGLAUwABAAEAApzLAASTHAAnwFMAHAABAAGYdwAQIAEEGAABAAAAAAAAAAAAOQ==","rt":1.345,"size":175},"src_addr":"2001:550:102:301::1001","subid":3,"submax":3,"time":1429553735}],"timestamp":1429553733,"type":"dns"}] > > No, it's ok, see https://atlas.ripe.net/measurements/1964820/#!map in what way is it ok? that url gives me a nice map of europe. and a grep for psg.com's ipv4 or ipv6 addy in the json result fails. randy From chuckchurch at gmail.com Mon Apr 20 19:08:30 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Mon, 20 Apr 2015 15:08:30 -0400 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: <00ca01d07b9d$74fdb3d0$5ef91b70$@gmail.com> Sounds like you're talking to my dad. Tell him I said hi. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Monday, April 20, 2015 2:45 PM To: Christopher Morrow Cc: North American Network Operators' Group Subject: Re: dns on fios/frontier > in the other message you make clear 'a frontier customer on the fios > infrastructure'... you do mean that, not 'a frontier customer OR a > verizon fios customer' right? end user with the problem said verizon/frontier. and they are very end user. debugging with them is a joy. randy From morrowc.lists at gmail.com Mon Apr 20 19:32:09 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 20 Apr 2015 15:32:09 -0400 Subject: dns on fios/frontier In-Reply-To: <55354C36.8020007@ripe.net> References: <5534C808.507@foobar.org> <55354C36.8020007@ripe.net> Message-ID: On Mon, Apr 20, 2015 at 2:57 PM, Robert Kisteleki wrote: >> >> so how did you find it? i was wondering if i could find a useful atlas >> probe or nlring node, and how to find them. > > https://atlas.ripe.net/docs/rest/#probe > or more specifically: > https://atlas.ripe.net/api/v1/probe/?tags=fios (it gives exactly one result > at the moment -- the above mentioned one. It's useful if people actually tag > their probes...) hurray! now it shows 2! (I didn't realize there was a fios user tag I could add to mine :( ) there are also 8 probes shown in your just search for 'fios' in the probes list... From randy at psg.com Tue Apr 21 01:07:22 2015 From: randy at psg.com (Randy Bush) Date: Tue, 21 Apr 2015 10:07:22 +0900 Subject: dns on fios/frontier In-Reply-To: References: <5534C808.507@foobar.org> <55354C36.8020007@ripe.net> Message-ID: > hurray! now it shows 2! (I didn't realize there was a fios user tag I > could add to mine :( ) so i added th upstreams to my probe descriptions. but one, 2285, does not stick. interesting randy From maxtul at netassist.ua Tue Apr 21 09:58:16 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 21 Apr 2015 12:58:16 +0300 Subject: Peering and Network Cost In-Reply-To: References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> Message-ID: <55361F38.6010700@netassist.ua> Choose another IX to peer. Or even make your own ;) Kiev have 3 major IXes, and price is about $100 for 10GE port. On 19.04.15 12:23, Baldur Norddahl wrote: > So why is IX peering so expensive? > > Again if I look at my local IX (dix.dk) they have about 40 networks > connected. Each network pays minimum 5800 USD a year. That gives them a > budget of 240000+ USD a year. > > But the only service is running an old layer 2 switch. > > Why do these guys deserve to be paid that much for so little? > > Recently we had a competitor show up in the form of Netnod. However the > pricing is almost exactly the same, although Netnod tries to deliver > slightly more service. > > Seems to me that this an unsound market. The 40 dix particants should > donate 1000 USD once and get a new layer 2 switch. Why does that not happen? > > Does not look like it is a local phenomenon either. IX'es all over are way > more expensive than they should be. > > Regards > > Baldur > From mark.tinka at seacom.mu Tue Apr 21 10:03:08 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 21 Apr 2015 12:03:08 +0200 Subject: Peering and Network Cost In-Reply-To: <55361F38.6010700@netassist.ua> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> <55361F38.6010700@netassist.ua> Message-ID: <5536205C.7090005@seacom.mu> On 21/Apr/15 11:58, Max Tulyev wrote: > Choose another IX to peer. Or even make your own ;) > > Kiev have 3 major IXes, and price is about $100 for 10GE port. Switch port costs will be governed by how the exchange point is run. Low or no running costs will, theoretically, yield cheaper ports. Mark. From maxtul at netassist.ua Tue Apr 21 17:37:02 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 21 Apr 2015 20:37:02 +0300 Subject: Peering and Network Cost In-Reply-To: <5531E487.8050001@seacom.mu> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> Message-ID: <55368ABE.90602@netassist.ua> That's generally good idea, but average TCP session speed depends not only your side of connection, but another side as well. On 18.04.15 07:58, Mark Tinka wrote: > > > On 17/Apr/15 15:05, Max Tulyev wrote: >> One more interesting thing. >> >> If you buy IP transit, mostly you are paying by exact bandwidth, per >> megabit. If you buy IX peering port, you are paying for port. This means >> Tranist ports are overloaded or close to it, while IX ports usually >> always have some extra free capacity. >> >> In practice, this mean if your customer download some file using IX way, >> speed will be much higher that same file reachable by IP transit. > > This depends entirely on how you run your network. If you run links hot, > you can't guarantee anything (keeping in mind that your less congested > exchange point ports does not mean other exchange point members are in > the same position also). > > We, for example, buy transit or peer with a minimum of 10Gbps port, with > the ability to push traffic at line rate if needed. We do not allow > ports to run hot (typically upgrading them anywhere from between 50% - > 70% utilization). I appreciate that not everyone can be in this > position, while others can be even more aggressive with their > "over-engineering", but this kind of information is hard to quantify > reliably. > > There is also backhaul from the interconnect point into the backbone to > think about, but that follows a similar strategy. > > Mark. > > From Marla.Azinger at FTR.com Tue Apr 21 18:22:36 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Tue, 21 Apr 2015 18:22:36 +0000 Subject: dns on fios/frontier In-Reply-To: References: Message-ID: This issue has now been resolved. Cheers Marla Frontier Communications -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, April 20, 2015 11:48 AM To: Azinger, Marla Cc: North American Network Operators' Group Subject: Re: dns on fios/frontier > Looking into this and getting it to the right crew at Frontier. thanks, marla. the atlas probe nick found *seemed* to be able to ping, but not resolve dns. can i claim abuse when an old geek asks for ping or dig and gets back jason web glorp? it may be restful, but not on these old eyes. :) randy From mark.tinka at seacom.mu Tue Apr 21 19:18:31 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 21 Apr 2015 21:18:31 +0200 Subject: Peering and Network Cost In-Reply-To: <55368ABE.90602@netassist.ua> References: <1429104508516.63849@hibernianetworks.com> <552EA4F1.5010700@netassist.ua> <552EC622.8090004@Janoszka.pl> <55310511.5060308@netassist.ua> <5531E487.8050001@seacom.mu> <55368ABE.90602@netassist.ua> Message-ID: <5536A287.5080307@seacom.mu> On 21/Apr/15 19:37, Max Tulyev wrote: > That's generally good idea, but average TCP session speed depends not > only your side of connection, but another side as well. It was always best effort :-). Mark. From frnkblk at iname.com Wed Apr 22 02:52:35 2015 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 21 Apr 2015 21:52:35 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <42BC42FB-846D-456A-A4FF-DE4E69C19661@consultant.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> <20150303225705.8DE772AC8A13@rock.dv.isc.org> <000101d05890$281f28d0$785d7a70$@iname.com> <42BC42FB-846D-456A-A4FF-DE4E69C19661@consultant.com> Message-ID: <004101d07ca7$646ef3c0$2d4cdb40$@iname.com> Those are measured at the campus boundary. I don't have visibility inside the school's network to know who much intra-campus traffic there may be . but we know that peer-to-peer is a small percentage of overall Internet traffic flows, and streaming video remains the largets. Frank From: James R Cutler [mailto:james.cutler at consultant.com] Sent: Saturday, March 07, 2015 8:51 AM To: Frank Bulk Cc: NANOG Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] Frank, Are your measurements taken at the campus boundary or within the campus network? I remember the confusion when Centrex was first introduced at UMich. The statistic there that confounded was call durations wildly exceeding models, but mostly within the campus, not to the outside world. Could there be peer to peer traffic that you do not see? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu On Mar 6, 2015, at 11:35 PM, Frank Bulk > wrote: The download/upload in our residential/business eyeball network has been trending a 95th-percentile based ratio of 9:1. If I look at a higher-ed customer of ours who has symmetric service and has a young demographic the average ratio is 11:1 and the peak ratio 8.8:1. So despite access to symmetric speeds, they're not showing a distinctively heavier symmetricity. Frank From srihari at cse.sc.edu Wed Apr 22 15:51:28 2015 From: srihari at cse.sc.edu (Srihari Nelakuditi) Date: Wed, 22 Apr 2015 11:51:28 -0400 Subject: CFP: IEEE ICNP 2015 Workshop Proposals Message-ID: <5537C380.6070400@cse.sc.edu> Call for Workshop Proposals IEEE ICNP 2015 http://icnp15.cs.ucr.edu/ ICNP, the IEEE International Conference on Network Protocols, is the premier conference covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. ICNP 2015 will host multiple one-day or half-day workshops in conjunction with the main conference, to be held in San Francisco, CA on Nov 10-13, 2015. We invite you to submit workshop proposals on any topic related to the main ICNP conference. ICNP workshops should focus on creating interactions among participants as well as community building. ====================================================================== Important dates Proposal Submission May 10, 2015 Acceptance Notification May 15, 2015 ====================================================================== A workshop proposal for ICNP 2015 should contain at least the following information: * Name and possible acronym of the workshop. * Motivation and rationale for the workshop. * Draft call-for-papers, including introduction and topics of the workshop. * Names and affiliations of main organizers, and a tentative composition of the committees (as complete as possible). Please indicate whether prospective committee members have been contacted and whether they have accepted the invitation. We strongly discourage speculative TPC listings. * Workshop format, i.e., expected number of presented papers, slot lengths, information about invited talks, panels, demonstrations, etc. * Expected number of participants and expected number of submissions. * Requirements in terms of A/V, networking, power, facilities. (Assume that nothing is provided other than a projector and a microphone.) * Prior history of this workshop, if any, including number of submissions, number of accepted papers, and attendee count of previous instances. If the workshop was co-located with another event in the past, please include details and a brief description why ICNP is a more appropriate venue. Please note that the camera-ready processing of conference papers, tentatively set as Aug 15, 2015, must be met by all workshops as well. Also, all workshops need to start, end, and have break times at the same time as the main conference. The paper lengths are limited to six pages in IEEE Computer Society format. All the accepted papers need to be presented at the workshop. They will be included in the workshop proceedings as well as IEEE Xplore. Please submit your workshop proposals by email to by May 10, 2015. We will get back to you with the acceptance by May 15, 2015. Workshop Chairs: Krishna Kant, Temple University Guoliang Xue, Arizona State University ====================================================================== From rodrigo at 1telecom.com.br Wed Apr 22 18:15:45 2015 From: rodrigo at 1telecom.com.br (Rodrigo Augusto) Date: Wed, 22 Apr 2015 15:15:45 -0300 Subject: DWDM and EDFA and DCM Message-ID: Does anyone have some experience to use dwdm monofiber mux/demux ( ex. fiberstore ) about 68km using a ADFA ? Have I to use a DCM( for chromatic dispersion ) on this distance? When I have to use a DCM ? Rodrigo Augusto Gestor de T.I. Grupo Connectoway http://www.connectoway.com.br http://www.1telecom.com.br * rodrigo at connectoway.com.br ( (81) 3497-6060 ( (81) 8184-3646 ( INOC-DBA 52965*100 From swmike at swm.pp.se Wed Apr 22 18:33:49 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 22 Apr 2015 20:33:49 +0200 (CEST) Subject: DWDM and EDFA and DCM In-Reply-To: References: Message-ID: On Wed, 22 Apr 2015, Rodrigo Augusto wrote: > Does anyone have some experience to use dwdm monofiber mux/demux ( ex. > fiberstore ) about 68km using a ADFA ? Have I to use a DCM( for chromatic > dispersion ) on this distance? When I have to use a DCM ? You have to use DCM when the chromatic dispersion caused by your distance exceeds what your receiver optical module can handle. So the answer is "it depends". If you're using 1GBASE-DWDM optics then you'll be fine, if you use 10GBASE DWDM optics then it depends on the distance they were designed to handle, if you buy the 40km ones then you should have DCM. -- Mikael Abrahamsson email: swmike at swm.pp.se From rodrigo at 1telecom.com.br Wed Apr 22 19:01:39 2015 From: rodrigo at 1telecom.com.br (Rodrigo Augusto) Date: Wed, 22 Apr 2015 16:01:39 -0300 Subject: DWDM and EDFA and DCM In-Reply-To: Message-ID: Buy 80km sfp+ dwdm modules? c21 and c51. On this scenario a don?t have a EDFA, only put these sfp+ and I have link on other side( 60km) but I have a -19dbm and other side I have -21dbm( ddm sfp+ output).. I think I have a better signal than this? because I use 80km sfp+ and my distance is 60km? can I have a chromatic dispersion? I think to use a EDFA, but i?m not sure this? if I have a chromatic dispersion I have to use a DCM not a ADFA or a booster? Right?! Rodrigo Augusto Gestor de T.I. Grupo Connectoway http://www.connectoway.com.br http://www.1telecom.com.br * rodrigo at connectoway.com.br ( (81) 3497-6060 ( (81) 8184-3646 ( INOC-DBA 52965*100 On 22/04/15 15:33, "Mikael Abrahamsson" wrote: >On Wed, 22 Apr 2015, Rodrigo Augusto wrote: > >> Does anyone have some experience to use dwdm monofiber mux/demux ( ex. >> fiberstore ) about 68km using a ADFA ? Have I to use a DCM( for >>chromatic >> dispersion ) on this distance? When I have to use a DCM ? > >You have to use DCM when the chromatic dispersion caused by your distance >exceeds what your receiver optical module can handle. > >So the answer is "it depends". If you're using 1GBASE-DWDM optics then >you'll be fine, if you use 10GBASE DWDM optics then it depends on the >distance they were designed to handle, if you buy the 40km ones then you >should have DCM. > >-- >Mikael Abrahamsson email: swmike at swm.pp.se From baldur.norddahl at gmail.com Wed Apr 22 20:51:29 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 22 Apr 2015 22:51:29 +0200 Subject: DWDM and EDFA and DCM In-Reply-To: References: Message-ID: First: buy a power meter. They are really cheap and the only way to know for sure how much signal you got. It will also tell you how much launch power you have. The fiberstore modules are listed as 0 to +5 dBm launch power - if you got lucky it might be +5 and if you got a lower end module it might be close to 0. Obviously this makes a huge difference for how much power you get on the other end. Also it is said that the laser will lose power over time. Second you need to think in terms of power budget, not distance. So you got 68 km and the module is rated for 80 km - but not all fiber is not born equal. A power meter allows you to measure the true link loss. Third you did not tell what DWDM multiplexer you are using. A 44 channel DWDM multiplexer from Fiberstore can have up to 4.5 dB insertion loss. You might have two of those on your link for a total of 9 dB loss. Your 80 km module has a 23 dB link budget, so this leaves you with 23-9 = 14 dB budget. If your fiber has 0.25 dB loss per km, that is only 56 km. Regards, Baldur From daniel.karrenberg at ripe.net Wed Apr 22 21:11:55 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 22 Apr 2015 23:11:55 +0200 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> Message-ID: <55380E9B.7080908@ripe.net> On 17.04.15 3:49 , Randy Bush wrote: >> in any case the idea still seems silly. > > not if you need to appear to be DOING SOMETHING!!! > > Of course there is that. But in order to be appear to be doing something one has to pledge to do BCP38 and various other things I would consider BCP. All little bits help. Daniel (no affiliation with this particular initiative) From jra at baylink.com Wed Apr 22 22:02:22 2015 From: jra at baylink.com (Jay Ashworth) Date: Wed, 22 Apr 2015 18:02:22 -0400 (EDT) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <004101d07ca7$646ef3c0$2d4cdb40$@iname.com> Message-ID: <14332523.16.1429740142344.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Frank Bulk" > Those are measured at the campus boundary. I don't have visibility inside > the school's network to know who much intra-campus traffic there may be . > but we know that peer-to-peer is a small percentage of overall Internet > traffic flows, and streaming video remains the largets. BitTorrent makes special efforts to keep as much traffic local as possible, I understand; that probably isn't too helpful... except at scales like that on a resnet at a sizable campus. 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 rodrigo at 1telecom.com.br Wed Apr 22 22:43:22 2015 From: rodrigo at 1telecom.com.br (Rodrigo 1telecom) Date: Wed, 22 Apr 2015 19:43:22 -0300 Subject: DWDM and EDFA and DCM In-Reply-To: References: Message-ID: <79610D4A-FC2F-44F0-9AB1-8ED66E1DD89D@1telecom.com.br> Nothing is wrong with the fiber... Attenuation is good... Gbics specs says -23db as a limit of your sensibility ...i have tried to put bidi sfp+ 80km on this fiber and have -25dbi on other side( not connect) this module have -20dbi sensibility ... This scenario have a 4 channels... And i use 2 10gb channels... C21 and c22 on side A and c51 and c52 on side B.... Enviado via iPhone ? Grupo Connectoway > Em 22/04/2015, ?s 19:01, Evelio Vila escreveu: > > I think the OP is asking about whether it should account for chromatic dispersion or not. Intramodal dispersion may very well be a limit on your link even the power budget (as presented before) is fine. As Mikael said, I would stick to the specs from the manufacturer for that specific module, or rent an OTDR and make the measurements. > > -- > Evelio > >> On Wed, Apr 22, 2015 at 1:51 PM, Baldur Norddahl wrote: >> First: buy a power meter. They are really cheap and the only way to know >> for sure how much signal you got. It will also tell you how much launch >> power you have. The fiberstore modules are listed as 0 to +5 dBm launch >> power - if you got lucky it might be +5 and if you got a lower end module >> it might be close to 0. Obviously this makes a huge difference for how much >> power you get on the other end. Also it is said that the laser will lose >> power over time. >> >> Second you need to think in terms of power budget, not distance. So you got >> 68 km and the module is rated for 80 km - but not all fiber is not born >> equal. A power meter allows you to measure the true link loss. >> >> Third you did not tell what DWDM multiplexer you are using. A 44 channel >> DWDM multiplexer from Fiberstore can have up to 4.5 dB insertion loss. You >> might have two of those on your link for a total of 9 dB loss. Your 80 km >> module has a 23 dB link budget, so this leaves you with 23-9 = 14 dB >> budget. If your fiber has 0.25 dB loss per km, that is only 56 km. >> >> Regards, >> >> Baldur > From shawnl at up.net Wed Apr 22 22:52:54 2015 From: shawnl at up.net (Shawn L) Date: Wed, 22 Apr 2015 18:52:54 -0400 Subject: DWDM and EDFA and DCM In-Reply-To: <79610D4A-FC2F-44F0-9AB1-8ED66E1DD89D@1telecom.com.br> References: <79610D4A-FC2F-44F0-9AB1-8ED66E1DD89D@1telecom.com.br> Message-ID: Remember, distance ratings are just generalizations. It all comes down to power budget. When fiber is laid there are slack loops for potential future service and for use if a cable is cut, splice cases -- because it's hard to work with a fiber spool with more than 5 miles of cable on it, other connectors, hand holes with slack coils, etc. If the route is 80km the actual fiber distance could be more like 100 or 120km with all of the slack. Then you add on DB loss for every splice and connector. As others have said, the only way to really know is to shoot it with a power meter and see what the end to end loss is, and then get the correct optics for the path you have On Wed, Apr 22, 2015 at 6:43 PM, Rodrigo 1telecom wrote: > Nothing is wrong with the fiber... Attenuation is good... Gbics specs says > -23db as a limit of your sensibility ...i have tried to put bidi sfp+ 80km > on this fiber and have -25dbi on other side( not connect) this module have > -20dbi sensibility ... > This scenario have a 4 channels... And i use 2 10gb channels... C21 and > c22 on side A and c51 and c52 on side B.... > > Enviado via iPhone ? > Grupo Connectoway > > > Em 22/04/2015, ?s 19:01, Evelio Vila escreveu: > > > > I think the OP is asking about whether it should account for chromatic > dispersion or not. Intramodal dispersion may very well be a limit on your > link even the power budget (as presented before) is fine. As Mikael said, > I would stick to the specs from the manufacturer for that specific module, > or rent an OTDR and make the measurements. > > > > -- > > Evelio > > > >> On Wed, Apr 22, 2015 at 1:51 PM, Baldur Norddahl < > baldur.norddahl at gmail.com> wrote: > >> First: buy a power meter. They are really cheap and the only way to know > >> for sure how much signal you got. It will also tell you how much launch > >> power you have. The fiberstore modules are listed as 0 to +5 dBm launch > >> power - if you got lucky it might be +5 and if you got a lower end > module > >> it might be close to 0. Obviously this makes a huge difference for how > much > >> power you get on the other end. Also it is said that the laser will lose > >> power over time. > >> > >> Second you need to think in terms of power budget, not distance. So you > got > >> 68 km and the module is rated for 80 km - but not all fiber is not born > >> equal. A power meter allows you to measure the true link loss. > >> > >> Third you did not tell what DWDM multiplexer you are using. A 44 channel > >> DWDM multiplexer from Fiberstore can have up to 4.5 dB insertion loss. > You > >> might have two of those on your link for a total of 9 dB loss. Your 80 > km > >> module has a 23 dB link budget, so this leaves you with 23-9 = 14 dB > >> budget. If your fiber has 0.25 dB loss per km, that is only 56 km. > >> > >> Regards, > >> > >> Baldur > > > From evelio at thousandeyes.com Wed Apr 22 22:01:46 2015 From: evelio at thousandeyes.com (Evelio Vila) Date: Wed, 22 Apr 2015 15:01:46 -0700 Subject: DWDM and EDFA and DCM In-Reply-To: References: Message-ID: I think the OP is asking about whether it should account for chromatic dispersion or not. Intramodal dispersion may very well be a limit on your link even the power budget (as presented before) is fine. As Mikael said, I would stick to the specs from the manufacturer for that specific module, or rent an OTDR and make the measurements. -- Evelio On Wed, Apr 22, 2015 at 1:51 PM, Baldur Norddahl wrote: > First: buy a power meter. They are really cheap and the only way to know > for sure how much signal you got. It will also tell you how much launch > power you have. The fiberstore modules are listed as 0 to +5 dBm launch > power - if you got lucky it might be +5 and if you got a lower end module > it might be close to 0. Obviously this makes a huge difference for how much > power you get on the other end. Also it is said that the laser will lose > power over time. > > Second you need to think in terms of power budget, not distance. So you got > 68 km and the module is rated for 80 km - but not all fiber is not born > equal. A power meter allows you to measure the true link loss. > > Third you did not tell what DWDM multiplexer you are using. A 44 channel > DWDM multiplexer from Fiberstore can have up to 4.5 dB insertion loss. You > might have two of those on your link for a total of 9 dB loss. Your 80 km > module has a 23 dB link budget, so this leaves you with 23-9 = 14 dB > budget. If your fiber has 0.25 dB loss per km, that is only 56 km. > > Regards, > > Baldur > From swmike at swm.pp.se Thu Apr 23 04:01:34 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 23 Apr 2015 06:01:34 +0200 (CEST) Subject: DWDM and EDFA and DCM In-Reply-To: References: Message-ID: On Wed, 22 Apr 2015, Rodrigo Augusto wrote: > Buy 80km sfp+ dwdm modules? c21 and c51. > On this scenario a don?t have a EDFA, only put these sfp+ and I have link > on other side( 60km) but I have a -19dbm and other side I have -21dbm( ddm > sfp+ output).. I think I have a better signal than this? because I use > 80km sfp+ and my distance is 60km? can I have a chromatic dispersion? I > think to use a EDFA, but i?m not sure this? if I have a chromatic > dispersion I have to use a DCM not a ADFA or a booster? > Right?! If you use 80km SFP+ then they should be able to handle the CD (chromatic dispersion) of your 68km fiber stretch, and if you have a power problem, then you can solve that by adding EDFA mid-span. CD causes "noise" (OSNR) to the receiver, it doesn't cause your power levels to be low. So if you want to solve your power problem, add EDFA mid-span. If you want to be able to use 40km optics (they might be cheaper), add DCM as well if the manufacturer rates them as not being able to electronically compensate for dispersion more than 40km. -- Mikael Abrahamsson email: swmike at swm.pp.se From lists.nanog at monmotha.net Thu Apr 23 07:36:23 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Thu, 23 Apr 2015 03:36:23 -0400 Subject: DWDM and EDFA and DCM In-Reply-To: References: Message-ID: <5538A0F7.9030906@monmotha.net> On 04/23/2015 12:01 AM, Mikael Abrahamsson wrote: > > If you use 80km SFP+ then they should be able to handle the CD > (chromatic dispersion) of your 68km fiber stretch, and if you have a > power problem, then you can solve that by adding EDFA mid-span. > > CD causes "noise" (OSNR) to the receiver, it doesn't cause your power > levels to be low. So if you want to solve your power problem, add EDFA > mid-span. If you want to be able to use 40km optics (they might be > cheaper), add DCM as well if the manufacturer rates them as not being > able to electronically compensate for dispersion more than 40km. > Should you find yourself on the edge (or unknowing) of the dispersion tolerance of the 80km modules you would like to use, 120km-tolerant modules are also somewhat readily available these days, including from fiberstore. They don't have the power to shoot 120km without external (generally mid-span) amplification, but they will tolerate the accumulation of ~120km worth of chromatic dispersion. Thus, you can do 120km of fiber (typ.) with EDFAs in the span for power budget reasons but without an accompanying DCM at each hop. Since the commodity DCMs cost almost as much as commodity mid-power EDFAs, these days, that could be a significant cost savings. As always when buying whitebox/commodity networking goods, careful review of the specifications and testing in your proposed application is in order. -- Brandon Martin From gslavic at sox.rs Thu Apr 23 08:06:38 2015 From: gslavic at sox.rs (Goran Slavic) Date: Thu, 23 Apr 2015 10:06:38 +0200 Subject: Fw: Euro-IX quagga stable download and implementation Message-ID: <7b5c414d74bd558bbb473086d422c099@sox.rs> Greetings Mr. Lamparter ? ??????????????? My name is Goran Slavic, and I am contacting you in the name of Serbian Open Exchange (SOX). I have read your post "Bird vs Quagga revisited"? http://mailman.nanog.org/pipermail/nanog/2012-August/051285.html at the mailing list and have an interest in downloading and implementing the Euro-IX version of Quagga in our Internet exchange. My questions are simple: - Considering the time when the post is written (2012) - what is the current status of the Euro-IX Quagga ? - Where can it be downloaded as a stable release / version ? ? I am grateful for any help you can provide with the issue in question. ? Regards G.Slavic ? ? ? ? ? ? ? ?? From rps at maine.edu Thu Apr 23 14:06:42 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 23 Apr 2015 10:06:42 -0400 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <14332523.16.1429740142344.JavaMail.root@benjamin.baylink.com> References: <004101d07ca7$646ef3c0$2d4cdb40$@iname.com> <14332523.16.1429740142344.JavaMail.root@benjamin.baylink.com> Message-ID: It's amazing, really. Netflix and YouTube now overtake BitTorrent and all other file sharing peer-to-peer traffic combined, even on academic networks, by order(s) of magnitude. The amount of peer-to-peer traffic is not even significant in comparison. It might as well be IRC from our perspective. Internet usage habits have shifted quite a bit in the past decade. I think the takeaway is that if you provide content in a way that is fairly priced and convenient to access (e.g. DRM doesn't get in your way), most people will opt for the legal route. Something we were trying to explain to the MPAA and RIAA years ago when they shoved the DMCA down our throats. I'm certainly in favor of symmetrical service. I think there is a widely held myth that DOS attacks will take down the Internet when everyone has more bandwidth. The fact is that DOS attacks are a problem regardless of bandwidth, and throttling people isn't a solution. The other (somewhat insulting) argument that people will use greater upload speeds for illegal activity is pretty bogus as well. The limit on upload bandwidth for most people is a roadblock to a lot of the services that people will take for granted a decade from now; cloud backup, residential video surveillance over IP, peer-to-peer high definition video conferencing. And likely a lot of things that we haven't imagined yet. As funny as it sounds, I think Twitch (streaming video games) has been the application that has made the younger generation care about their upload speed more than anything else. They now have a use case where their limited upload is a real problem for them, and when they find out their ISP can't provide anything good enough they get pretty upset about it. On Wed, Apr 22, 2015 at 6:02 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Frank Bulk" > > > Those are measured at the campus boundary. I don't have visibility inside > > the school's network to know who much intra-campus traffic there may be . > > but we know that peer-to-peer is a small percentage of overall Internet > > traffic flows, and streaming video remains the largets. > > BitTorrent makes special efforts to keep as much traffic local as possible, > I understand; that probably isn't too helpful... except at scales like that > on a resnet at a sizable campus. > > 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 > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From jra at baylink.com Thu Apr 23 14:09:35 2015 From: jra at baylink.com (Jay Ashworth) Date: Thu, 23 Apr 2015 10:09:35 -0400 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <004101d07ca7$646ef3c0$2d4cdb40$@iname.com> <14332523.16.1429740142344.JavaMail.root@benjamin.baylink.com> Message-ID: <26AACEBC-EBA6-4F13-A932-3A3D6666FF77@baylink.com> There's an op-ed piece in this posting, Ray. Do you want to write it, or should I? :-) On April 23, 2015 10:06:42 AM EDT, Ray Soucy wrote: >It's amazing, really. > >Netflix and YouTube now overtake BitTorrent and all other file sharing >peer-to-peer traffic combined, even on academic networks, by order(s) >of >magnitude. The amount of peer-to-peer traffic is not even significant >in >comparison. It might as well be IRC from our perspective. > >Internet usage habits have shifted quite a bit in the past decade. I >think >the takeaway is that if you provide content in a way that is fairly >priced >and convenient to access (e.g. DRM doesn't get in your way), most >people >will opt for the legal route. Something we were trying to explain to >the >MPAA and RIAA years ago when they shoved the DMCA down our throats. > >I'm certainly in favor of symmetrical service. I think there is a >widely >held myth that DOS attacks will take down the Internet when everyone >has >more bandwidth. The fact is that DOS attacks are a problem regardless >of >bandwidth, and throttling people isn't a solution. The other (somewhat >insulting) argument that people will use greater upload speeds for >illegal >activity is pretty bogus as well. > >The limit on upload bandwidth for most people is a roadblock to a lot >of >the services that people will take for granted a decade from now; cloud >backup, residential video surveillance over IP, peer-to-peer high >definition video conferencing. And likely a lot of things that we >haven't >imagined yet. > >As funny as it sounds, I think Twitch (streaming video games) has been >the >application that has made the younger generation care about their >upload >speed more than anything else. They now have a use case where their >limited upload is a real problem for them, and when they find out their >ISP >can't provide anything good enough they get pretty upset about it. > > > > > >On Wed, Apr 22, 2015 at 6:02 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >> > From: "Frank Bulk" >> >> > Those are measured at the campus boundary. I don't have visibility >inside >> > the school's network to know who much intra-campus traffic there >may be . >> > but we know that peer-to-peer is a small percentage of overall >Internet >> > traffic flows, and streaming video remains the largets. >> >> BitTorrent makes special efforts to keep as much traffic local as >possible, >> I understand; that probably isn't too helpful... except at scales >like that >> on a resnet at a sizable campus. >> >> 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 >> > > > >-- >Ray Patrick Soucy >Network Engineer >University of Maine System > >T: 207-561-3526 >F: 207-561-3531 > >MaineREN, Maine's Research and Education Network >www.maineren.net -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From rps at maine.edu Thu Apr 23 14:17:51 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 23 Apr 2015 10:17:51 -0400 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <26AACEBC-EBA6-4F13-A932-3A3D6666FF77@baylink.com> References: <004101d07ca7$646ef3c0$2d4cdb40$@iname.com> <14332523.16.1429740142344.JavaMail.root@benjamin.baylink.com> <26AACEBC-EBA6-4F13-A932-3A3D6666FF77@baylink.com> Message-ID: Sorry, I know I get long-winded. That's why I don't post as much as I used to. ;-) On Thu, Apr 23, 2015 at 10:09 AM, Jay Ashworth wrote: > There's an op-ed piece in this posting, Ray. Do you want to write it, or > should I? > > :-) > > > On April 23, 2015 10:06:42 AM EDT, Ray Soucy wrote: >> >> It's amazing, really. >> >> Netflix and YouTube now overtake BitTorrent and all other file sharing >> peer-to-peer traffic combined, even on academic networks, by order(s) of >> magnitude. The amount of peer-to-peer traffic is not even significant in >> comparison. It might as well be IRC from our perspective. >> >> Internet usage habits have shifted quite a bit in the past decade. I >> think the takeaway is that if you provide content in a way that is fairly >> priced and convenient to access (e.g. DRM doesn't get in your way), most >> people will opt for the legal route. Something we were trying to explain >> to the MPAA and RIAA years ago when they shoved the DMCA down our throats. >> >> I'm certainly in favor of symmetrical service. I think there is a widely >> held myth that DOS attacks will take down the Internet when everyone has >> more bandwidth. The fact is that DOS attacks are a problem regardless of >> bandwidth, and throttling people isn't a solution. The other (somewhat >> insulting) argument that people will use greater upload speeds for illegal >> activity is pretty bogus as well. >> >> The limit on upload bandwidth for most people is a roadblock to a lot of >> the services that people will take for granted a decade from now; cloud >> backup, residential video surveillance over IP, peer-to-peer high >> definition video conferencing. And likely a lot of things that we haven't >> imagined yet. >> >> As funny as it sounds, I think Twitch (streaming video games) has been >> the application that has made the younger generation care about their >> upload speed more than anything else. They now have a use case where their >> limited upload is a real problem for them, and when they find out their ISP >> can't provide anything good enough they get pretty upset about it. >> >> >> >> >> >> On Wed, Apr 22, 2015 at 6:02 PM, Jay Ashworth wrote: >> >>> ----- Original Message ----- >>> > From: "Frank Bulk" >>> >>> > Those are measured at the campus boundary. I don't have visibility >>> inside >>> > the school's network to know who much intra-campus traffic there may >>> be . >>> > but we know that peer-to-peer is a small percentage of overall Internet >>> > traffic flows, and streaming video remains the largets. >>> >>> BitTorrent makes special efforts to keep as much traffic local as >>> possible, >>> I understand; that probably isn't too helpful... except at scales like >>> that >>> on a resnet at a sizable campus. >>> >>> 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 >>> >> >> >> >> -- >> Ray Patrick Soucy >> Network Engineer >> University of Maine System >> >> T: 207-561-3526 >> F: 207-561-3531 >> >> MaineREN, Maine's Research and Education Network >> www.maineren.net >> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From jra at baylink.com Thu Apr 23 14:19:39 2015 From: jra at baylink.com (Jay Ashworth) Date: Thu, 23 Apr 2015 10:19:39 -0400 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <004101d07ca7$646ef3c0$2d4cdb40$@iname.com> <14332523.16.1429740142344.JavaMail.root@benjamin.baylink.com> <26AACEBC-EBA6-4F13-A932-3A3D6666FF77@baylink.com> Message-ID: <7B9F2350-6CBF-433F-B4B6-D00622378AF2@baylink.com> I wasn't being funny. :-) That was about a quarter to a third of a /wonderful/ #takethat to the *AA... On April 23, 2015 10:17:51 AM EDT, Ray Soucy wrote: >Sorry, I know I get long-winded. That's why I don't post as much as I >used >to. ;-) > >On Thu, Apr 23, 2015 at 10:09 AM, Jay Ashworth wrote: > >> There's an op-ed piece in this posting, Ray. Do you want to write it, >or >> should I? >> >> :-) >> >> >> On April 23, 2015 10:06:42 AM EDT, Ray Soucy wrote: >>> >>> It's amazing, really. >>> >>> Netflix and YouTube now overtake BitTorrent and all other file >sharing >>> peer-to-peer traffic combined, even on academic networks, by >order(s) of >>> magnitude. The amount of peer-to-peer traffic is not even >significant in >>> comparison. It might as well be IRC from our perspective. >>> >>> Internet usage habits have shifted quite a bit in the past decade. >I >>> think the takeaway is that if you provide content in a way that is >fairly >>> priced and convenient to access (e.g. DRM doesn't get in your way), >most >>> people will opt for the legal route. Something we were trying to >explain >>> to the MPAA and RIAA years ago when they shoved the DMCA down our >throats. >>> >>> I'm certainly in favor of symmetrical service. I think there is a >widely >>> held myth that DOS attacks will take down the Internet when everyone >has >>> more bandwidth. The fact is that DOS attacks are a problem >regardless of >>> bandwidth, and throttling people isn't a solution. The other >(somewhat >>> insulting) argument that people will use greater upload speeds for >illegal >>> activity is pretty bogus as well. >>> >>> The limit on upload bandwidth for most people is a roadblock to a >lot of >>> the services that people will take for granted a decade from now; >cloud >>> backup, residential video surveillance over IP, peer-to-peer high >>> definition video conferencing. And likely a lot of things that we >haven't >>> imagined yet. >>> >>> As funny as it sounds, I think Twitch (streaming video games) has >been >>> the application that has made the younger generation care about >their >>> upload speed more than anything else. They now have a use case >where their >>> limited upload is a real problem for them, and when they find out >their ISP >>> can't provide anything good enough they get pretty upset about it. >>> >>> >>> >>> >>> >>> On Wed, Apr 22, 2015 at 6:02 PM, Jay Ashworth >wrote: >>> >>>> ----- Original Message ----- >>>> > From: "Frank Bulk" >>>> >>>> > Those are measured at the campus boundary. I don't have >visibility >>>> inside >>>> > the school's network to know who much intra-campus traffic there >may >>>> be . >>>> > but we know that peer-to-peer is a small percentage of overall >Internet >>>> > traffic flows, and streaming video remains the largets. >>>> >>>> BitTorrent makes special efforts to keep as much traffic local as >>>> possible, >>>> I understand; that probably isn't too helpful... except at scales >like >>>> that >>>> on a resnet at a sizable campus. >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Ray Patrick Soucy >>> Network Engineer >>> University of Maine System >>> >>> T: 207-561-3526 >>> F: 207-561-3531 >>> >>> MaineREN, Maine's Research and Education Network >>> www.maineren.net >>> >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> > > > >-- >Ray Patrick Soucy >Network Engineer >University of Maine System > >T: 207-561-3526 >F: 207-561-3531 > >MaineREN, Maine's Research and Education Network >www.maineren.net -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From Daniel.Jameson at tdstelecom.com Thu Apr 23 16:34:05 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Thu, 23 Apr 2015 16:34:05 +0000 Subject: DWDM and EDFA and DCM In-Reply-To: <5538A0F7.9030906@monmotha.net> References: <5538A0F7.9030906@monmotha.net> Message-ID: Rule of thumb is you need Dispersion compensation for any single span over 60Km. 10G/STM64 has a CD Tolerance of 1176 ps/nm, 40G/STM256 has a CD tolerance of 73.5ps/nm but you don't want your dispersion number to ever go negative. If it's a single-span only rule of thumb is use the next size smaller than the measured fiber distance maintaining at least 10km on the bottom end, 65km would use a 40km dcm 70km would use a 60km dcm. As long as each site does OEO you can do Dispersion hop-by-hop, if any node on the ring pass a channel through, or is only optically amplified, you need to calculate DC along the entire path, ensuring that the DC number never goes negative. DC should be inserted between the egress of the combining mux and the post-amp to maximize your launch power. Try to stay away from channel-by-channel DCM, it gets really messy as the system grows. And remember always clean-scope-clean! -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Thursday, April 23, 2015 2:36 AM To: nanog at nanog.org Subject: Re: DWDM and EDFA and DCM On 04/23/2015 12:01 AM, Mikael Abrahamsson wrote: > > If you use 80km SFP+ then they should be able to handle the CD > (chromatic dispersion) of your 68km fiber stretch, and if you have a > power problem, then you can solve that by adding EDFA mid-span. > > CD causes "noise" (OSNR) to the receiver, it doesn't cause your power > levels to be low. So if you want to solve your power problem, add EDFA > mid-span. If you want to be able to use 40km optics (they might be > cheaper), add DCM as well if the manufacturer rates them as not being > able to electronically compensate for dispersion more than 40km. > Should you find yourself on the edge (or unknowing) of the dispersion tolerance of the 80km modules you would like to use, 120km-tolerant modules are also somewhat readily available these days, including from fiberstore. They don't have the power to shoot 120km without external (generally mid-span) amplification, but they will tolerate the accumulation of ~120km worth of chromatic dispersion. Thus, you can do 120km of fiber (typ.) with EDFAs in the span for power budget reasons but without an accompanying DCM at each hop. Since the commodity DCMs cost almost as much as commodity mid-power EDFAs, these days, that could be a significant cost savings. As always when buying whitebox/commodity networking goods, careful review of the specifications and testing in your proposed application is in order. -- Brandon Martin From jason at lixfeld.ca Thu Apr 23 18:37:47 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 23 Apr 2015 14:37:47 -0400 Subject: Infinera sales contact? Message-ID: Might someone have an Infinera sales contact handy for Canada? Information submitted via their web form doesn?t seem to be getting much attention. Thanks! From andy at nosignal.org Fri Apr 24 09:30:12 2015 From: andy at nosignal.org (Andy Davidson) Date: Fri, 24 Apr 2015 09:30:12 +0000 Subject: Euro-IX quagga stable download and implementation In-Reply-To: <7b5c414d74bd558bbb473086d422c099@sox.rs> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> Message-ID: <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> Hi, Goran, everyone -- On 23 Apr 2015, at 09:06, Goran Slavic wrote: > at the mailing list and have an interest in downloading and implementing the Euro-IX version of Quagga in our Internet exchange. My questions are simple: > - Considering the time when the post is written (2012) - what is the current status of the Euro-IX Quagga ? > - Where can it be downloaded as a stable release / version ? This email is a comment on using this software as a route-server, and not a comment on using this software as a RIB manager on a forwarding device - if you?re a reader from the future trying to understand about running this software on a router, then please bear this in mind. There are three well known open source BGP implementations which are commonly used as a route-server - BIRD, Quagga, and OpenBGPd. It is typical to configure them today in a way that has the route-server calculate a different RIB for every connected ASN on your exchange. This is because it is also common to allow route-server users to filter (prevent their prefixes reaching) other participants. Information about why this is important has been published in various presentations and papers at IX and operator events. Calculating best-path for every participant becomes complex when you have a lot of participants, further when the number of prefixes on the exchange grows. OpenBGPd will stay up but take a very long time to process and forward announce/withdraw BGP messages. On a ~100 ASN/participant/table system with ~5000 prefixes, it can take anywhere up to an hour for a withdraw to be processed and forwarded which means your participants will get a route that is withdrawn for a long time and blackhole traffic at the exchange. It is therefore problematic to use this software on all but the smallest exchanges. It?s OK on small instances but does not scale. Quagga?s vanilla build will fail to stay up with large numbers of tables and participants. Chris Hall did an amazing job at making a build that was more prone to staying up and his build is doing a sterling job at LINX (alongside BIRD) but I understand that this source tree is no longer maintained and that the task of merging his stability fixes into the mainline or OSR (https://www.opensourcerouting.org) version is not a simple job and has not been done. This gives me a serious concern about the future of this branch. BIRD just doesn?t die, no matter what scale we seem to throw at it. This thing just keeps flying. We now have two (busy) BIRD instances at the LONAP exchange in London where most of our 150 exchange point members use the service. Goran - SOX is a member of the Euro-IX association for exchange points and there is a private mailing list for members who operate route-servers. There may be a greater concentration of route-server operators on that list so it?s probably worth continuing the discussion there? You sign in to the website and visit https://www.euro-ix.net/mailing-list-archives to subscribe. With best wishes, Andy Davidson (Relevant Hats: LONAP, IXLeeds, Euro-IX, IIX, NapAfrica) From nanog at ics-il.net Fri Apr 24 11:48:53 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 24 Apr 2015 06:48:53 -0500 (CDT) Subject: Euro-IX quagga stable download and implementation In-Reply-To: <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> Message-ID: <7883384.5871.1429876126477.JavaMail.mhammett@ThunderFuck> The best IX list I've found is Open-IX as it's the only one I've found dedicated to IXes while still being public. Tried to join the Euro-IX ones, but as you indicated... members only. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Andy Davidson" To: "Goran Slavic" Cc: nanog at nanog.org Sent: Friday, April 24, 2015 4:30:12 AM Subject: Re: Euro-IX quagga stable download and implementation Hi, Goran, everyone -- On 23 Apr 2015, at 09:06, Goran Slavic wrote: > at the mailing list and have an interest in downloading and implementing the Euro-IX version of Quagga in our Internet exchange. My questions are simple: > - Considering the time when the post is written (2012) - what is the current status of the Euro-IX Quagga ? > - Where can it be downloaded as a stable release / version ? This email is a comment on using this software as a route-server, and not a comment on using this software as a RIB manager on a forwarding device - if you?re a reader from the future trying to understand about running this software on a router, then please bear this in mind. There are three well known open source BGP implementations which are commonly used as a route-server - BIRD, Quagga, and OpenBGPd. It is typical to configure them today in a way that has the route-server calculate a different RIB for every connected ASN on your exchange. This is because it is also common to allow route-server users to filter (prevent their prefixes reaching) other participants. Information about why this is important has been published in various presentations and papers at IX and operator events. Calculating best-path for every participant becomes complex when you have a lot of participants, further when the number of prefixes on the exchange grows. OpenBGPd will stay up but take a very long time to process and forward announce/withdraw BGP messages. On a ~100 ASN/participant/table system with ~5000 prefixes, it can take anywhere up to an hour for a withdraw to be processed and forwarded which means your participants will get a route that is withdrawn for a long time and blackhole traffic at the exchange. It is therefore problematic to use this software on all but the smallest exchanges. It?s OK on small instances but does not scale. Quagga?s vanilla build will fail to stay up with large numbers of tables and participants. Chris Hall did an amazing job at making a build that was more prone to staying up and his build is doing a sterling job at LINX (alongside BIRD) but I understand that this source tree is no longer maintained and that the task of merging his stability fixes into the mainline or OSR (https://www.opensourcerouting.org) version is not a simple job and has not been done. This gives me a serious concern about the future of this branch. BIRD just doesn?t die, no matter what scale we seem to throw at it. This thing just keeps flying. We now have two (busy) BIRD instances at the LONAP exchange in London where most of our 150 exchange point members use the service. Goran - SOX is a member of the Euro-IX association for exchange points and there is a private mailing list for members who operate route-servers. There may be a greater concentration of route-server operators on that list so it?s probably worth continuing the discussion there? You sign in to the website and visit https://www.euro-ix.net/mailing-list-archives to subscribe. With best wishes, Andy Davidson (Relevant Hats: LONAP, IXLeeds, Euro-IX, IIX, NapAfrica) From hhoffman at ip-solutions.net Fri Apr 24 12:55:15 2015 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 24 Apr 2015 08:55:15 -0400 Subject: OT: Long term contract work in Boston/Cambridge area Message-ID: <553A3D33.2020108@ip-solutions.net> Good morning, First, I beg your pardon if job posting are unacceptable. I had a quick glance at the website and didn't see anything jump out as prohibited. I've got a couple of contractor positions open in Infosec and am hoping to find someone with a good background in networking, tools (IDS, Flow collection reporting, Splunk, etc.) who is also decent at scripting (most stuff is in perl but python would be ok too). Positions report to me so I'll be able to answer any questions you might have. Cheers, Harry From cscora at apnic.net Fri Apr 24 18:11:28 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Apr 2015 04:11:28 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201504241811.t3OIBSoK025002@thyme.rand.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, CaribNOG and the RIPE Routing Working Group. 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 25 Apr, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 541795 Prefixes after maximum aggregation (per Origin AS): 206788 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 264333 Total ASes present in the Internet Routing Table: 50103 Prefixes per ASN: 10.81 Origin-only ASes present in the Internet Routing Table: 36582 Origin ASes announcing only one prefix: 16288 Transit ASes present in the Internet Routing Table: 6337 Transit-only ASes present in the Internet Routing Table: 175 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 44 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1193 Unregistered ASNs in the Routing Table: 408 Number of 32-bit ASNs allocated by the RIRs: 9255 Number of 32-bit ASNs visible in the Routing Table: 7184 Prefixes from 32-bit ASNs in the Routing Table: 25851 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 360 Number of addresses announced to Internet: 2739318436 Equivalent to 163 /8s, 70 /16s and 174 /24s Percentage of available address space announced: 74.0 Percentage of allocated address space announced: 74.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 182352 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133662 Total APNIC prefixes after maximum aggregation: 38993 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 139448 Unique aggregates announced from the APNIC address blocks: 56810 APNIC Region origin ASes present in the Internet Routing Table: 5040 APNIC Prefixes per ASN: 27.67 APNIC Region origin ASes announcing only one prefix: 1205 APNIC Region transit ASes present in the Internet Routing Table: 875 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1395 Number of APNIC addresses announced to Internet: 747690496 Equivalent to 44 /8s, 144 /16s and 218 /24s Percentage of available APNIC address space announced: 87.4 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, 131072-135580 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: 178367 Total ARIN prefixes after maximum aggregation: 87920 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 180796 Unique aggregates announced from the ARIN address blocks: 84833 ARIN Region origin ASes present in the Internet Routing Table: 16559 ARIN Prefixes per ASN: 10.92 ARIN Region origin ASes announcing only one prefix: 6097 ARIN Region transit ASes present in the Internet Routing Table: 1737 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 409 Number of ARIN addresses announced to Internet: 1065386528 Equivalent to 63 /8s, 128 /16s and 130 /24s Percentage of available ARIN address space announced: 56.4 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, 393216-394239 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: 131539 Total RIPE prefixes after maximum aggregation: 65635 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 137820 Unique aggregates announced from the RIPE address blocks: 84964 RIPE Region origin ASes present in the Internet Routing Table: 17952 RIPE Prefixes per ASN: 7.68 RIPE Region origin ASes announcing only one prefix: 8157 RIPE Region transit ASes present in the Internet Routing Table: 2982 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3634 Number of RIPE addresses announced to Internet: 693611908 Equivalent to 41 /8s, 87 /16s and 173 /24s Percentage of available RIPE address space announced: 100.8 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, 196608-202239 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: 59469 Total LACNIC prefixes after maximum aggregation: 11181 LACNIC Deaggregation factor: 5.32 Prefixes being announced from the LACNIC address blocks: 69431 Unique aggregates announced from the LACNIC address blocks: 32265 LACNIC Region origin ASes present in the Internet Routing Table: 2426 LACNIC Prefixes per ASN: 28.62 LACNIC Region origin ASes announcing only one prefix: 626 LACNIC Region transit ASes present in the Internet Routing Table: 501 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 22 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1638 Number of LACNIC addresses announced to Internet: 167318016 Equivalent to 9 /8s, 249 /16s and 18 /24s Percentage of available LACNIC address space announced: 99.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12738 Total AfriNIC prefixes after maximum aggregation: 3015 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 13940 Unique aggregates announced from the AfriNIC address blocks: 5136 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 18.91 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 158 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 108 Number of AfriNIC addresses announced to Internet: 64997120 Equivalent to 3 /8s, 223 /16s and 199 /24s Percentage of available AfriNIC address space announced: 64.6 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 4766 2923 11557 912 Korea Telecom 17974 2771 904 78 PT Telekomunikasi Indonesia 7545 2374 336 128 TPG Telecom Limited 4755 2012 422 214 TATA Communications formerly 4538 1908 4190 71 China Education and Research 9829 1632 1326 39 National Internet Backbone 9808 1572 8717 28 Guangdong Mobile Communicatio 4808 1442 2244 446 CNCGROUP IP network China169 9583 1409 116 575 Sify Limited 9498 1323 334 95 BHARTI Airtel Ltd. 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 3015 2956 143 Cox Communications Inc. 6389 2832 3688 51 BellSouth.net Inc. 3356 2559 10684 488 Level 3 Communications, Inc. 18566 2040 379 182 MegaPath Corporation 20115 1877 1840 431 Charter Communications 6983 1755 866 245 EarthLink, Inc. 4323 1619 1021 409 tw telecom holdings, inc. 30036 1523 309 496 Mediacom Communications Corp 701 1407 11276 690 MCI Communications Services, 22561 1341 412 243 CenturyTel Internet Holdings, 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 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1964 303 366 TELLCOM ILETISIM HIZMETLERI A 20940 1810 702 1338 Akamai International B.V. 6849 1214 356 24 JSC "Ukrtelecom" 8402 1157 544 15 OJSC "Vimpelcom" 31148 1044 45 21 Freenet Ltd. 13188 1038 97 69 TOV "Bank-Inform" 12479 908 864 83 France Telecom Espana SA 8551 886 373 48 Bezeq International-Ltd 6830 853 2344 451 Liberty Global Operations B.V 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 3216 525 183 Telmex Colombia S.A. 28573 2349 2179 119 NET Servi?os de Comunica??o S 7303 1654 1042 241 Telecom Argentina S.A. 6147 1623 374 30 Telefonica del Peru S.A.A. 8151 1591 3189 454 Uninet S.A. de C.V. 6503 1252 421 57 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 983 2325 35 Tim Celular S.A. 3816 923 418 154 COLOMBIA TELECOMUNICACIONES S 18881 865 1036 22 Global Village Telecom 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 8452 1708 958 13 TE-AS 24863 964 284 27 Link Egypt (Link.NET) 36903 493 248 88 Office National des Postes et 36992 417 1229 32 ETISALAT MISR 37492 302 155 72 Orange Tunisie 24835 300 144 9 Vodafone Data 3741 250 857 208 Internet Solutions 29571 231 21 12 Cote d'Ivoire Telecom 37054 199 19 6 Data Telecom Service 36947 198 807 13 Telecom Algeria 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 10620 3216 525 183 Telmex Colombia S.A. 22773 3015 2956 143 Cox Communications Inc. 4766 2923 11557 912 Korea Telecom 6389 2832 3688 51 BellSouth.net Inc. 17974 2771 904 78 PT Telekomunikasi Indonesia 3356 2559 10684 488 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 7545 2374 336 128 TPG Telecom Limited 28573 2349 2179 119 NET Servi?os de Comunica??o S 18566 2040 379 182 MegaPath Corporation 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 3015 2872 Cox Communications Inc. 6389 2832 2781 BellSouth.net Inc. 17974 2771 2693 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2374 2246 TPG Telecom Limited 28573 2349 2230 NET Servi?os de Comunica??o S 3356 2559 2071 Level 3 Communications, Inc. 4766 2923 2011 Korea Telecom 18566 2040 1858 MegaPath Corporation 4538 1908 1837 China Education and Research Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 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:12 /10:34 /11:94 /12:263 /13:506 /14:1002 /15:1711 /16:12959 /17:7204 /18:12224 /19:25351 /20:35848 /21:38596 /22:59112 /23:51410 /24:292432 /25:1132 /26:1133 /27:709 /28:14 /29:12 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2223 3015 Cox Communications Inc. 18566 1996 2040 MegaPath Corporation 6389 1654 2832 BellSouth.net Inc. 6983 1402 1755 EarthLink, Inc. 30036 1367 1523 Mediacom Communications Corp 34984 1284 1964 TELLCOM ILETISIM HIZMETLERI A 6147 1171 1623 Telefonica del Peru S.A.A. 10620 1133 3216 Telmex Colombia S.A. 11492 1106 1178 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1485 2:678 4:93 5:1758 6:23 8:1420 12:1824 13:10 14:1217 15:17 16:2 17:44 18:21 20:48 23:1210 24:1704 27:1890 31:1528 32:38 33:2 34:5 35:3 36:120 37:1895 38:1019 39:5 40:250 41:2989 42:282 43:1229 44:26 45:462 46:2138 47:39 49:819 50:801 52:12 54:73 55:5 56:8 57:37 58:1276 59:671 60:470 61:1745 62:1333 63:1917 64:4418 65:2249 66:4050 67:2063 68:1053 69:3254 70:956 71:448 72:1955 74:2654 75:324 76:406 77:1458 78:1185 79:797 80:1321 81:1348 82:816 83:688 84:713 85:1362 86:394 87:1066 88:510 89:1830 90:151 91:5990 92:828 93:2219 94:1990 95:2097 96:429 97:354 98:1055 99:49 100:68 101:830 103:7261 104:1597 105:61 106:246 107:940 108:621 109:2038 110:1081 111:1491 112:778 113:1101 114:821 115:1254 116:1329 117:1000 118:1798 119:1447 120:443 121:1045 122:2204 123:1793 124:1510 125:1587 128:532 129:379 130:390 131:1152 132:488 133:174 134:420 135:109 136:325 137:321 138:630 139:152 140:225 141:424 142:661 143:525 144:575 145:115 146:699 147:601 148:1131 149:435 150:573 151:610 152:491 153:242 154:471 155:840 156:407 157:463 158:321 159:995 160:380 161:647 162:1961 163:423 164:673 165:689 166:299 167:808 168:1289 169:164 170:1468 171:241 172:41 173:1531 174:703 175:681 176:1406 177:3747 178:2135 179:889 180:1940 181:1678 182:1746 183:620 184:741 185:3353 186:2707 187:1773 188:2019 189:1574 190:7696 191:937 192:8290 193:5583 194:4127 195:3652 196:1690 197:1054 198:5531 199:5530 200:6634 201:3063 202:9463 203:9100 204:4680 205:2835 206:3085 207:2980 208:3942 209:3958 210:3542 211:1860 212:2470 213:2294 214:862 215:71 216:5554 217:1806 218:685 219:456 220:1412 221:788 222:465 223:670 End of report From miguel at rackforce.com Fri Apr 24 21:55:50 2015 From: miguel at rackforce.com (Miguel Hernandez) Date: Fri, 24 Apr 2015 14:55:50 -0700 (PDT) Subject: Fibre optic patch cables in Vancouver area In-Reply-To: <1069142915.6974086.1429909593608.JavaMail.zimbra@rackforce.com> References: <1069142915.6974086.1429909593608.JavaMail.zimbra@rackforce.com> Message-ID: <70939291.6990020.1429912550073.JavaMail.zimbra@rackforce.com> Hello list, I'm looking to source some various fibre patch cables (LC-LC, LC-SC, 1-2M lengths) in the Vancouver, BC area. - Any places open later than general closing time (4-5pm)? I'm not looking for information about suppliers who require more than 1 day to have ready, and don't allow local pickup. Thanks! - Miguel From cidr-report at potaroo.net Fri Apr 24 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Apr 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201504242200.t3OM00r1028325@wattle.apnic.net> This report has been generated at Fri Apr 24 21:14:34 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-04-15 547852 300435 18-04-15 547919 300361 19-04-15 547731 300474 20-04-15 547953 300487 21-04-15 548027 300965 22-04-15 548127 301072 23-04-15 548418 301342 24-04-15 548904 301551 AS Summary 50360 Number of ASes in routing system 20079 Number of ASes announcing only one prefix 3218 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120958464 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 24Apr15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 548847 301466 247381 45.1% All ASes AS22773 3016 172 2844 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2831 68 2763 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2771 78 2693 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 22 2451 99.1% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2347 317 2030 86.5% NET Servi?os de Comunica??o S.A.,BR AS4755 2010 268 1742 86.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2923 1338 1585 54.2% KIXS-AS-KR Korea Telecom,KR AS6983 1754 248 1506 85.9% ITCDELTA - Earthlink, Inc.,US AS9808 1572 67 1505 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS20115 1877 495 1382 73.6% CHARTER-NET-HKY-NC - Charter Communications,US AS10620 3218 1839 1379 42.9% Telmex Colombia S.A.,CO AS7303 1648 285 1363 82.7% Telecom Argentina S.A.,AR AS6147 1623 267 1356 83.5% Telefonica del Peru S.A.A.,PE AS7545 2607 1264 1343 51.5% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1626 411 1215 74.7% TWTC - tw telecom holdings, inc.,US AS9498 1323 110 1213 91.7% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2039 868 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS8402 1141 24 1117 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS22561 1349 258 1091 80.9% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1139 55 1084 95.2% VIETEL-AS-AP Viettel Corporation,VN AS3356 2566 1499 1067 41.6% LEVEL3 - Level 3 Communications, Inc.,US AS6849 1211 249 962 79.4% UKRTELNET JSC UKRTELECOM,UA AS8151 1595 635 960 60.2% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS8452 1878 987 891 47.4% TE-AS TE-AS,EG AS4538 1926 1043 883 45.8% ERX-CERNET-BKB China Education and Research Network Center,CN AS38285 982 119 863 87.9% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 865 23 842 97.3% Global Village Telecom,BR AS26615 968 161 807 83.4% Tim Celular S.A.,BR AS4780 1079 301 778 72.1% SEEDNET Digital United Inc.,TW Total 55356 13554 41802 75.5% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 45.73.144.0/20 AS33132 FPL-FIBERNET - FPL FiberNet, LLC,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.116.0/22 AS54632 -Reserved AS-,ZZ 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.96.0/21 AS54632 -Reserved AS-,ZZ 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.136.36.0/24 AS11071 IW-ASN-11071 - InfoWest, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.114.136.0/22 AS33866 -Reserved AS-,ZZ 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.83.88.0/22 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.90.0/23 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.91.0/24 AS12910 -Reserved AS-,ZZ 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 24 22:00:04 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Apr 2015 22:00:04 GMT Subject: BGP Update Report Message-ID: <201504242200.t3OM04bY028347@wattle.apnic.net> BGP Update Report Interval: 16-Apr-15 -to- 23-Apr-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 265807 4.6% 2271.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 168514 2.9% 116.2 -- BSNL-NIB National Internet Backbone,IN 3 - AS46230 159223 2.8% 7582.0 -- DUDROP - Dignitas Technology Inc,US 4 - AS61894 89501 1.6% 44750.5 -- FreeBSD Brasil LTDA,BR 5 - AS36947 85688 1.5% 486.9 -- ALGTEL-AS,DZ 6 - AS7713 74404 1.3% 3720.2 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 7 - AS22059 72259 1.3% 12043.2 -- APVIO-1 - Apvio, Inc.,US 8 - AS3709 70356 1.2% 2605.8 -- NET-CITY-SA - City of San Antonio,US 9 - AS42337 69847 1.2% 396.9 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 10 - AS38197 56156 1.0% 44.5 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 11 - AS9583 45630 0.8% 32.9 -- SIFY-AS-IN Sify Limited,IN 12 - AS48159 43113 0.8% 129.9 -- TIC-AS Telecommunication Infrastructure Company,IR 13 - AS25184 40203 0.7% 304.6 -- AFRANET AFRANET Co. Tehran, Iran,IR 14 - AS45899 38950 0.7% 59.6 -- VNPT-AS-VN VNPT Corp,VN 15 - AS25563 36855 0.6% 12285.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 16 - AS7602 34986 0.6% 239.6 -- SPT-AS-VN Saigon Postel Corporation,VN 17 - AS30902 34607 0.6% 317.5 -- NEDA-AS neda rayaneh,IR 18 - AS28573 32765 0.6% 11.0 -- NET Servi?os de Comunica??o S.A.,BR 19 - AS29520 32163 0.6% 1037.5 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 20 - AS197207 31483 0.6% 425.4 -- MCCI-AS Mobile Communication Company of Iran PLC,IR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 89501 1.6% 44750.5 -- FreeBSD Brasil LTDA,BR 2 - AS25563 36855 0.6% 12285.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 3 - AS22059 72259 1.3% 12043.2 -- APVIO-1 - Apvio, Inc.,US 4 - AS393588 9499 0.2% 9499.0 -- MUBEA-FLO - Mubea,US 5 - AS46336 8752 0.1% 8752.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 6 - AS46230 159223 2.8% 7582.0 -- DUDROP - Dignitas Technology Inc,US 7 - AS197914 6159 0.1% 6159.0 -- STOCKHO-AS Stockho Hosting SARL,FR 8 - AS7713 74404 1.3% 3720.2 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 9 - AS133599 3085 0.1% 3085.0 -- FAIRFAXNZ-AS-AP Fairfax NZ SDC,NZ 10 - AS46358 5782 0.1% 2891.0 -- UAT - University of Advancing Technology,US 11 - AS3709 70356 1.2% 2605.8 -- NET-CITY-SA - City of San Antonio,US 12 - AS20386 2559 0.0% 2559.0 -- MOVE-VAN - Move Sales, Inc.,US 13 - AS33045 7137 0.1% 2379.0 -- HGST-AS - HITACHI GLOBAL STORAGE TECHNOLOGIES, INC.,US 14 - AS23752 265807 4.6% 2271.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - AS59846 2165 0.0% 2165.0 -- FGC-AS FGC UES JSC,RU 16 - AS47680 10478 0.2% 2095.6 -- NHCS EOBO Limited,IE 17 - AS35093 3758 0.1% 1879.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 18 - AS55741 1627 0.0% 1627.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 19 - AS33440 6294 0.1% 1573.5 -- WEBRULON-NETWORK - webRulon, LLC,US 20 - AS52925 9062 0.2% 1510.3 -- Ascenty DataCenters Locacao e Servicos LTDA,BR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 132797 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 132269 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 177.10.158.0/24 89499 1.5% AS61894 -- FreeBSD Brasil LTDA,BR 4 - 105.96.0.0/22 82951 1.4% AS36947 -- ALGTEL-AS,DZ 5 - 118.98.88.0/24 74526 1.3% AS64567 -- -Private Use AS-,ZZ AS7713 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 6 - 64.34.125.0/24 36350 0.6% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 76.191.107.0/24 35897 0.6% AS22059 -- APVIO-1 - Apvio, Inc.,US 8 - 196.43.158.0/24 24988 0.4% AS327687 -- RENU,UG 9 - 92.43.216.0/21 12614 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 10 - 185.84.192.0/22 12122 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 11 - 178.174.96.0/19 12119 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 12 - 88.87.160.0/19 10450 0.2% AS47680 -- NHCS EOBO Limited,IE 13 - 192.58.232.0/24 10354 0.2% AS6629 -- NOAA-AS - NOAA,US 14 - 95.138.234.0/24 9975 0.2% AS29520 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 15 - 95.138.240.0/20 9949 0.2% AS29520 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 16 - 95.138.224.0/20 9920 0.2% AS29520 -- ROSINTEL-AS Locked Joint Stock Company OGANER-SERVICE,RU 17 - 192.58.137.0/24 9499 0.2% AS393588 -- MUBEA-FLO - Mubea,US 18 - 42.83.48.0/20 9207 0.2% AS18135 -- BTV BTV Cable television,JP 19 - 177.185.0.0/20 8927 0.1% AS52925 -- Ascenty DataCenters Locacao e Servicos LTDA,BR 20 - 50.200.112.0/24 8752 0.1% AS46336 -- GOODVILLE - Goodville Mutual Casualty Company,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From randy at psg.com Sat Apr 25 00:44:17 2015 From: randy at psg.com (Randy Bush) Date: Sat, 25 Apr 2015 09:44:17 +0900 Subject: dns on fios/frontier In-Reply-To: References: <5534C808.507@foobar.org> Message-ID: thanks for the fix, marla. [ sorry to be slow, i was out ] randy From mwinter at noaccess.com Sat Apr 25 01:41:18 2015 From: mwinter at noaccess.com (Martin Winter) Date: Fri, 24 Apr 2015 18:41:18 -0700 (PDT) Subject: Euro-IX quagga stable download and implementation In-Reply-To: <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> Message-ID: Andy, Goran (and everyone else) Disclaimer first: I work full-time for OpenSourceRouting on Quagga. On Fri, 24 Apr 2015, Andy Davidson wrote: > > Hi, Goran, everyone -- > > On 23 Apr 2015, at 09:06, Goran Slavic wrote: > >> at the mailing list and have an interest in downloading and >> implementing the Euro-IX version of Quagga in our Internet exchange. My >> questions are simple: >> - Considering the time when the post is written (2012) - what is the >> current status of the Euro-IX Quagga ? >> - Where can it be downloaded as a stable release / version ? > [...] > Quagga's vanilla build will fail to stay up with large numbers of > tables and participants. Chris Hall did an amazing job at making a > build that was more prone to staying up and his build is doing a > sterling job at LINX (alongside BIRD) but I understand that this source > tree is no longer maintained and that the task of merging his stability > fixes into the mainline or OSR (https://www.opensourcerouting.org) > version is not a simple job and has not been done. This gives me a > serious concern about the future of this branch. On the Chris Hall branch: Chris did some great work fixing many issues, but unfortunatly, mostly in a solo mission on it's own. The idea (from the beginning when Euro-IX sponsored his work) was to get this integrated back into the mainline Quagga. However, by the time we got access to the code, it was a basically one large diff of 1000's of lines with no git history. This would be a lot of work to pick it apart again, review the code and commit it (in pieces) into the mainline. We talked about supporting it as an alternative BGP daemon, but he changed quite a bit in zebra as well, so this was still too much work. When I say "too much", the issue was that noone was willing to sponsor the work (person or money) to get this integrated. We did (actually multiple times) look into the issues and made different plans on how to get the BGP performance fixed. But so far (in the past), everyone who sponsors us doesn't care much about the BGP scale and cares more on IPv6 with OSPFv3, ISIS etc. So that's where most of our work went. (Plus a lot of testing. I think Quagga is the only Open Source routing platform which is tested against protocol fuzzers and for RFC compliance) There is now (again) some interest (mainly form european IX'es) to look into the problems and we started (again) to evaluate, measure and see how we can fix it on a limited budget. The idea is to really get Quagga usable as a RouteServer to have a 2nd choice (beside Bird). Happy to get donations (We are a US 501c3 non-profit) to actually make it happen. Overall, if everyone here who complains would just donate a little bit money (or some work), then the whole issue would be long solved. > BIRD just doesn?t die, no matter what scale we seem to throw at it. > This thing just keeps flying. Short term, if you are ok with a single solution and need something now for a route-server, I think Bird is the solution. Long term, I hope to get Quagga as an alternative (and for everyone who wants 2 different solutions). Bird initially was (and still is) focused to the Route server & Route reflector application and has some unique features there. Quagga is today more focused as a full routing daemon and mostly used in virtual routers, SDN applications and ToR routers. Regards, Martin Winter (OpenSourceRouting, NetDEF) From lorell at hathcock.org Sat Apr 25 15:53:23 2015 From: lorell at hathcock.org (lorell at hathcock.org) Date: Sat, 25 Apr 2015 10:53:23 -0500 Subject: FW: OSP multi-fiber Network-to Network Interface - Recommendations requested In-Reply-To: <002501d07f6f$3185bcd0$94913670$@solstarnetwork.com> References: <005001d07dda$af44ab40$0dce01c0$@solstarnetwork.com> <00a101d07dde$c3dfa510$4b9eef30$@solstarnetwork.com> <00b801d07de0$07514fa0$15f3eee0$@solstarnetwork.com> <00d801d07de5$7a7dc530$6f794f90$@solstarnetwork.com> <00f201d07de5$c56b22e0$504168a0$@solstarnetwork.com> <002501d07f6f$3185bcd0$94913670$@solstarnetwork.com> Message-ID: <003d01d07f6f$f648fbe0$e2daf3a0$@hathcock.org> NANOG: The purpose of this email is to discuss information, standards, recommendations, et cetera about interconnect solutions considering the parameters contained herein. We believe the correct term is a multi-fiber network to network interface. My firm has made an IRU agreement with a municipality to use each other's OSP fibers. In most of the City's OSP, they have a 96 strand count fiber with eight buffer tubes (each buffer tube having 12 fibers). They have dedicated the black buffer tube for our use (again, 12 strands) We have yet to build any OSP fiber plant. When we do and when we interconnect with the City's fiber, we will extend a minimum of 96 fibers. When our plant extends in public right of way, we will interconnect 84 strands (maybe 7 buffer tubes with 12 strands each) of our fiber to the City and keep a minimum of one for our ourselves. It is highly likely that we will pull a much higher fiber count cable to give ourselves additional fibers beyond just 12 strands. On certain projects, when outside City limits and/or on private right of way within City limits, we are required to give them 12 strands of fiber. When we interconnect with their fiber, we must consider the following: 1. How many strands with which will we interconnect? a. If we are interconnecting in the middle of a City span, we must think about interconnecting with North-bound and South-bound fibers. (12 fibers for us going in two directions and as many as 84 fibers for them going in two directions). b. If we are connecting at the end of a City span, we must consider just the South-bound fibers and the interconnection between our OSP. 2. Available real estate for placing vaults, pedestals, FDHs, et cetera. 3. The likelihood of damage from accidents on the adjacent roads. 4. The likelihood of water filling up underground vaults. 5. dB loss resulting from splices, interconnects, et cetera. 6. Scalability and future growth. 7. Other considerations? In our discussions with the City, we have contemplated a dual cabinet system where we ask the following questions to determine how to load those cabinets. 1. Where is the proposed interconnect in terms of real estate and adjacent traffic? (Find a safe place with enough real estate). 2. How many fibers will interconnect from our network to theirs? (either 12 or 84 for each direction we take from the site - most likely just one direction). 3. How many fibers will interconnect from their network to ours? (just 12 at most, but likely in at least two directions - because we are cutting into their fiber mid-span) Once those questions are answered, then we can design and build the cabinets. Also, we want to be cost effective in this design. Thanks in advance for a push in the right direction. Sincerely, Lorell Hathcock Chief Technology Officer SolStar Network, LLC From andy at nosignal.org Sat Apr 25 19:34:17 2015 From: andy at nosignal.org (Andy Davidson) Date: Sat, 25 Apr 2015 19:34:17 +0000 Subject: Euro-IX quagga stable download and implementation In-Reply-To: <002101d07f8c$67f67b20$37e37160$@rs> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> Message-ID: <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> On 25 Apr 2015, at 15:16, Goran Slavi? wrote: > Considering what I have learned in your posts (and on other places > that I have informed myself) I will definitely suggest to SOX management to > go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) for > the simple reason that 2 different solution provides more security in > context of "new program update->new bugs" problems and incidents and > prevents other potential problems. Goran - glad to have helped. One last piece of advice which might be useful - to help to guarantee consistency of performance between the two route-servers, you should consider a configuration generator so that your route-server configs are in sync. The best way to implement this at your exchange is to use IXP Manager, maintained by the awesome folks at the Irish exchange point, INEX. https://github.com/inex/IXP-Manager IXP Manager will get you lots of other features as well as good route-server hygiene. There?s also a historic perl-script that does this on my personal github. Both of these solutions allow you to filter route-server participants based on IRR data, which has proved to be a life-saver at all of the exchanges I help to operate. Having my horrible historic thing is maybe better than no thing at all, but I deliberately won?t link to it as you should really use IXP Manager. :-) Andy From isabeldias1 at yahoo.com Fri Apr 24 14:16:08 2015 From: isabeldias1 at yahoo.com (Isabel Dias) Date: Fri, 24 Apr 2015 07:16:08 -0700 Subject: OT: Long term contract work in Boston/Cambridge area In-Reply-To: <553A3D33.2020108@ip-solutions.net> Message-ID: <1429884968.96979.YahooMailBasic@web122002.mail.ne1.yahoo.com> Please send the job spec.................. -------------------------------------------- On Fri, 4/24/15, Harry Hoffman wrote: Subject: OT: Long term contract work in Boston/Cambridge area To: "NANOG" Date: Friday, April 24, 2015, 1:55 PM Good morning, First, I beg your pardon if job posting are unacceptable. I had a quick glance at the website and didn't see anything jump out as prohibited. I've got a couple of contractor positions open in Infosec and am hoping to find someone with a good background in networking, tools (IDS, Flow collection reporting, Splunk, etc.) who is also decent at scripting (most stuff is in perl but python would be ok too). Positions report to me so I'll be able to answer any questions you might have. Cheers, Harry From gslavic at sox.rs Sat Apr 25 19:16:59 2015 From: gslavic at sox.rs (=?iso-8859-2?Q?Goran_Slavi=E6?=) Date: Sat, 25 Apr 2015 21:16:59 +0200 Subject: Euro-IX quagga stable download and implementation In-Reply-To: References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> Message-ID: <002101d07f8c$67f67b20$37e37160$@rs> Hello Andy, Martin and everyone else First I would like to thank you all on extremely well written and well-argumented posts. SOX operated Quagga route servers for many years but as the number of peers (and more importantly prefixes) has grown we began to see very disturbing warning signs that the stability of those servers is at peril. "Clear" commands that take forever, over processing of requests that makes Quagga forget to send keep-alive pockets to peers, constant memory leakage etc. Considering that those problems have began to multiply and escalate with every new peering - I was tasked to find and implement the alternative for current route servers in order to improve stability or find the alternative to program packages we currently use. Considering what I have learned in your posts (and on other places that I have informed myself) I will definitely suggest to SOX management to go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) for the simple reason that 2 different solution provides more security in context of "new program update->new bugs" problems and incidents and prevents other potential problems. I am extremely grateful for your help specially in the context of how much time it has saved me and good arguments it has given me for the solution I plan to implement. I hope we will continue future discussions and exchange of ideas on Euro-IX forums/mailing lists. Regards, Goran Slavi? SOX -----Original Message----- From: Martin Winter [mailto:mwinter at noaccess.com] Sent: Saturday, 25 April 2015 03:41 To: Andy Davidson Cc: Goran Slavic; nanog at nanog.org Subject: Re: Euro-IX quagga stable download and implementation Andy, Goran (and everyone else) Disclaimer first: I work full-time for OpenSourceRouting on Quagga. On Fri, 24 Apr 2015, Andy Davidson wrote: > > Hi, Goran, everyone -- > > On 23 Apr 2015, at 09:06, Goran Slavic wrote: > >> at the mailing list and have an interest in downloading and >> implementing the Euro-IX version of Quagga in our Internet exchange. My >> questions are simple: >> - Considering the time when the post is written (2012) - what is the >> current status of the Euro-IX Quagga ? >> - Where can it be downloaded as a stable release / version ? > [...] > Quagga's vanilla build will fail to stay up with large numbers of > tables and participants. Chris Hall did an amazing job at making a > build that was more prone to staying up and his build is doing a > sterling job at LINX (alongside BIRD) but I understand that this source > tree is no longer maintained and that the task of merging his stability > fixes into the mainline or OSR (https://www.opensourcerouting.org) > version is not a simple job and has not been done. This gives me a > serious concern about the future of this branch. On the Chris Hall branch: Chris did some great work fixing many issues, but unfortunatly, mostly in a solo mission on it's own. The idea (from the beginning when Euro-IX sponsored his work) was to get this integrated back into the mainline Quagga. However, by the time we got access to the code, it was a basically one large diff of 1000's of lines with no git history. This would be a lot of work to pick it apart again, review the code and commit it (in pieces) into the mainline. We talked about supporting it as an alternative BGP daemon, but he changed quite a bit in zebra as well, so this was still too much work. When I say "too much", the issue was that noone was willing to sponsor the work (person or money) to get this integrated. We did (actually multiple times) look into the issues and made different plans on how to get the BGP performance fixed. But so far (in the past), everyone who sponsors us doesn't care much about the BGP scale and cares more on IPv6 with OSPFv3, ISIS etc. So that's where most of our work went. (Plus a lot of testing. I think Quagga is the only Open Source routing platform which is tested against protocol fuzzers and for RFC compliance) There is now (again) some interest (mainly form european IX'es) to look into the problems and we started (again) to evaluate, measure and see how we can fix it on a limited budget. The idea is to really get Quagga usable as a RouteServer to have a 2nd choice (beside Bird). Happy to get donations (We are a US 501c3 non-profit) to actually make it happen. Overall, if everyone here who complains would just donate a little bit money (or some work), then the whole issue would be long solved. > BIRD just doesn't die, no matter what scale we seem to throw at it. > This thing just keeps flying. Short term, if you are ok with a single solution and need something now for a route-server, I think Bird is the solution. Long term, I hope to get Quagga as an alternative (and for everyone who wants 2 different solutions). Bird initially was (and still is) focused to the Route server & Route reflector application and has some unique features there. Quagga is today more focused as a full routing daemon and mostly used in virtual routers, SDN applications and ToR routers. Regards, Martin Winter (OpenSourceRouting, NetDEF) From gslavic at sox.rs Sat Apr 25 20:06:11 2015 From: gslavic at sox.rs (=?iso-8859-2?Q?Goran_Slavi=E6?=) Date: Sat, 25 Apr 2015 22:06:11 +0200 Subject: Euro-IX quagga stable download and implementation In-Reply-To: <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> References: <7b5c414d74bd558bbb473086d422c099@sox.rs> <13A7BFA0-E258-4A85-9879-95E0CD3FD786@nosignal.org> <002101d07f8c$67f67b20$37e37160$@rs> <54BC7947-5766-447F-B1A2-7BB137411F98@nosignal.org> Message-ID: <002201d07f93$478fc970$d6af5c50$@rs> Andy, Believe me when I say: I would never have the idea to think about attempting to try to test my ability to generate configurations for this "2 route servers/ 2 different programs that run them" solution without the IXP Manager :-) I am familiar with the work INEX has been doing with IXP Manager and have for some time attempted to find time from regular SOX operation to implement it in our IX. This migration gives me the excellent opportunity and arguments to finally allocate time, resources and manpower for installation and implementation of IXP Manager as the route server configuration generator at SOX. Regards G.Slavic -----Original Message----- From: Andy Davidson [mailto:andy at nosignal.org] Sent: Saturday, 25 April 2015 21:34 To: Goran Slavi? Cc: nanog at nanog.org Subject: Re: Euro-IX quagga stable download and implementation On 25 Apr 2015, at 15:16, Goran Slavi? wrote: > Considering what I have learned in your posts (and on other places > that I have informed myself) I will definitely suggest to SOX management to > go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) for > the simple reason that 2 different solution provides more security in > context of "new program update->new bugs" problems and incidents and > prevents other potential problems. Goran - glad to have helped. One last piece of advice which might be useful - to help to guarantee consistency of performance between the two route-servers, you should consider a configuration generator so that your route-server configs are in sync. The best way to implement this at your exchange is to use IXP Manager, maintained by the awesome folks at the Irish exchange point, INEX. https://github.com/inex/IXP-Manager IXP Manager will get you lots of other features as well as good route-server hygiene. There's also a historic perl-script that does this on my personal github. Both of these solutions allow you to filter route-server participants based on IRR data, which has proved to be a life-saver at all of the exchanges I help to operate. Having my horrible historic thing is maybe better than no thing at all, but I deliberately won't link to it as you should really use IXP Manager. :-) Andy= From lorell at hathcock.org Mon Apr 27 16:23:58 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Mon, 27 Apr 2015 11:23:58 -0500 Subject: OSP multi-fiber Network-to Network Interface - Recommendations requested In-Reply-To: <003d01d07f6f$f648fbe0$e2daf3a0$@hathcock.org> References: <005001d07dda$af44ab40$0dce01c0$@solstarnetwork.com> <00a101d07dde$c3dfa510$4b9eef30$@solstarnetwork.com> <00b801d07de0$07514fa0$15f3eee0$@solstarnetwork.com> <00d801d07de5$7a7dc530$6f794f90$@solstarnetwork.com> <00f201d07de5$c56b22e0$504168a0$@solstarnetwork.com> <002501d07f6f$3185bcd0$94913670$@solstarnetwork.com> <003d01d07f6f$f648fbe0$e2daf3a0$@hathcock.org> Message-ID: <604c01d08106$907618f0$b1624ad0$@hathcock.org> It's rare that NANOG is speechless on an issue. Have I stumped the experts? :) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of lorell at hathcock.org Sent: Saturday, April 25, 2015 10:53 AM To: nanog at nanog.org Subject: FW: OSP multi-fiber Network-to Network Interface - Recommendations requested NANOG: The purpose of this email is to discuss information, standards, recommendations, et cetera about interconnect solutions considering the parameters contained herein. We believe the correct term is a multi-fiber network to network interface. My firm has made an IRU agreement with a municipality to use each other's OSP fibers. In most of the City's OSP, they have a 96 strand count fiber with eight buffer tubes (each buffer tube having 12 fibers). They have dedicated the black buffer tube for our use (again, 12 strands) We have yet to build any OSP fiber plant. When we do and when we interconnect with the City's fiber, we will extend a minimum of 96 fibers. When our plant extends in public right of way, we will interconnect 84 strands (maybe 7 buffer tubes with 12 strands each) of our fiber to the City and keep a minimum of one for our ourselves. It is highly likely that we will pull a much higher fiber count cable to give ourselves additional fibers beyond just 12 strands. On certain projects, when outside City limits and/or on private right of way within City limits, we are required to give them 12 strands of fiber. When we interconnect with their fiber, we must consider the following: 1. How many strands with which will we interconnect? a. If we are interconnecting in the middle of a City span, we must think about interconnecting with North-bound and South-bound fibers. (12 fibers for us going in two directions and as many as 84 fibers for them going in two directions). b. If we are connecting at the end of a City span, we must consider just the South-bound fibers and the interconnection between our OSP. 2. Available real estate for placing vaults, pedestals, FDHs, et cetera. 3. The likelihood of damage from accidents on the adjacent roads. 4. The likelihood of water filling up underground vaults. 5. dB loss resulting from splices, interconnects, et cetera. 6. Scalability and future growth. 7. Other considerations? In our discussions with the City, we have contemplated a dual cabinet system where we ask the following questions to determine how to load those cabinets. 1. Where is the proposed interconnect in terms of real estate and adjacent traffic? (Find a safe place with enough real estate). 2. How many fibers will interconnect from our network to theirs? (either 12 or 84 for each direction we take from the site - most likely just one direction). 3. How many fibers will interconnect from their network to ours? (just 12 at most, but likely in at least two directions - because we are cutting into their fiber mid-span) Once those questions are answered, then we can design and build the cabinets. Also, we want to be cost effective in this design. Thanks in advance for a push in the right direction. Sincerely, Lorell Hathcock Chief Technology Officer SolStar Network, LLC From leo at vegoda.org Mon Apr 27 16:42:21 2015 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 27 Apr 2015 17:42:21 +0100 Subject: 192.0.1.0/24? In-Reply-To: <55319CBC.6060205@dougbarton.us> References: <55319CBC.6060205@dougbarton.us> Message-ID: <20150427164221.GA4276@vegoda.org> Hi, On Fri, Apr 17, 2015 at 04:52:28PM -0700, Doug Barton wrote: [...] > I've also cc'ed Leo and Michelle from ICANN so that hopefully they > can see about getting some whois info set up for that network. > Michelle, let me know if it would be easier for you if I opened a > ticket for this request. As Harley correctly notes, in 1990 192.0.1.0/24 was listed in RFC 1166 as BBN-TEST-C. RFC 1166 was one in a series of status reports on the distribution of Internet Number Resources and other protocol parameters that started in the 1970s and continued until RFC 1700, which was published in 1994. Eight years later, RFC 3232 noted that the function provided by those reports had been provided via an online database since 1994. RFC 3232 noted that the periodic status reports might be continued by a new organization. Most of that reporting responsibility was taken on by the RIRs. However, in 2002 RFC 3330 provided an update on the special use IPv4 addresses that had been assigned in various RFCs. RFC 3330 did not include any mention of 192.0.1.0/24 and nor did its successor, RFC 5735. RFC 6890 was published In 2013 and created a pair of IANA registries for special-purpose IPv4 and IPv6 addresses. 192.0.1.0/24 is not listed in the IANA IPv4 Special-Purpose Address Registry (https://www.iana.org/assignments/iana-ipv4-special-registry) and has no special purpose. ARIN is the administrator of 192.0.0.0/8 and other than special-purpose assignments registered in accordance with the requirements of section 4.3 of RFC 2860, addresses in this /8 are allocated according to ARIN policy. I hope this is helpful. Regards, Leo Vegoda From Matthew.Black at csulb.edu Mon Apr 27 20:59:01 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 27 Apr 2015 20:59:01 +0000 Subject: Yahoo postmaster Message-ID: One of our user?s e-mail messages to Yahoo bounced with the following link for more information: http://postmaster.yahoo.com/errors/postmaster-27.html which redirects to https://help.yahoo.com/kb/postmaster/SLN5067.html?impressions=true That page contains a link to ?Yahoo Mail and Yahoo Messenger Terms of Service?, which is broken! http://https//info.yahoo.com/legal/us/yahoo/mail/en-us/ It redirects to an https link saying, Server not found. I hope someone from Yahoo can fix this. matthew black california state university, long beach From zwicky at yahoo-inc.com Mon Apr 27 21:13:58 2015 From: zwicky at yahoo-inc.com (Elizabeth Zwicky) Date: Mon, 27 Apr 2015 21:13:58 +0000 (UTC) Subject: Yahoo postmaster In-Reply-To: References: Message-ID: <2115448201.14713.1430169238826.JavaMail.yahoo@mail.yahoo.com> http://postmaster.yahoo.com will allow you to contact the postmaster team for assistance. I've reported this error already, but fixing it won't help you any; basically, the web page without the link is all Yahoo's willing to publicly say about that error message, you'll need to talk to postmaster for help debugging your particular situation. Elizabeth ZwickyYahoo Mail On Monday, April 27, 2015 2:02 PM, Matthew Black wrote: One of our user?s e-mail messages to Yahoo bounced with the following link for more information: http://postmaster.yahoo.com/errors/postmaster-27.html which redirects to https://help.yahoo.com/kb/postmaster/SLN5067.html?impressions=true That page contains a link to ?Yahoo Mail and Yahoo Messenger Terms of Service?, which is broken! http://https//info.yahoo.com/legal/us/yahoo/mail/en-us/ It redirects to an https link? saying, Server not found. I hope someone from Yahoo can fix this. matthew black california state university, long beach From clay at bloomcounty.org Mon Apr 27 21:55:14 2015 From: clay at bloomcounty.org (Clay Fiske) Date: Mon, 27 Apr 2015 14:55:14 -0700 Subject: No subject In-Reply-To: References: Message-ID: <3C6205F2-6458-4E0C-8C10-7DFF909B689F@bloomcounty.org> On Apr 27, 2015, at 2:14 PM, Elizabeth Zwicky via NANOG wrote: > > http://postmaster.yahoo.com will allow you to contact the postmaster team for assistance. > I've reported this error already, but fixing it won't help you any; basically, the web page without the link is all Yahoo's willing to publicly say about that error message, you'll need to talk to postmaster for help debugging your particular situation. > Elizabeth ZwickyYahoo Mail > If one cares to read it, fixing the link typo(s) gets me redirected to this link, which does work and does appear to be ToS info: https://policies.yahoo.com/xw/en/yahoo/terms/product-atos/comms/index.htm -c From chaim.rieger at gmail.com Mon Apr 27 21:55:28 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 27 Apr 2015 14:55:28 -0700 Subject: (OT) cisco tacops Message-ID: <4959AE7B-D2BB-4393-A788-C2D49390286E@gmail.com> Seeking to make contact with somebody in Cisco Tacops please. Any help would be appreciated, not sales related, would like to lend a hand with current ops. From eric at ericheather.com Tue Apr 28 00:15:54 2015 From: eric at ericheather.com (Eric C. Miller) Date: Tue, 28 Apr 2015 00:15:54 +0000 Subject: Looking for a provider in Ecuador Message-ID: Hello, Does anyone have a recommendation for a provider who can service the west coast of Ecuador at speeds 100Mbps - 1Gbps? Thanks! Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 From lists.nanog at monmotha.net Tue Apr 28 00:17:00 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 27 Apr 2015 20:17:00 -0400 Subject: IPTV providers in IN/Chicago Message-ID: <553ED17C.6040000@monmotha.net> Anyone know of an IPTV provider/wholesaler who I could meet in Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? Direct solicitations are OK out-of-band. -- Brandon Martin From rubensk at gmail.com Tue Apr 28 00:32:15 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 27 Apr 2015 21:32:15 -0300 Subject: Looking for a provider in Ecuador In-Reply-To: References: Message-ID: Level 3 wholesale (former Global Crossing), Telef?nica Wholesale, Tata Communications(former Teleglobe) and LANautilus(TI/Sparkle). Possible local providers could be TelcoNet (private) or CNT (government-owned). Rubens On Mon, Apr 27, 2015 at 9:15 PM, Eric C. Miller wrote: > Hello, > > Does anyone have a recommendation for a provider who can service the west > coast of Ecuador at speeds 100Mbps - 1Gbps? > > Thanks! > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > From nanog at ics-il.net Tue Apr 28 00:54:54 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 27 Apr 2015 19:54:54 -0500 (CDT) Subject: IPTV providers in IN/Chicago In-Reply-To: <553ED17C.6040000@monmotha.net> Message-ID: <13922612.858.1430182486908.JavaMail.mhammett@ThunderFuck> I have these guys as contacts for that sort of service. It was reasonably priced. They even had a "when you approach 1k customers, you can move to this other system" option. Someone that has small guys in mind is rare. "Emily" < emily.call at mwt.net > Emily Call Midwest Video Solutions 608-634-7411 "Tom Barry" < barry at wins.net >, "Bob Hurtgen" < hurtgen at wins.net > http://www.midwestvideosolutions.com/ Let them know I sent you. Maybe I'll get some cookies for it at some point. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Brandon Martin" To: nanog at nanog.org Sent: Monday, April 27, 2015 7:17:00 PM Subject: IPTV providers in IN/Chicago Anyone know of an IPTV provider/wholesaler who I could meet in Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? Direct solicitations are OK out-of-band. -- Brandon Martin From rs at seastrom.com Tue Apr 28 01:08:50 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 27 Apr 2015 21:08:50 -0400 Subject: IPTV providers in IN/Chicago In-Reply-To: <553ED17C.6040000@monmotha.net> (Brandon Martin's message of "Mon, 27 Apr 2015 20:17:00 -0400") References: <553ED17C.6040000@monmotha.net> Message-ID: <86618hqct9.fsf@valhalla.seastrom.com> Brandon Martin writes: > Anyone know of an IPTV provider/wholesaler who I could meet in > Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? "IPTV" implies, or used to imply, multicast (or unicast, whichever, swap them with a few DCMs) MPEG2-TS feeds. If that's what you want, fine, but if it's not you might want to be a bit more specific. -r From listas at esds.com.br Tue Apr 28 01:12:01 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Mon, 27 Apr 2015 22:12:01 -0300 Subject: Looking for a provider in Ecuador In-Reply-To: References: Message-ID: Also Internexa: http://www.internexa.com/en-us/Pages/home.aspx -- Eduardo Schoedler 2015-04-27 21:32 GMT-03:00 Rubens Kuhl : > Level 3 wholesale (former Global Crossing), Telef?nica Wholesale, Tata > Communications(former Teleglobe) and LANautilus(TI/Sparkle). > Possible local providers could be TelcoNet (private) or CNT > (government-owned). > > > Rubens > > > > > > > > > > On Mon, Apr 27, 2015 at 9:15 PM, Eric C. Miller > wrote: > > > Hello, > > > > Does anyone have a recommendation for a provider who can service the west > > coast of Ecuador at speeds 100Mbps - 1Gbps? > > > > Thanks! > > > > > > > > Eric Miller, CCNP > > Network Engineering Consultant > > (407) 257-5115 > > > > > > > > > -- Eduardo Schoedler From nanog at ics-il.net Tue Apr 28 01:27:02 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 27 Apr 2015 20:27:02 -0500 (CDT) Subject: Looking for a provider in Ecuador In-Reply-To: Message-ID: <9094200.930.1430184408888.JavaMail.mhammett@ThunderFuck> Did you check the map listings over at Telecom Ramblings? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Eric C. Miller" To: "NANOG (nanog at nanog.org)" Sent: Monday, April 27, 2015 7:15:54 PM Subject: Looking for a provider in Ecuador Hello, Does anyone have a recommendation for a provider who can service the west coast of Ecuador at speeds 100Mbps - 1Gbps? Thanks! Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 From lists.nanog at monmotha.net Tue Apr 28 01:33:00 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 27 Apr 2015 21:33:00 -0400 Subject: IPTV providers in IN/Chicago In-Reply-To: <86618hqct9.fsf@valhalla.seastrom.com> References: <553ED17C.6040000@monmotha.net> <86618hqct9.fsf@valhalla.seastrom.com> Message-ID: <553EE34C.4040500@monmotha.net> On 04/27/2015 09:08 PM, Rob Seastrom wrote: > > Brandon Martin writes: > >> Anyone know of an IPTV provider/wholesaler who I could meet in >> Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? > > "IPTV" implies, or used to imply, multicast (or unicast, whichever, > swap them with a few DCMs) MPEG2-TS feeds. If that's what you want, > fine, but if it's not you might want to be a bit more specific. Yes, I should perhaps clarify. I'm ideally looking for a provider targeting smaller providers/startups that has some means at their disposal to deliver conventional cable-like TV services over my IP-speaking network (could be a separately routed network or "in-band") to my customers either on a re-branded or co-billed type basis using IP-speaking, Ethernet-connected (or 802.11) STBs either supplied by me to provider specifications or by the aforementioned provider. The network in question is IPv4 multicast capable and could somewhat trivially (I think) be IPv6 multicast capable (it is definitely IPv6 unicast capable). I am not looking for bulk feeds of content for me to redistribute using conventional infrastructure as I don't have any at this point. As the network this would be going into is greenfield, I have little desire to run a conventional RF network overlay, though it isn't completely out of the question. -- Brandon Martin From rs at seastrom.com Tue Apr 28 02:02:14 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 27 Apr 2015 22:02:14 -0400 Subject: vendor spam OTD Message-ID: Anyone else been spammed by Andy Boland at "Function5 Technology Group"? -r From list at satchell.net Tue Apr 28 02:21:59 2015 From: list at satchell.net (Stephen Satchell) Date: Mon, 27 Apr 2015 19:21:59 -0700 Subject: vendor spam OTD In-Reply-To: References: Message-ID: <553EEEC7.3040306@satchell.net> On 04/27/2015 07:02 PM, Rob Seastrom wrote: > Anyone else been spammed by Andy Boland at "Function5 Technology > Group"? I'm not sure it's fair to class the e-mail as "spam", but he is one persistent fellow. My company made list for some of the equipment we retired for purchase, and his Cisco buyer never got back to me. So the excess inventory is being offered to another reseller. There does seem to be a disconnect between the front office and the back office. That could be part of the reason for the mailout repetition. From rs at seastrom.com Tue Apr 28 02:59:14 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 27 Apr 2015 22:59:14 -0400 Subject: vendor spam OTD In-Reply-To: <553EEEC7.3040306@satchell.net> (Stephen Satchell's message of "Mon, 27 Apr 2015 19:21:59 -0700") References: <553EEEC7.3040306@satchell.net> Message-ID: <868udd9cvx.fsf@valhalla.seastrom.com> Stephen Satchell writes: > On 04/27/2015 07:02 PM, Rob Seastrom wrote: >> Anyone else been spammed by Andy Boland at "Function5 Technology >> Group"? > > I'm not sure it's fair to class the e-mail as "spam", but he is one > persistent fellow. My company made list for some of the equipment we > retired for purchase, and his Cisco buyer never got back to me. So > the excess inventory is being offered to another reseller. Well, it's unsolicited email from a company who I've never had any commercial relationship with. If it's not fair to class it as spam, what is it fair to class it as? I reported it to the appropriate abuse folks. -r From ops.lists at gmail.com Tue Apr 28 03:19:40 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 28 Apr 2015 08:49:40 +0530 Subject: vendor spam OTD In-Reply-To: <868udd9cvx.fsf@valhalla.seastrom.com> References: <553EEEC7.3040306@satchell.net> <868udd9cvx.fsf@valhalla.seastrom.com> Message-ID: <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> Given we?re going down this ?what is spam? rathole again, spam is generally defined as unsolicited BULK email As the email appears to be one to one, though a remarkably persistent one to one, I would suggest procmail, unless you know he?s harvested nanog and is sending the same offer mail merged to a bunch of operators. ?srs > On 28-Apr-2015, at 8:29 am, Rob Seastrom wrote: > >> On 04/27/2015 07:02 PM, Rob Seastrom wrote: >>> Anyone else been spammed by Andy Boland at "Function5 Technology >>> Group"? >> >> I'm not sure it's fair to class the e-mail as "spam", but he is one >> persistent fellow. My company made list for some of the equipment we >> retired for purchase, and his Cisco buyer never got back to me. So >> the excess inventory is being offered to another reseller. > > Well, it's unsolicited email from a company who I've never had any > commercial relationship with. If it's not fair to class it as spam, > what is it fair to class it as? > > I reported it to the appropriate abuse folks. From rs at seastrom.com Tue Apr 28 03:30:28 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 27 Apr 2015 23:30:28 -0400 Subject: vendor spam OTD In-Reply-To: <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> (Suresh Ramasubramanian's message of "Tue, 28 Apr 2015 08:49:40 +0530") References: <553EEEC7.3040306@satchell.net> <868udd9cvx.fsf@valhalla.seastrom.com> <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> Message-ID: <86k2wx3p63.fsf@valhalla.seastrom.com> Suresh Ramasubramanian writes: > Given we?(TM)re going down this ?oewhat is spam?Y\.. rathole again, spam is > generally defined as unsolicited BULK email Correct, and moreover it's generally conceded that having a perl script insert "Dear Robert" at the beginning of the email message is insufficient for it to not be "bulk", particularly if it's general and has nothing to do with any kind of specialized knowledge of your company beyond the fact that you have an email address. This sure looks like bulk mail merge to me. > As the email appears to be one to one, Have you gotten a copy too, or are you just idly speculating here? > though a remarkably persistent one to one, I would suggest procmail, > unless you know he?(TM)s harvested nanog and is sending the same > offer mail merged to a bunch of operators. Gee, it's almost as if by posing a question to nanog@ like "Has anyone else received spam from X", I might be trying to ascertain an answer to precisely that question. -r From list at satchell.net Tue Apr 28 03:43:20 2015 From: list at satchell.net (Stephen Satchell) Date: Mon, 27 Apr 2015 20:43:20 -0700 Subject: vendor spam OTD In-Reply-To: <86k2wx3p63.fsf@valhalla.seastrom.com> References: <553EEEC7.3040306@satchell.net> <868udd9cvx.fsf@valhalla.seastrom.com> <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> <86k2wx3p63.fsf@valhalla.seastrom.com> Message-ID: <553F01D8.5040902@satchell.net> On 04/27/2015 08:30 PM, Rob Seastrom wrote: > > Suresh Ramasubramanian writes: > >> though a remarkably persistent one to one, I would suggest procmail, >> unless you know he?(TM)s harvested nanog and is sending the same >> offer mail merged to a bunch of operators. > > Gee, it's almost as if by posing a question to nanog@ like "Has anyone > else received spam from X", I might be trying to ascertain an answer > to precisely that question. Key data point: If the mail was being spammed to NANOG, I would have received that mail at this address, one of several that I use specifically for public mailing lists. The mail I did receive (multiple e-mail letters, by the way, some of them obvious form letters) came to my primary work address, which had been used in the past to contact that company to buy equipment. So my answer to your precise question would be "no". From ops.lists at gmail.com Tue Apr 28 05:03:26 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 28 Apr 2015 10:33:26 +0530 Subject: vendor spam OTD In-Reply-To: <86k2wx3p63.fsf@valhalla.seastrom.com> References: <553EEEC7.3040306@satchell.net> <868udd9cvx.fsf@valhalla.seastrom.com> <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> <86k2wx3p63.fsf@valhalla.seastrom.com> Message-ID: <3303C73D-1BFB-443F-8FA0-477D35553055@gmail.com> Having seen my share of pesky vendors - though not this one .. Yeah idle speculation it is. Informed idle I hope. :) --srs > On 28-Apr-2015, at 9:00 am, Rob Seastrom wrote: > > Have you gotten a copy too, or are you just idly speculating here? From lorell at hathcock.org Tue Apr 28 05:28:05 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 28 Apr 2015 00:28:05 -0500 Subject: OSP multi-fiber Network-to Network Interface - Recommendations requested In-Reply-To: <553E6ADD.9070703@xkl.com> References: <005001d07dda$af44ab40$0dce01c0$@solstarnetwork.com> <00a101d07dde$c3dfa510$4b9eef30$@solstarnetwork.com> <00b801d07de0$07514fa0$15f3eee0$@solstarnetwork.com> <00d801d07de5$7a7dc530$6f794f90$@solstarnetwork.com> <00f201d07de5$c56b22e0$504168a0$@solstarnetwork.com> <002501d07f6f$3185bcd0$94913670$@solstarnetwork.com> <003d01d07f6f$f648fbe0$e2daf3a0$@hathcock.org> <604c01d08106$907618f0$b1624ad0$@hathcock.org> <553E6ADD.9070703@xkl.com> Message-ID: <008801d08174$1b3f0a10$51bd1e30$@hathcock.org> Roy: Thanks. I seek information from people that have already done this kind of thing before. Admittedly, this may be lower down the OSI model than many of them go, but there are some lurkers among the bunch. So, re-phrased, I would ask "What are industry standard, best practices when designing an OSP multi-fiber NNI?" Thanks, Lorell From: Roy Hirst [mailto:rhirst at xkl.com] Sent: Monday, April 27, 2015 11:59 AM To: Lorell Hathcock Subject: Re: OSP multi-fiber Network-to Network Interface - Recommendations requested Lorell The silence of the experts is indeed rare. At my reading, though, it was not very clear what you were asking the alias for. You have some perfectly reasonable questions re negotiation, and a project to design presumably soon. Sounds exciting. What did you want to ask, I may be able to help. Roy Roy Hirst | 425-556-5773 | XKL LLC | xkl.com On 4/27/15 9:23 AM, Lorell Hathcock wrote: It's rare that NANOG is speechless on an issue. Have I stumped the experts? :) -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of lorell at hathcock.org Sent: Saturday, April 25, 2015 10:53 AM To: nanog at nanog.org Subject: FW: OSP multi-fiber Network-to Network Interface - Recommendations requested NANOG: The purpose of this email is to discuss information, standards, recommendations, et cetera about interconnect solutions considering the parameters contained herein. We believe the correct term is a multi-fiber network to network interface. My firm has made an IRU agreement with a municipality to use each other's OSP fibers. In most of the City's OSP, they have a 96 strand count fiber with eight buffer tubes (each buffer tube having 12 fibers). They have dedicated the black buffer tube for our use (again, 12 strands) We have yet to build any OSP fiber plant. When we do and when we interconnect with the City's fiber, we will extend a minimum of 96 fibers. When our plant extends in public right of way, we will interconnect 84 strands (maybe 7 buffer tubes with 12 strands each) of our fiber to the City and keep a minimum of one for our ourselves. It is highly likely that we will pull a much higher fiber count cable to give ourselves additional fibers beyond just 12 strands. On certain projects, when outside City limits and/or on private right of way within City limits, we are required to give them 12 strands of fiber. When we interconnect with their fiber, we must consider the following: 1. How many strands with which will we interconnect? a. If we are interconnecting in the middle of a City span, we must think about interconnecting with North-bound and South-bound fibers. (12 fibers for us going in two directions and as many as 84 fibers for them going in two directions). b. If we are connecting at the end of a City span, we must consider just the South-bound fibers and the interconnection between our OSP. 2. Available real estate for placing vaults, pedestals, FDHs, et cetera. 3. The likelihood of damage from accidents on the adjacent roads. 4. The likelihood of water filling up underground vaults. 5. dB loss resulting from splices, interconnects, et cetera. 6. Scalability and future growth. 7. Other considerations? In our discussions with the City, we have contemplated a dual cabinet system where we ask the following questions to determine how to load those cabinets. 1. Where is the proposed interconnect in terms of real estate and adjacent traffic? (Find a safe place with enough real estate). 2. How many fibers will interconnect from our network to theirs? (either 12 or 84 for each direction we take from the site - most likely just one direction). 3. How many fibers will interconnect from their network to ours? (just 12 at most, but likely in at least two directions - because we are cutting into their fiber mid-span) Once those questions are answered, then we can design and build the cabinets. Also, we want to be cost effective in this design. Thanks in advance for a push in the right direction. Sincerely, Lorell Hathcock Chief Technology Officer SolStar Network, LLC The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error, please e-mail the sender at the above e-mail address. From frnkblk at iname.com Tue Apr 28 05:35:43 2015 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 28 Apr 2015 00:35:43 -0500 Subject: IPTV providers in IN/Chicago In-Reply-To: <553ED17C.6040000@monmotha.net> References: <553ED17C.6040000@monmotha.net> Message-ID: <001a01d08175$2d472b60$87d58220$@iname.com> I believe Vubiquity (http://www.vubiquity.com/product-portfolio/livevu/) does, as well as Comcast HITS (http://www.comcastwholesale.com/products-services/mpeg-2-content-delivery/mpeg-2-delivery-content-providers). Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Monday, April 27, 2015 7:17 PM To: nanog at nanog.org Subject: IPTV providers in IN/Chicago Anyone know of an IPTV provider/wholesaler who I could meet in Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? Direct solicitations are OK out-of-band. -- Brandon Martin From mark.tinka at seacom.mu Tue Apr 28 05:36:07 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 28 Apr 2015 07:36:07 +0200 Subject: IPTV providers in IN/Chicago In-Reply-To: <553EE34C.4040500@monmotha.net> References: <553ED17C.6040000@monmotha.net> <86618hqct9.fsf@valhalla.seastrom.com> <553EE34C.4040500@monmotha.net> Message-ID: <553F1C47.6070003@seacom.mu> On 28/Apr/15 03:33, Brandon Martin wrote: > > > I am not looking for bulk feeds of content for me to redistribute > using conventional infrastructure as I don't have any at this point. > As the network this would be going into is greenfield, I have little > desire to run a conventional RF network overlay, though it isn't > completely out of the question. Certainly, if you've got a Multicast-capable greenfield IP network, I'd suggest focusing energies on that. In case you have not yet settled on a technology, I'd suggest going for NG-MVPN. You should be able to get decent IPv6 Multicast support for it as well. Mark. From m4rtntns at gmail.com Tue Apr 28 09:32:05 2015 From: m4rtntns at gmail.com (Martin T) Date: Tue, 28 Apr 2015 12:32:05 +0300 Subject: common checks performed when passing on an IPv4 PA allocation from one end-customer to another In-Reply-To: References: Message-ID: Hi, as far as I know, some large US Internet companies like Google, Facebook or Amazon restrict access to some services for certain regions like Crimea or countries like Iran or North Korea. Do they rely on services like MaxMind? Or do they use some other method to check the geographical location of IP address? If yes, then is there an API to check if an address is allowed to use Google, Facebook, etc services or not? thanks, Martin On 9/17/13, Martin T wrote: > Hi, > > when one end-customer has been using for example /24 IPv4 allocation > for a while and returns this(for example changes an ISP) to LIR, then > are there some good practices before handing out this same /24 to a > new customer? I guess LIR should: > > 1) remove all the DNS PTR records, classless of classful delegations > 2) check if some of the IP addresses are in DNSBL(maybe the previous > customer was a spammer). Example with 93.184.216.0/24: > > $ for ip in {0..255}.216.184.93;\ >> do for addr in \ >> cbl.abuseat.org \ >> dnsbl.inps.de \ >> no-more-funn.moensted.dk \ >> dnsbl.sorbs.net \ >> bl.spamcannibal.org \ >> bl.spamcop.net \ >> psbl.surriel.com \ >> dnsrbl.swinog.ch; \ >> do dig @8.8.8.8 "$ip"."$addr" +short | grep -q "^127.0.0." && \ >> echo "DNSBL-Alarm: $ip is listed on $addr"; done; done > $ > > > Anything else? > > > regards, > Martin > From colinj at gt86car.org.uk Tue Apr 28 10:42:34 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 28 Apr 2015 11:42:34 +0100 Subject: common checks performed when passing on an IPv4 PA allocation from one end-customer to another In-Reply-To: References: Message-ID: <9D5C3AF1-B726-4344-912B-0AFF5849AE9B@gt86car.org.uk> > On 28 Apr 2015, at 10:32, Martin T wrote: > > Hi, > > as far as I know, some large US Internet companies like Google, > Facebook or Amazon restrict access to some services for certain > regions like Crimea or countries like Iran or North Korea. Do they > rely on services like MaxMind? Or do they use some other method to > check the geographical location of IP address? If yes, then is there > an API to check if an address is allowed to use Google, Facebook, etc > services or not? > you could use ripe atlas selecting nodes in countries you require and destination facbook/google/amazon servers and check results Colin From rs at seastrom.com Tue Apr 28 10:52:30 2015 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 28 Apr 2015 06:52:30 -0400 Subject: IPTV providers in IN/Chicago In-Reply-To: <553EE34C.4040500@monmotha.net> (Brandon Martin's message of "Mon, 27 Apr 2015 21:33:00 -0400") References: <553ED17C.6040000@monmotha.net> <86618hqct9.fsf@valhalla.seastrom.com> <553EE34C.4040500@monmotha.net> Message-ID: <86zj5sfrtd.fsf@valhalla.seastrom.com> Brandon Martin writes: > The network in > question is IPv4 multicast capable and could somewhat trivially (I > think) be IPv6 multicast capable (it is definitely IPv6 unicast > capable). You'd be surprised how many edge devices (unfortunately) support IPv6 multicast only to the degree necessary to implement neighbor discovery. Lean on your vendor. And for the love of God, do SSM not ASM (requires igmpv3 or mld2). I can expound on the problem space off-list if you like. -r From mark.tinka at seacom.mu Tue Apr 28 11:15:07 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 28 Apr 2015 13:15:07 +0200 Subject: IPTV providers in IN/Chicago In-Reply-To: <86zj5sfrtd.fsf@valhalla.seastrom.com> References: <553ED17C.6040000@monmotha.net> <86618hqct9.fsf@valhalla.seastrom.com> <553EE34C.4040500@monmotha.net> <86zj5sfrtd.fsf@valhalla.seastrom.com> Message-ID: <553F6BBB.1030208@seacom.mu> On 28/Apr/15 12:52, Rob Seastrom wrote: > > > And for the love of God, do SSM not ASM (requires igmpv3 or mld2). I > can expound on the problem space off-list if you like. Agree that SSM will scale better in the long run. RP's are a thing of the past. In case your STB's don't support IGMPv3 (which is very possible), ensure your router supports SSM Mapping (any decent vendor has this) and run IGMPv3 on the port facing the STB. If your STB's support IGMPv3, then you're in SSM heaven, and ASM can go where RIP now lives. Mark. From nanog at ics-il.net Tue Apr 28 12:05:54 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Apr 2015 07:05:54 -0500 (CDT) Subject: IPTV providers in IN/Chicago In-Reply-To: <001a01d08175$2d472b60$87d58220$@iname.com> Message-ID: <8474125.1516.1430222741898.JavaMail.mhammett@ThunderFuck> I'm not sure why or that Comcast would enable competition. Maybe I'm wrong. Then again, maybe Brandon isn't in a Comcast served area. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Frank Bulk" To: "Brandon Martin" , nanog at nanog.org Sent: Tuesday, April 28, 2015 12:35:43 AM Subject: RE: IPTV providers in IN/Chicago I believe Vubiquity (http://www.vubiquity.com/product-portfolio/livevu/) does, as well as Comcast HITS (http://www.comcastwholesale.com/products-services/mpeg-2-content-delivery/mpeg-2-delivery-content-providers). Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Monday, April 27, 2015 7:17 PM To: nanog at nanog.org Subject: IPTV providers in IN/Chicago Anyone know of an IPTV provider/wholesaler who I could meet in Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? Direct solicitations are OK out-of-band. -- Brandon Martin From nanog at ics-il.net Tue Apr 28 12:07:59 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 28 Apr 2015 07:07:59 -0500 (CDT) Subject: IPTV providers in IN/Chicago In-Reply-To: <86618hqct9.fsf@valhalla.seastrom.com> Message-ID: <3775047.1526.1430222868168.JavaMail.mhammett@ThunderFuck> I suspect it's more of a choice of what's available than what he wants. If you're building from the ground-up, you can be picky, but if you're going light-weight (as little head-end as possible), you're stuck with whatever (good or bad) your wholesale partner uses. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Rob Seastrom" To: "Brandon Martin" Cc: nanog at nanog.org Sent: Monday, April 27, 2015 8:08:50 PM Subject: Re: IPTV providers in IN/Chicago Brandon Martin writes: > Anyone know of an IPTV provider/wholesaler who I could meet in > Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? "IPTV" implies, or used to imply, multicast (or unicast, whichever, swap them with a few DCMs) MPEG2-TS feeds. If that's what you want, fine, but if it's not you might want to be a bit more specific. -r From m4rtntns at gmail.com Tue Apr 28 13:23:53 2015 From: m4rtntns at gmail.com (Martin T) Date: Tue, 28 Apr 2015 16:23:53 +0300 Subject: common checks performed when passing on an IPv4 PA allocation from one end-customer to another In-Reply-To: <9D5C3AF1-B726-4344-912B-0AFF5849AE9B@gt86car.org.uk> References: <9D5C3AF1-B726-4344-912B-0AFF5849AE9B@gt86car.org.uk> Message-ID: Colin, this is a good idea, but in this case the network I am interested in does not have a RIPE Atlas probe. regards, Martin On 4/28/15, Colin Johnston wrote: > > > >> On 28 Apr 2015, at 10:32, Martin T wrote: >> >> Hi, >> >> as far as I know, some large US Internet companies like Google, >> Facebook or Amazon restrict access to some services for certain >> regions like Crimea or countries like Iran or North Korea. Do they >> rely on services like MaxMind? Or do they use some other method to >> check the geographical location of IP address? If yes, then is there >> an API to check if an address is allowed to use Google, Facebook, etc >> services or not? >> > > you could use ripe atlas selecting nodes in countries you require and > destination facbook/google/amazon servers and check results > > Colin > > From bzs at world.std.com Tue Apr 28 16:39:12 2015 From: bzs at world.std.com (Barry Shein) Date: Tue, 28 Apr 2015 12:39:12 -0400 Subject: vendor spam OTD In-Reply-To: <86k2wx3p63.fsf@valhalla.seastrom.com> References: <553EEEC7.3040306@satchell.net> <868udd9cvx.fsf@valhalla.seastrom.com> <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> <86k2wx3p63.fsf@valhalla.seastrom.com> Message-ID: <21823.47024.673166.569627@world.std.com> As more and more "legitimate" companies exploit email as a free resource I think we're going to need to broaden the definition of spam. Email is already on the verge of useless. And a lot of that is just pitches from orgs one would, under old definitions, argue are not spam. So the question is whether spam, and we can quibble the word, only email which is UBE or is it email which is rendering the technology useless? I think we've mistakenly via UBE definitions given out free licenses to dump pollution in our drinking water. If you don't think that's a problem right now that's ok I'll be back in a year and two. I believe hearts and minds will change towards my way of thinking about this, it's just a matter of pain threshold. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bill at herrin.us Tue Apr 28 18:11:37 2015 From: bill at herrin.us (William Herrin) Date: Tue, 28 Apr 2015 14:11:37 -0400 Subject: vendor spam OTD In-Reply-To: References: Message-ID: On Mon, Apr 27, 2015 at 10:02 PM, Rob Seastrom wrote: > Anyone else been spammed by Andy Boland at "Function5 Technology > Group"? No, but I feel your pain. Two jokers have been trying since July to recruit me as an Aflac salesman. Hear from them every few weeks. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jfmezei_nanog at vaxination.ca Tue Apr 28 21:24:39 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 28 Apr 2015 17:24:39 -0400 Subject: ADSL Line Extenders Message-ID: <553FFA97.8030405@vaxination.ca> A friend on a rural DSl association asked about ADSL line extenders. A search on Google yields many products dating back to the days of ADSL-1 advertising 1mbps profiles, but a few seem more recent and support ADSL2+ (not sure if any support VDSL2). Are these thing out of date and no longer deployed ? Were they ever effective, or just vapourware that didn't really improve things ? Do any Telcos still deploy them ? Anyone know of deployments in Canada ? I just need a reality check on those devices. jf From lists.nanog at monmotha.net Tue Apr 28 21:34:57 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 28 Apr 2015 17:34:57 -0400 Subject: IPTV providers in IN/Chicago In-Reply-To: <86zj5sfrtd.fsf@valhalla.seastrom.com> References: <553ED17C.6040000@monmotha.net> <86618hqct9.fsf@valhalla.seastrom.com> <553EE34C.4040500@monmotha.net> <86zj5sfrtd.fsf@valhalla.seastrom.com> Message-ID: <553FFD01.4060800@monmotha.net> On 04/28/2015 06:52 AM, Rob Seastrom wrote: > You'd be surprised how many edge devices (unfortunately) support IPv6 > multicast only to the degree necessary to implement neighbor > discovery. Lean on your vendor. Yep, I know routers will do it in the latest software, which I cannot quite run (needs a modest hardware upgrade), but I'm still playing around with the edge devices which is why I say "I think". > And for the love of God, do SSM not ASM (requires igmpv3 or mld2). I > can expound on the problem space off-list if you like. My routers will do SSM on IPv4 and IPv6, and they will also do SSM mapping, but I do need to check on the access pieces which prefer to be the customer's L3 termination (they CAN hand off L2 to another router, but my preferred routers are not designed for bulk BRAS use). The access gear is somewhat in the "price point" realm and, while surprisingly capable, is not particularly well documented. This was definitely on my checklist before committing to any multicast solution, especially IPv6-based, but I would like to hear your thoughts if you don't mind (via unicast or multicast as you deem appropriate). I've not done a ton of IPv4 multicast and basically no IPv6 multicast in the past. Many vendors are unfortunately just starting to catch up with mainstream IPv6 support in many cases...only took a decade (a frequent lament on here, I know), and multicast is still lagging in that department in many cases. -- Brandon Martin From rsk at gsp.org Tue Apr 28 21:52:10 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 28 Apr 2015 17:52:10 -0400 Subject: vendor spam OTD In-Reply-To: <21823.47024.673166.569627@world.std.com> References: <553EEEC7.3040306@satchell.net> <868udd9cvx.fsf@valhalla.seastrom.com> <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> <86k2wx3p63.fsf@valhalla.seastrom.com> <21823.47024.673166.569627@world.std.com> Message-ID: <20150428215209.GA4842@gsp.org> On Tue, Apr 28, 2015 at 12:39:12PM -0400, Barry Shein wrote: > As more and more "legitimate" companies exploit email as a free > resource I think we're going to need to broaden the definition of > spam. Absolutely not. The canonical -- and only correct -- definition is UBE, as Suresh pointed out. It has served us well for decades and it continues to do so. HOWEVER -- there are other forms of abuse carried by SMTP and we have names for some of those. If it turns out that yet one more form of abuse is becoming a problem and thus we need a term to refer to it, we can and should come up with one. It's also worth noting that some instances of abuse can be described by more than one term. Abusers, unfortunately, can be quite creative and prolific. ---rsk From Valdis.Kletnieks at vt.edu Tue Apr 28 22:09:23 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 28 Apr 2015 18:09:23 -0400 Subject: vendor spam OTD In-Reply-To: Your message of "Tue, 28 Apr 2015 12:39:12 -0400." <21823.47024.673166.569627@world.std.com> References: <553EEEC7.3040306@satchell.net> <868udd9cvx.fsf@valhalla.seastrom.com> <2A53DE06-6583-44F5-87A8-98E3E997AB91@gmail.com> <86k2wx3p63.fsf@valhalla.seastrom.com> <21823.47024.673166.569627@world.std.com> Message-ID: <31000.1430258963@turing-police.cc.vt.edu> On Tue, 28 Apr 2015 12:39:12 -0400, Barry Shein said: > Email is already on the verge of useless. And a lot of that is just > pitches from orgs one would, under old definitions, argue are not > spam. That prompts two questions: (a) How do you define "useless" and (b) what do you advocate as a replacement? (You want to stress-test your MUA, subscribe to the linux-kernel mailing list, which runs anywhere from 700 to 1100 posts. Per day. And the list is well-run, we see single-digits of spam per week.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mpalmer at hezmatt.org Tue Apr 28 22:49:56 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 29 Apr 2015 08:49:56 +1000 Subject: ADSL Line Extenders In-Reply-To: <553FFA97.8030405@vaxination.ca> References: <553FFA97.8030405@vaxination.ca> Message-ID: <20150428224956.GR22608@hezmatt.org> On Tue, Apr 28, 2015 at 05:24:39PM -0400, Jean-Francois Mezei wrote: > A search on Google yields many products dating back to the days of > ADSL-1 advertising 1mbps profiles, but a few seem more recent and > support ADSL2+ (not sure if any support VDSL2). > > Are these thing out of date and no longer deployed ? Were they ever > effective, or just vapourware that didn't really improve things ? Wikipedia[1] suggests they're a real thing, and have real-world uses. I can imagine that a big disincentive to installing them would be powering them, although line power would probably be enough for one or two hops. Getting access to the line in the right places to install them might be a challenge, too (or at least be somewhat expensive). No doubt telcos also don't want to install them because they can make a whole lot more money for less effort by forcing customers onto wireless. - Matt [1] https://en.wikipedia.org/wiki/ADSL_loop_extender From jeff at ting.com Tue Apr 28 00:30:41 2015 From: jeff at ting.com (Jeff Cornejo) Date: Mon, 27 Apr 2015 20:30:41 -0400 Subject: Looking for a provider in Ecuador In-Reply-To: References: Message-ID: <79D73C9B-5822-4DC0-B38C-935095E89210@ting.com> Punto Net may be able to help. They operate a fiber-based network in different areas of the country. http://www.puntonet.ec Jeff Jeff Cornejo jeff at ting.com ting.com/internet that makes sense. > On Apr 27, 2015, at 8:15 PM, Eric C. Miller wrote: > > Hello, > > Does anyone have a recommendation for a provider who can service the west coast of Ecuador at speeds 100Mbps - 1Gbps? > > Thanks! > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From colton.conor at gmail.com Wed Apr 29 00:52:38 2015 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 28 Apr 2015 19:52:38 -0500 Subject: ADSL Line Extenders In-Reply-To: <553FFA97.8030405@vaxination.ca> References: <553FFA97.8030405@vaxination.ca> Message-ID: I know a couple of LECs that use these with success: http://actelis.com/actelis-products/broadband-amplifiers/ On Tue, Apr 28, 2015 at 4:24 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > A friend on a rural DSl association asked about ADSL line extenders. > > A search on Google yields many products dating back to the days of > ADSL-1 advertising 1mbps profiles, but a few seem more recent and > support ADSL2+ (not sure if any support VDSL2). > > Are these thing out of date and no longer deployed ? Were they ever > effective, or just vapourware that didn't really improve things ? > > > Do any Telcos still deploy them ? Anyone know of deployments in Canada ? > > I just need a reality check on those devices. > > jf > From josh at spitwspots.com Wed Apr 29 02:27:30 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Tue, 28 Apr 2015 18:27:30 -0800 Subject: Current state / use of OSPF-TE Message-ID: <55404192.2030507@spitwspots.com> What is the current state/use of OSPF-TE? Something you don't hear about much, for sure. Is this something that wasn't designed well, supported well, or was it just superseded by label based switching by the vast Telco market? Any info would be appreciated. Thanks -- Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com From mark.tinka at seacom.mu Wed Apr 29 06:59:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 29 Apr 2015 08:59:13 +0200 Subject: IPTV providers in IN/Chicago In-Reply-To: <553FFD01.4060800@monmotha.net> References: <553ED17C.6040000@monmotha.net> <86618hqct9.fsf@valhalla.seastrom.com> <553EE34C.4040500@monmotha.net> <86zj5sfrtd.fsf@valhalla.seastrom.com> <553FFD01.4060800@monmotha.net> Message-ID: <55408141.5050602@seacom.mu> On 28/Apr/15 23:34, Brandon Martin wrote: > > > My routers will do SSM on IPv4 and IPv6, and they will also do SSM > mapping, but I do need to check on the access pieces which prefer to > be the customer's L3 termination (they CAN hand off L2 to another > router, but my preferred routers are not designed for bulk BRAS use). > The access gear is somewhat in the "price point" realm and, while > surprisingly capable, is not particularly well documented. This was > definitely on my checklist before committing to any multicast > solution, especially IPv6-based, but I would like to hear your > thoughts if you don't mind (via unicast or multicast as you deem > appropriate). I've not done a ton of IPv4 multicast and basically no > IPv6 multicast in the past. Many vendors are unfortunately just > starting to catch up with mainstream IPv6 support in many cases...only > took a decade (a frequent lament on here, I know), and multicast is > still lagging in that department in many cases. You can have multiple BRAS topologies running at the same time. You can terminate Internet access on one BRAS and IPTv on another. This lends itself well to centralized BRAS topologies, although it can also work in distributed models too. Depends on how much hardware you have. Mark. From sthaug at nethelp.no Wed Apr 29 07:03:14 2015 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 29 Apr 2015 09:03:14 +0200 (CEST) Subject: Current state / use of OSPF-TE In-Reply-To: <55404192.2030507@spitwspots.com> References: <55404192.2030507@spitwspots.com> Message-ID: <20150429.090314.74690940.sthaug@nethelp.no> > What is the current state/use of OSPF-TE? > > Something you don't hear about much, for sure. Is this something that > wasn't designed well, supported well, or was it just superseded by label > based switching by the vast Telco market? I assume you mean RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2"? This would be used by providers running MPLS, RSVP-TE and using OSPF as the IGP. As far as I can see it is supported by all major vendors. The reason you don't hear all that much about it is probably that a significant number of providers running MPLS and RSVP-TE use IS-IS as their IGP (we do). Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mark.tinka at seacom.mu Wed Apr 29 07:16:17 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 29 Apr 2015 09:16:17 +0200 Subject: Current state / use of OSPF-TE In-Reply-To: <20150429.090314.74690940.sthaug@nethelp.no> References: <55404192.2030507@spitwspots.com> <20150429.090314.74690940.sthaug@nethelp.no> Message-ID: <55408541.1020500@seacom.mu> On 29/Apr/15 09:03, sthaug at nethelp.no wrote: > I assume you mean RFC 3630 "Traffic Engineering (TE) Extensions to > OSPF Version 2"? This would be used by providers running MPLS, RSVP-TE > and using OSPF as the IGP. > > As far as I can see it is supported by all major vendors. The reason > you don't hear all that much about it is probably that a significant > number of providers running MPLS and RSVP-TE use IS-IS as their IGP > (we do). Assuming the OP is referring to RFC 3630, I suppose you wouldn't hear much about IS-IS either in this regard, since the TE extensions to IS-IS and OSPF are not the final product. The final product would be MPLS-TE itself. IS-IS and OSPF are just a ubiquitous way to get the TE information across the backbone. Mark. From khelms at zcorum.com Wed Apr 29 12:09:31 2015 From: khelms at zcorum.com (Scott Helms) Date: Wed, 29 Apr 2015 08:09:31 -0400 Subject: ADSL Line Extenders In-Reply-To: <553FFA97.8030405@vaxination.ca> References: <553FFA97.8030405@vaxination.ca> Message-ID: They're certainly real, still in use, and deployed world wide but most commonly in rural areas. They aren't particularly cost effective for most scenarios, but cheaper than hanging even a mini-DSLAM to service 1-2 customers that are too far away from a cabinet. Installing them is a pain and keeping them running long term is an even bigger pain. Certain models don't work well with specific DSLAMs and/or in specific plant combinations so testing with your DSLAMs, modems, and in your plant is a must. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Apr 28, 2015 at 5:24 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > A friend on a rural DSl association asked about ADSL line extenders. > > A search on Google yields many products dating back to the days of > ADSL-1 advertising 1mbps profiles, but a few seem more recent and > support ADSL2+ (not sure if any support VDSL2). > > Are these thing out of date and no longer deployed ? Were they ever > effective, or just vapourware that didn't really improve things ? > > > Do any Telcos still deploy them ? Anyone know of deployments in Canada ? > > I just need a reality check on those devices. > > jf > From Steve.Coker at flydenver.com Wed Apr 29 12:20:52 2015 From: Steve.Coker at flydenver.com (Coker, Steve - DIA) Date: Wed, 29 Apr 2015 12:20:52 +0000 Subject: ADSL Line Extenders In-Reply-To: References: <553FFA97.8030405@vaxination.ca>, Message-ID: <6AC2A935-27D1-4FEA-A834-B02423AECB71@flydenver.com> You can get adtran 1248b's that run ADSL 2+ for less than 2k still. Then get Cisco 887s as end points. That's what I run. 8 meg at 3 miles or so. I am not sure if they make a VDSL or not, but would check them out. Steve Sent from my iPhone > On Apr 29, 2015, at 7:11 AM, Scott Helms wrote: > > They're certainly real, still in use, and deployed world wide but most > commonly in rural areas. They aren't particularly cost effective for most > scenarios, but cheaper than hanging even a mini-DSLAM to service 1-2 > customers that are too far away from a cabinet. Installing them is a pain > and keeping them running long term is an even bigger pain. Certain models > don't work well with specific DSLAMs and/or in specific plant combinations > so testing with your DSLAMs, modems, and in your plant is a must. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Tue, Apr 28, 2015 at 5:24 PM, Jean-Francois Mezei < > jfmezei_nanog at vaxination.ca> wrote: > >> >> A friend on a rural DSl association asked about ADSL line extenders. >> >> A search on Google yields many products dating back to the days of >> ADSL-1 advertising 1mbps profiles, but a few seem more recent and >> support ADSL2+ (not sure if any support VDSL2). >> >> Are these thing out of date and no longer deployed ? Were they ever >> effective, or just vapourware that didn't really improve things ? >> >> >> Do any Telcos still deploy them ? Anyone know of deployments in Canada ? >> >> I just need a reality check on those devices. >> >> jf >> From rafael at gav.ufsc.br Wed Apr 29 14:36:33 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 29 Apr 2015 09:36:33 -0500 Subject: ADSL Line Extenders In-Reply-To: <553FFA97.8030405@vaxination.ca> References: <553FFA97.8030405@vaxination.ca> Message-ID: Semi-related question: in instances like this, wouldn't a point-to-point link provide larger throughput and be less expensive? Unless you are talking about several subscribers that are already installed and operating. Depending on the situation, it might make sense to set a few sectorial antennas at a high-point and link everyone with small inexpensive CPE antennas. Just a quick thought. Good luck, Rafael On Tue, Apr 28, 2015 at 4:24 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > A friend on a rural DSl association asked about ADSL line extenders. > > A search on Google yields many products dating back to the days of > ADSL-1 advertising 1mbps profiles, but a few seem more recent and > support ADSL2+ (not sure if any support VDSL2). > > Are these thing out of date and no longer deployed ? Were they ever > effective, or just vapourware that didn't really improve things ? > > > Do any Telcos still deploy them ? Anyone know of deployments in Canada ? > > I just need a reality check on those devices. > > jf > From Bob.Watson at wwt.com Wed Apr 29 14:48:12 2015 From: Bob.Watson at wwt.com (Watson, Bob) Date: Wed, 29 Apr 2015 14:48:12 +0000 Subject: Single box Mux for qty (4) ChOC-3 to 12 DS3 Message-ID: Any recommendations on something reliable / affordable? Opti line from Adtran is an option thx From randy at psg.com Thu Apr 30 02:51:18 2015 From: randy at psg.com (Randy Bush) Date: Thu, 30 Apr 2015 11:51:18 +0900 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: <55380E9B.7080908@ripe.net> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> <55380E9B.7080908@ripe.net> Message-ID: >>> in any case the idea still seems silly. >> not if you need to appear to be DOING SOMETHING!!! > Of course there is that. But in order to be appear to be doing something > one has to pledge to do BCP38 and various other things I would consider > BCP. All little bits help. except the big logo marketing has the implication that all the rest of us unwashed networks are untrustable. this is not the cooperative internet. randy From frnkblk at iname.com Thu Apr 30 04:06:41 2015 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 29 Apr 2015 23:06:41 -0500 Subject: IPTV providers in IN/Chicago In-Reply-To: <8474125.1516.1430222741898.JavaMail.mhammett@ThunderFuck> References: <001a01d08175$2d472b60$87d58220$@iname.com> <8474125.1516.1430222741898.JavaMail.mhammett@ThunderFuck> Message-ID: <002901d082fb$11d09970$3571cc50$@iname.com> Different division within Comcast. =) Frank -----Original Message----- From: NANOG [mailto:nanog-bounces+frnkblk=iname.com at nanog.org] On Behalf Of Mike Hammett Sent: Tuesday, April 28, 2015 7:06 AM To: nanog at nanog.org Subject: Re: IPTV providers in IN/Chicago I'm not sure why or that Comcast would enable competition. Maybe I'm wrong. Then again, maybe Brandon isn't in a Comcast served area. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Frank Bulk" To: "Brandon Martin" , nanog at nanog.org Sent: Tuesday, April 28, 2015 12:35:43 AM Subject: RE: IPTV providers in IN/Chicago I believe Vubiquity (http://www.vubiquity.com/product-portfolio/livevu/) does, as well as Comcast HITS (http://www.comcastwholesale.com/products-services/mpeg-2-content-delivery/mpeg-2-delivery-content-providers). Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Monday, April 27, 2015 7:17 PM To: nanog at nanog.org Subject: IPTV providers in IN/Chicago Anyone know of an IPTV provider/wholesaler who I could meet in Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? Direct solicitations are OK out-of-band. -- Brandon Martin From nanog at ics-il.net Thu Apr 30 10:56:40 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 30 Apr 2015 05:56:40 -0500 (CDT) Subject: IPTV providers in IN/Chicago In-Reply-To: <002901d082fb$11d09970$3571cc50$@iname.com> Message-ID: <1497771.6419.1430391369552.JavaMail.mhammett@ThunderFuck> That is true. They'll sell ISPs transport. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Frank Bulk" To: "Mike Hammett" , nanog at nanog.org Sent: Wednesday, April 29, 2015 11:06:41 PM Subject: RE: IPTV providers in IN/Chicago Different division within Comcast. =) Frank -----Original Message----- From: NANOG [mailto:nanog-bounces+frnkblk=iname.com at nanog.org] On Behalf Of Mike Hammett Sent: Tuesday, April 28, 2015 7:06 AM To: nanog at nanog.org Subject: Re: IPTV providers in IN/Chicago I'm not sure why or that Comcast would enable competition. Maybe I'm wrong. Then again, maybe Brandon isn't in a Comcast served area. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Frank Bulk" To: "Brandon Martin" , nanog at nanog.org Sent: Tuesday, April 28, 2015 12:35:43 AM Subject: RE: IPTV providers in IN/Chicago I believe Vubiquity (http://www.vubiquity.com/product-portfolio/livevu/) does, as well as Comcast HITS (http://www.comcastwholesale.com/products-services/mpeg-2-content-delivery/mpeg-2-delivery-content-providers). Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Monday, April 27, 2015 7:17 PM To: nanog at nanog.org Subject: IPTV providers in IN/Chicago Anyone know of an IPTV provider/wholesaler who I could meet in Indianapolis (Henry St/Lifeline) or Chicago (Cermak/Equinix)? Direct solicitations are OK out-of-band. -- Brandon Martin From srihari at cse.sc.edu Thu Apr 30 17:58:05 2015 From: srihari at cse.sc.edu (Srihari Nelakuditi) Date: Thu, 30 Apr 2015 13:58:05 -0400 Subject: CFP: IEEE ICNP (Submission Deadline Just a Week Away) Message-ID: <55426D2D.6090902@cse.sc.edu> Call for Papers IEEE ICNP 2015 http://icnp15.cs.ucr.edu/ ICNP, the IEEE International Conference on Network Protocols, is the premier conference on network protocols, covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. Sponsored by the IEEE, ICNP 2015 is the 23rd edition of the conference, to be held in San Francisco, CA, USA from Nov. 10-13, 2015. ====================================================================== Important dates Paper Submission May 8, 2015, 7:59 PM EST (FIRM) Acceptance Notification June 30, 2015 Camera Ready Version Aug 15, 2015 ====================================================================== We invite papers with significant, original research contributions to the field of network protocols for submission. Topics of interest include, but are not limited to: * All aspects of network protocol research including design, specification, verification, implementation, measurement, testing, and analysis * Domain-specific solutions, including protocols for network security, Internet of Things, routing, user privacy, network management, and data centers * Application-layer protocols for peer-to-peer systems, social networks, and emerging systems * Contributions to network architecture, e.g., specific algorithms and protocols for software defined networks, network virtualization, or future Internet architectures ICNP 2015 will select an accepted full paper for the best paper award. Up to two of the best papers from ICNP will be fast-tracked in the IEEE/ACM Transactions on Networking, with a streamlined journal review process. Acceptance of fast-tracked papers in ToN is not guaranteed, but is more likely than a regular submission. Submission Guidelines * All papers should adhere to the IEEE Computer conference paper formatting requirements (IEEEtran.cls) and should not exceed 10 pages with font size no smaller than 10 pt (details can be found on the submission guidelines and formatting page). * ICNP uses a double-blind review process. The identity of authors and referees will not be revealed to each other. To ensure double-blind reviewing, author names and affiliations should not appear in the paper; bibliographic references should be made in such a way as to preserve author anonymity; acknowledgement with identifiable names and funding sources should be removed. Note that own work should be cited as a third person. Papers violating this double-blind review policy will be rejected without review. * Authors need to indicate on their paper?s submission page all TPC members with whom they have conflicts of interest. * Every paper MUST be presented by an author at the conference. The author list MUST remain the same as when the paper was submitted for review, and any changes in the author list or title is forbidden without prior written permission from the TPC Co-Chairs. At least one author of an accepted paper is expected to register at the full rate of the conference and to present the paper at the conference, in order for the paper to appear in the conference proceedings and be submitted to the IEEE digital library. Papers not presented by an author at the conference will not be published in the proceedings or submitted for inclusion in the IEEE digital library. Integrity Policy Submitted papers should not be previously published nor under review by another conference or journal. In some cases, the ICNP chairs may share information about submitted papers with other conference chairs and journal editors to ensure the integrity of papers under consideration. Authors are prohibited from informing any TPC member of any identifiable information (such as titles) of their submissions. Also, papers containing plagiarized material will be subject to the IEEE plagiarism policy and will be rejected without review. Organizing Committee General Co-Chairs: Srikanth V. Krishnamurthy, University of California, Riverside Prasant Mohapatra, University of California, Davis TPC Co-Chairs: Aditya Akella, University of Wisconsin, Madison Vishal Misra, Columbia University Steering Committee: Kevin Almeroth, University of California, Santa Barbara Ken Calvert, University of Kentucky Sonia Fahmy, Purdue University Mohamed Gouda, University of Texas, Austin Timothy G. Griffin, University of Cambridge Teruo Higashino, Osaka University David Lee, HP Labs K.K. Ramakrishnan (Chair), University of California, Riverside Krishan Sabnani, Bell Laboratories ====================================================================== From shimon.hochbaum at teliswitch.com Thu Apr 30 12:59:02 2015 From: shimon.hochbaum at teliswitch.com (Shimon Hochbaum) Date: Thu, 30 Apr 2015 15:59:02 +0300 Subject: ADSL Line Extenders In-Reply-To: References: <553FFA97.8030405@vaxination.ca> Message-ID: I second wholeheartedly the idea of wireless for this application, except that Rafael probably meant point to multipoint solutions: Trango https://www.trangosys.com/altum-ac or Waveip http://www.waveip.com/products/overview/ are 2 good options. Line extenders supporting ADSL2+ won't do much good: the 2 and the + denote improvements in the short range, less than 5000', probably not relevant in your case. If wired is your preferred option, you might want to consider HDSL based products, which are meant to drive 1.5M symmetric over long distances, power fed from the 2 sides for simplicity, with ability to go higher when pairs are bundled. Adtran should be the 1st place to look at. Good luck, Shimon > -----Original Message----- > From: Rafael Possamai [mailto:rafael at gav.ufsc.br] > Sent: Wednesday, April 29, 2015 17:37 > To: Jean-Francois Mezei > Cc: nanog at nanog.org > Subject: Re: ADSL Line Extenders > > Semi-related question: in instances like this, wouldn't a point-to-point link > provide larger throughput and be less expensive? Unless you are talking about > several subscribers that are already installed and operating. > Depending on the situation, it might make sense to set a few sectorial > antennas at a high-point and link everyone with small inexpensive CPE > antennas. Just a quick thought. > > Good luck, > Rafael > > > On Tue, Apr 28, 2015 at 4:24 PM, Jean-Francois Mezei < > jfmezei_nanog at vaxination.ca> wrote: > > > > > A friend on a rural DSl association asked about ADSL line extenders. > > > > A search on Google yields many products dating back to the days of > > ADSL-1 advertising 1mbps profiles, but a few seem more recent and > > support ADSL2+ (not sure if any support VDSL2). > > > > Are these thing out of date and no longer deployed ? Were they ever > > effective, or just vapourware that didn't really improve things ? > > > > > > Do any Telcos still deploy them ? Anyone know of deployments in Canada ? > > > > I just need a reality check on those devices. > > > > jf > >