From ops.lists at gmail.com  Sat Aug  1 00:17:32 2015
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 31 Jul 2015 17:17:32 -0700
Subject: Working with Spamhaus
In-Reply-To: <op.x2nwsoovtfhldh@rbeam.xactional.com>
References: <CAAARkvKXqPG991hA3fFQZ3DPaJ0sNMQOj-ZrWJVM_U6rEAGpnw@mail.gmail.com>
 <55BA27C9.2050907@snovc.com>
 <SN1PR08MB14382D07A9C1C2EAE7E334A8838B0@SN1PR08MB1438.namprd08.prod.outlook.com>
 <op.x2lynfsgtfhldh@rbeam.xactional.com>
 <SN1PR08MB1438AEAFD00FB8042E2BEB08838A0@SN1PR08MB1438.namprd08.prod.outlook.com>
 <CAGkwwuOSAccvaDfr94_MmiBAGZjEFrNEGuRy1qt5023wLO10ig@mail.gmail.com>
 <op.x2nwsoovtfhldh@rbeam.xactional.com>
Message-ID: <80721E3E-930C-4E9C-9D7B-7865BBAF5AB2@gmail.com>

It's what they call a free country 

Those that don't use it don't use it, and those who do are free to do so

--srs

> On 31-Jul-2015, at 4:56 PM, Ricky Beam <jfbeam at gmail.com> wrote:
> 
>> On Fri, 31 Jul 2015 17:28:34 -0400, Jaren Angerbauer <jarenangerbauer at gmail.com> wrote:
>> I work for Proofpoint -- we acquired SORBS back in 2011.
> 
> Hint: The Internet has a LONG memory.
> 
> The liberal and numerous dropping of "for free" makes me laugh. "You" knew the tainted nature of what you were buying. Nobody, to this day, places much trust at all in SORBS. I dare say there isn't anyone on NANOG (certainly any "long hairs") that haven't had at least one interaction with SORBS, most likely due to spamtraps; that number drops to almost zero when you put the word "good" in that sentence. Maybe it's better now under new management; we (the royal we) moved on long ago.

From kmedcalf at dessus.com  Sat Aug  1 02:27:32 2015
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Fri, 31 Jul 2015 22:27:32 -0400
Subject: Windows 10 Release
In-Reply-To: <CAMrdfRwhyCjp4jfVJRdZoAOioYjsGiUN=RjhHF2V0ORQGFFVfA@mail.gmail.com>
Message-ID: <a5501ab90d409049bc377752356ebd55@mail.dessus.com>


It takes no effort at all.  You just do the same thing as has been done with every previous version of windows:

When it asks for a LOCAL account and password, give it one.  When it asks if you want to do a Microsoft Account", say no thank-you.  Mind you, it does ask you about 8 times if you are REALLY REALLY REALLY REALLY sure you don't want to create or use a Microsoft account (obviously because that must be worth a LOT of money to microsoft).

But you do not have to do it.  And it is not difficult to avoid creating/using a microsoft account.

Nor does not having a Microsoft Account have any adverse effect.  It just means that you cannot use the crappy apps or the crappy app store.  The only failing that I find is that there is no way to actually get rid of all the cruft -- to say "I do not want to use a Microsoft Account so please permanently remove anything which requires it, or which cannot be maintained without it".

It is not as bad, however, as their propensity for turning the firewall off (and diddling the rules) everytime you get even the slightest update such that you have to go into the firewall settings on a daily basis and make sure they are still set the way YOU want them set and not the way Microsoft wants them set (Microsoft wants them completely disabled).

> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Helms
> Sent: Thursday, 30 July, 2015 10:35
> To: Justin Mckillican
> Cc: nanog at nanog.org list
> Subject: Re: Windows 10 Release
> 
> Justin,
> 
> That's true, but it takes effort for people to either set up a local
> account or change to one, and very few consumers will do that or have.
> 
> 
> Scott Helms
> Vice President of Technology
> ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
> 
> On Thu, Jul 30, 2015 at 10:28 AM, Justin Mckillican <justin at mckill.ca>
> wrote:
> 
> > Nope.  For the upgrade the only piece of information MSFT needed was
> your
> > email if you chose email notification once the upgrade was ready for
> you.
> >
> > After it's installed it will ask to finish up the install the 'Express'
> > method which enabled a bunch of things like WIFI password sharing to
> > friends and whatever else or if you chose the manual option like I did
> you
> > can disable everything.  It will also inherit your existing user
> settings,
> > so if your user is a local one instead of a cloud one it will continue
> to
> > be that way.
> >
> > It does install One Drive but again, if you never configured it or used
> it
> > then you'll simply see it in your task bar with the "welcome" or signup
> > screen.
> >
> >
> > -justin
> >
> > > On Jul 30, 2015, at 10:19 AM, Scott Helms <khelms at zcorum.com> wrote:
> > >
> > > Since the requirement is that users are upgrading from Win 7, 8, or
> 8.1
> > > they've already had to create at least a minimal MS ID which means
> either
> > > creating an email account on Outlook.com or providing an existing
> email
> > > address and  a password for MS.
> > >
> > >
> > > Scott Helms
> > > Vice President of Technology
> > > ZCorum
> > > (678) 507-5000
> > > --------------------------------
> > > http://twitter.com/kscotthelms
> > > --------------------------------
> > >
> > > On Thu, Jul 30, 2015 at 10:15 AM, Matthew Black
> <Matthew.Black at csulb.edu
> > >
> > > wrote:
> > >
> > >> Are users required to create any type of Microsoft cloud account
> (e.g.,
> > >> OneDrive, Office365, et alil) in order to install and use Windows 10?
> Of
> > >> Office? Is it possible to simply use Windows 10 without any Microsoft
> or
> > >> Google or Yahoo accounts?
> > >>
> > >> Is the unique identifier available to advertisers only through IE (or
> > its
> > >> successor) OR will it also be available through Firefox/Chrome?
> > >>
> > >>
> > >> matthew black
> > >> california state university, long beach
> > >>
> >
> >




From mhoppes at indigowireless.com  Sat Aug  1 02:29:22 2015
From: mhoppes at indigowireless.com (Matt Hoppes)
Date: Fri, 31 Jul 2015 22:29:22 -0400
Subject: Level3 packet loss
Message-ID: <81B7AA79-3B36-4D29-8828-556380109C96@indigowireless.com>

Anyone again seeing level3 packet loss tonight leaving the east coast going west bound?  In my case to Dallas. 



From bill at herrin.us  Sat Aug  1 02:34:10 2015
From: bill at herrin.us (William Herrin)
Date: Fri, 31 Jul 2015 22:34:10 -0400
Subject: Working with Spamhaus
In-Reply-To: <CAGkwwuOSAccvaDfr94_MmiBAGZjEFrNEGuRy1qt5023wLO10ig@mail.gmail.com>
References: <CAAARkvKXqPG991hA3fFQZ3DPaJ0sNMQOj-ZrWJVM_U6rEAGpnw@mail.gmail.com>
 <55BA27C9.2050907@snovc.com>
 <SN1PR08MB14382D07A9C1C2EAE7E334A8838B0@SN1PR08MB1438.namprd08.prod.outlook.com>
 <op.x2lynfsgtfhldh@rbeam.xactional.com>
 <SN1PR08MB1438AEAFD00FB8042E2BEB08838A0@SN1PR08MB1438.namprd08.prod.outlook.com>
 <CAGkwwuOSAccvaDfr94_MmiBAGZjEFrNEGuRy1qt5023wLO10ig@mail.gmail.com>
Message-ID: <CAP-guGU7=GObDg_w31XdvreZDvQug8WWw3C3qzZYVsfsqTON8g@mail.gmail.com>

On Fri, Jul 31, 2015 at 5:28 PM, Jaren Angerbauer
<jarenangerbauer at gmail.com> wrote:
> I work for Proofpoint -- we acquired SORBS back in 2011.  There is
> delisting (via SORBS support ticket).  Additionally, there is NO CHARGE to
> be delisted.

Hi Jaren,

The big problem I remember with SORBS from my ISP days was that if
they tested an open relay at IP address A and the return message came
from IP address B, they listed IP address B. This put me in an
impossible situation as an ISP providing an SMTP smarthost to my
authenticated customers. If just one of them screwed up their mail
programming, not trying to spam mind you, just screwed up their
configuration, my entire relay was hit with a block.

Practically speaking, to keep my mail server off SORBS I was required
to employ SORBS on my relay to block any customers whose IP appear as
an input into SORBS. If I wanted to stay off their list then I MUST
use them. Bad ethics there IMO.

Is itstill SORBS practice to list both input and output IP addresses
of an open relay, regardless of detected spam activity and without any
attempt to notify the mail op of the problem?

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From jlewis at lewis.org  Sat Aug  1 02:46:21 2015
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 31 Jul 2015 22:46:21 -0400 (EDT)
Subject: Working with Spamhaus
In-Reply-To: <25854.1438372498@turing-police.cc.vt.edu>
References: <CAAARkvKXqPG991hA3fFQZ3DPaJ0sNMQOj-ZrWJVM_U6rEAGpnw@mail.gmail.com>
 <55BA27C9.2050907@snovc.com>
 <SN1PR08MB14382D07A9C1C2EAE7E334A8838B0@SN1PR08MB1438.namprd08.prod.outlook.com>
 <m24mkk9khw.wl%randy@psg.com> <25854.1438372498@turing-police.cc.vt.edu>
Message-ID: <Pine.LNX.4.61.1507312245530.10544@soloth.lewis.org>

On Fri, 31 Jul 2015 Valdis.Kletnieks at vt.edu wrote:

> On Sat, 01 Aug 2015 04:48:11 +0900, Randy Bush said:
>>> As for SORBS, I'm not aware of anyone that uses it these days
>>
>> many folk do
>
> Many of them your competitors? :)  (Sorry, couldn't resist :)

Is that to be encouraged?

:)

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
                              |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From randy_94108 at yahoo.com  Sat Aug  1 04:53:34 2015
From: randy_94108 at yahoo.com (Randy)
Date: Sat, 1 Aug 2015 04:53:34 +0000 (UTC)
Subject: Working with Spamhaus
In-Reply-To: <CAGkwwuOSAccvaDfr94_MmiBAGZjEFrNEGuRy1qt5023wLO10ig@mail.gmail.com>
References: <CAGkwwuOSAccvaDfr94_MmiBAGZjEFrNEGuRy1qt5023wLO10ig@mail.gmail.com>
Message-ID: <1091862665.32660.1438404814250.JavaMail.yahoo@mail.yahoo.com>

----- Original Message -----

From: Jaren Angerbauer <jarenangerbauer at gmail.com>
To: "nanog at nanog.org" <nanog at nanog.org>
Cc: 
Sent: Friday, July 31, 2015 2:28 PM
Subject: Re: Working with Spamhaus

Hi,

As for SORBS, I'm not aware of anyone that uses it these days because of
> the extortion thing and the rather ..ahem .. "eccentric" nature of it's
> owner.
>

and


> I see you've never had the pleasure of dealing with SORBS. All it takes is
> *ONE* message - EVER - to be instantly, and forever, listed in their
> spamtraps list. Getting on the list is automatic and immediate. There are
> no thresholds or limits; and there's expiration. The only way off that
> list is to PAY them to remove you. (which makes it illegal in most places.
> The corporate sharks flipped when I pointed them to that "policy".)


I work for Proofpoint -- we acquired SORBS back in 2011.  There is
obviously some incorrect / very outdated information / viewpoints here, so
I thought it would make sense to clear the air a bit:

Listings can happen a number of different ways, however the vast majority
of these can be resolved, either through automatic delisting, or manual
delisting (via SORBS support ticket).  Additionally, there is NO CHARGE to
be delisted.

I'm happy to help mitigate any issues -- feel free to hit me up off list --
jangerbauer at proofpoint.com

Thanks


--Jaren


There is a very good reason as to why the .."
some incorrect / very outdated information / viewpoints here..<snip>

Matt/Michelle Sullivan did a lot of good things but a lot more *bad* in the name of SORBS - ergo the SORBS-Anathema.
...I have; just like many others on this list, have had to deal with this entity that had in essence turned into a joke.
./Randy


./Randy

From randy_94108 at yahoo.com  Sat Aug  1 05:12:48 2015
From: randy_94108 at yahoo.com (Randy)
Date: Sat, 1 Aug 2015 05:12:48 +0000 (UTC)
Subject: Working with Spamhaus
In-Reply-To: <1091862665.32660.1438404814250.JavaMail.yahoo@mail.yahoo.com>
References: <CAGkwwuOSAccvaDfr94_MmiBAGZjEFrNEGuRy1qt5023wLO10ig@mail.gmail.com>
 <1091862665.32660.1438404814250.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <2021776733.43747.1438405968621.JavaMail.yahoo@mail.yahoo.com>





----- Original Message -----
From: Randy <randy_94108 at yahoo.com>
To: Jaren Angerbauer <jarenangerbauer at gmail.com>; "nanog at nanog.org" <nanog at nanog.org>
Cc: 
Sent: Friday, July 31, 2015 9:53 PM
Subject: Re: Working with Spamhaus

----- Original Message -----


From: Jaren Angerbauer <jarenangerbauer at gmail.com>
To: "nanog at nanog.org" <nanog at nanog.org>
Cc: 
Sent: Friday, July 31, 2015 2:28 PM
Subject: Re: Working with Spamhaus

Hi,

As for SORBS, I'm not aware of anyone that uses it these days because of
> the extortion thing and the rather ..ahem .. "eccentric" nature of it's
> owner.
>

and


> I see you've never had the pleasure of dealing with SORBS. All it takes is
> *ONE* message - EVER - to be instantly, and forever, listed in their
> spamtraps list. Getting on the list is automatic and immediate. There are
> no thresholds or limits; and there's expiration. The only way off that
> list is to PAY them to remove you. (which makes it illegal in most places.
> The corporate sharks flipped when I pointed them to that "policy".)


I work for Proofpoint -- we acquired SORBS back in 2011.  There is
obviously some incorrect / very outdated information / viewpoints here, so
I thought it would make sense to clear the air a bit:

Listings can happen a number of different ways, however the vast majority
of these can be resolved, either through automatic delisting, or manual
delisting (via SORBS support ticket).  Additionally, there is NO CHARGE to
be delisted.

I'm happy to help mitigate any issues -- feel free to hit me up off list --
jangerbauer at proofpoint.com

Thanks


--Jaren


There is a very good reason as to why the .."
some incorrect / very outdated information / viewpoints here..<snip>

Matt/Michelle Sullivan did a lot of good things but a lot more *bad* in the name of SORBS - ergo the SORBS-Anathema.
...I have; just like many others on this list, have had to deal with this entity that had in essence turned into a joke.
./Randy


./Randy




....and to echo OP ovservation: at my last $day-job: SORBS wanted payment ( payment options: paypal and other electronic-means; To a Fund to suppport the defense(in court in Australia) of (someone whose I name I don't remember..)
Needless to say, the next exec-memo said: "Anyone who uses SORBS is on their own.
./Randy

From colinj at gt86car.org.uk  Sat Aug  1 06:45:12 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Sat, 1 Aug 2015 07:45:12 +0100
Subject: multipath tcp now in production use for linux based mobile devices
Message-ID: <D95C3C08-8F67-4F6B-BA8B-A5D32C7E463B@gt86car.org.uk>

http://blog.multipath-tcp.org/blog/html/2015/07/24/korea.html

From tom at cloudflare.com  Sat Aug  1 06:48:51 2015
From: tom at cloudflare.com (Tom Paseka)
Date: Fri, 31 Jul 2015 23:48:51 -0700
Subject: Comcast IPv6 issues
Message-ID: <CAL89SgK8qqMXeL6jhjBNLoopy_+u25HmDu==m2r24c6MonM_ZA@mail.gmail.com>

Can someone from Comcast please reach out? Looks like you're black holing
some prefixes.

-Tom

From jerome at ceriz.fr  Sat Aug  1 08:24:10 2015
From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=)
Date: Sat, 1 Aug 2015 10:24:10 +0200
Subject: Leak or legit ? 11/8
Message-ID: <55BC822A.9040409@ceriz.fr>

Hello,

Just saw something suprising : 11/8 just came live from AS23352
(ServerCentral)
http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=11.0.0.0 .

ARIN's registry didn't change :

Net Range	11.0.0.0 - 11.255.255.255
CIDR	11.0.0.0/8
Name	DODIIS
Handle	NET-11-0-0-0-1
Parent	
Net Type	Direct Allocation
Origin AS	
Organization	DoD Network Information Center (DNIC)
Registration Date	1984-01-19
Last Updated	2007-08-22

But on ALTDB it's declared as legit :

http://www.altdb.net/whois.cgi?query=11.0.0.0%2F8

So it's unlikely a mistake. What do you think happened here ?

Best regards,

-- 
J?r?me Nicolle

From nick at foobar.org  Sat Aug  1 10:05:19 2015
From: nick at foobar.org (Nick Hilliard)
Date: Sat, 1 Aug 2015 11:05:19 +0100
Subject: Windows 10 Release
In-Reply-To: <a5501ab90d409049bc377752356ebd55@mail.dessus.com>
References: <a5501ab90d409049bc377752356ebd55@mail.dessus.com>
Message-ID: <55BC99DF.4020208@foobar.org>

On 01/08/2015 03:27, Keith Medcalf wrote:
> It just means that you cannot use the crappy apps or the crappy app store.

which is fine until Microsoft ties in future software upgrades to the app
store and you find that you can't upgrade without tying yourself into a
Microsoft account.

E.g. just like they did with the Windows 8.0 to 8.1 upgrade.

Nick


From job at instituut.net  Sat Aug  1 10:11:33 2015
From: job at instituut.net (Job Snijders)
Date: Sat, 1 Aug 2015 12:11:33 +0200
Subject: Leak or legit ? 11/8
In-Reply-To: <55BC822A.9040409@ceriz.fr>
References: <55BC822A.9040409@ceriz.fr>
Message-ID: <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>

On Sat, Aug 01, 2015 at 10:24:10AM +0200, J?r?me Nicolle wrote:
> Just saw something suprising : 11/8 just came live from AS23352
> (ServerCentral)
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=11.0.0.0 .
> 
> ARIN's registry didn't change :
> 
> Net Range	11.0.0.0 - 11.255.255.255
> CIDR	11.0.0.0/8
> Name	DODIIS
> Handle	NET-11-0-0-0-1
> Parent	
> Net Type	Direct Allocation
> Origin AS	
> Organization	DoD Network Information Center (DNIC)
> Registration Date	1984-01-19
> Last Updated	2007-08-22
> 
> But on ALTDB it's declared as legit :
> 
> http://www.altdb.net/whois.cgi?query=11.0.0.0%2F8
> 
> So it's unlikely a mistake. What do you think happened here ?

I reached out to ServerCentral network engineering to ask.

Kind regards,

Job

From rdobbins at arbor.net  Sat Aug  1 11:47:17 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 01 Aug 2015 18:47:17 +0700
Subject: Leak or legit ? 11/8
In-Reply-To: <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>
References: <55BC822A.9040409@ceriz.fr>
 <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>
Message-ID: <A94B385E-70FA-4187-8F74-8B3F377CF7AF@arbor.net>

On 1 Aug 2015, at 17:11, Job Snijders wrote:

> I reached out to ServerCentral network engineering to ask.

I pinged NTT and Telia, as well - it's weekend nighttime in CONUS, and 
holiday season in Scandinavia, so it may take a while for folks to 
respond.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Sat Aug  1 11:49:20 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 01 Aug 2015 18:49:20 +0700
Subject: Leak or legit ? 11/8
In-Reply-To: <A94B385E-70FA-4187-8F74-8B3F377CF7AF@arbor.net>
References: <55BC822A.9040409@ceriz.fr>
 <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>
 <A94B385E-70FA-4187-8F74-8B3F377CF7AF@arbor.net>
Message-ID: <9BCAA553-6413-4123-89A2-09D5A5B64335@arbor.net>

On 1 Aug 2015, at 18:47, Roland Dobbins wrote:

> and Telia, as well

Got in touch with some Telia folks who're in-between flight legs - 
they're reaching out internally.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Sat Aug  1 12:00:23 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 01 Aug 2015 19:00:23 +0700
Subject: Leak or legit ? 11/8
In-Reply-To: <A94B385E-70FA-4187-8F74-8B3F377CF7AF@arbor.net>
References: <55BC822A.9040409@ceriz.fr>
 <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>
 <A94B385E-70FA-4187-8F74-8B3F377CF7AF@arbor.net>
Message-ID: <75056943-4B34-46A5-9973-C9D12E533787@arbor.net>

On 1 Aug 2015, at 18:47, Roland Dobbins wrote:

> I pinged NTT and Telia, as well - it's weekend nighttime in CONUS, and 
> holiday season in Scandinavia, so it may take a while for folks to 
> respond.

Pinged GTT, as well.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From kmedcalf at dessus.com  Sat Aug  1 12:23:21 2015
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 01 Aug 2015 08:23:21 -0400
Subject: Windows 10 Release
In-Reply-To: <55BC99DF.4020208@foobar.org>
Message-ID: <3f26f44139847b4c920c9ceb8c87d72f@mail.dessus.com>


Just like the phone needs a google account, the computer might end up needing a microsoft account.  That does not make it *my* account nor require that *I* use it.  Like the phone, it will simply be to keep the computer in minimal happiness.

You are right though, and it would be nice it stayed a stand-alone OS.  It might end up being the stray that drives more people to an alternate OS.  Or maybe not.  i Things have required apple accounts for decades -- but then again -- I would not expect anything different from the iThing crowd.

> -----Original Message-----
> From: Nick Hilliard [mailto:nick at foobar.org]
> Sent: Saturday, 1 August, 2015 06:05
> To: Keith Medcalf; nanog at nanog.org
> Subject: Re: Windows 10 Release
> 
> On 01/08/2015 03:27, Keith Medcalf wrote:
> > It just means that you cannot use the crappy apps or the crappy app
> store.
> 
> which is fine until Microsoft ties in future software upgrades to the app
> store and you find that you can't upgrade without tying yourself into a
> Microsoft account.
> 
> E.g. just like they did with the Windows 8.0 to 8.1 upgrade.
> 
> Nick





From rdobbins at arbor.net  Sat Aug  1 13:15:11 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 01 Aug 2015 20:15:11 +0700
Subject: Leak or legit ? 11/8
In-Reply-To: <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>
References: <55BC822A.9040409@ceriz.fr>
 <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>
Message-ID: <0E479F4E-2C97-4068-B986-672F955731F7@arbor.net>

On 1 Aug 2015, at 17:11, Job Snijders wrote:

> I reached out to ServerCentral network engineering to ask.

ServerCentral say it's legit, and that they have the appropriate 
documentation.

I encouraged them to reply here.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From job at instituut.net  Sat Aug  1 13:28:57 2015
From: job at instituut.net (Job Snijders)
Date: Sat, 1 Aug 2015 15:28:57 +0200
Subject: Leak or legit ? 11/8
In-Reply-To: <0E479F4E-2C97-4068-B986-672F955731F7@arbor.net>
References: <55BC822A.9040409@ceriz.fr>
 <20150801101133.GR65805@dhcp-a1b1.meeting.ietf.org>
 <0E479F4E-2C97-4068-B986-672F955731F7@arbor.net>
Message-ID: <20150801132857.GU65805@dhcp-a1b1.meeting.ietf.org>

On Sat, Aug 01, 2015 at 08:15:11PM +0700, Roland Dobbins wrote:
> On 1 Aug 2015, at 17:11, Job Snijders wrote:
> 
> >I reached out to ServerCentral network engineering to ask.
> 
> ServerCentral say it's legit, and that they have the appropriate
> documentation.

I've been in touch with ServerCentral and they told me this is NOT a
misconfiguration. Should anybody have questions I recommend you reach
out to the ServerCentral NOC directly.

Kind regards,

Job

From tqr2813d376cjozqap1l at tutanota.com  Sat Aug  1 14:44:05 2015
From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com)
Date: Sat, 1 Aug 2015 14:44:05 +0000 (UTC)
Subject: Windows 10 Release
In-Reply-To: <55BC99DF.4020208@foobar.org>
References: <<CAMrdfRwhyCjp4jfVJRdZoAOioYjsGiUN=RjhHF2V0ORQGFFVfA@mail.gmail.com>>
 <a5501ab90d409049bc377752356ebd55@mail.dessus.com>
 <<a5501ab90d409049bc377752356ebd55@mail.dessus.com>>
 <55BC99DF.4020208@foobar.org>
Message-ID: <Jvdi3bR----0@tutanota.com>

1. Aug 2015 10:05 by nick at foobar.org:


> On 01/08/2015 03:27, Keith Medcalf wrote:
>> It just means that you cannot use the crappy apps or the crappy app store.
>
> which is fine until Microsoft ties in future software upgrades to the app
> store and you find that you can't upgrade without tying yourself into a
> Microsoft account.
>
> E.g. just like they did with the Windows 8.0 to 8.1 upgrade.
>




It's been a while but I'm near certain that they did not require a microsoft 
account to download the 8.1 update - you just had to use their sucky 
application to start the process


From rafael at gav.ufsc.br  Sat Aug  1 15:03:58 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Sat, 1 Aug 2015 10:03:58 -0500
Subject: Leak or legit ? 11/8
In-Reply-To: <55BC822A.9040409@ceriz.fr>
References: <55BC822A.9040409@ceriz.fr>
Message-ID: <CAJB2g-H5b8NdcCgrAxxSOFkFCXbj0YpkgfZqmPkraRTHf-Duzg@mail.gmail.com>

This is interesting, the DoD has a half trillion dollar budget, so not sure
what the motivation was to get rid of a /8.

On Sat, Aug 1, 2015 at 3:24 AM, J?r?me Nicolle <jerome at ceriz.fr> wrote:

> Hello,
>
> Just saw something suprising : 11/8 just came live from AS23352
> (ServerCentral)
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=11.0.0.0 .
>
> ARIN's registry didn't change :
>
> Net Range       11.0.0.0 - 11.255.255.255
> CIDR    11.0.0.0/8
> Name    DODIIS
> Handle  NET-11-0-0-0-1
> Parent
> Net Type        Direct Allocation
> Origin AS
> Organization    DoD Network Information Center (DNIC)
> Registration Date       1984-01-19
> Last Updated    2007-08-22
>
> But on ALTDB it's declared as legit :
>
> http://www.altdb.net/whois.cgi?query=11.0.0.0%2F8
>
> So it's unlikely a mistake. What do you think happened here ?
>
> Best regards,
>
> --
> J?r?me Nicolle
>

From pabraeken at gmail.com  Sat Aug  1 15:11:07 2015
From: pabraeken at gmail.com (Pierre-Alexandre Braeken)
Date: Sat, 1 Aug 2015 11:11:07 -0400
Subject: Windows 10 Release
In-Reply-To: <Jvdi3bR----0@tutanota.com>
References: <a5501ab90d409049bc377752356ebd55@mail.dessus.com>
 <55BC99DF.4020208@foobar.org> <Jvdi3bR----0@tutanota.com>
Message-ID: <CAAPPtAbD_3WPG2C+0p+EvH4WGZPa4_ai7f4U_MLw=+=ESko8NA@mail.gmail.com>

Pay attention to your account because it is still possible to reveal the
passwords
http://sysadminconcombre.blogspot.ca/2015/07/how-to-reveal-windows-10-password.html
 and https://twitter.com/pabraeken/status/627493309674573824

On Sat, Aug 1, 2015 at 10:44 AM, <tqr2813d376cjozqap1l at tutanota.com> wrote:

> 1. Aug 2015 10:05 by nick at foobar.org:
>
>
> > On 01/08/2015 03:27, Keith Medcalf wrote:
> >> It just means that you cannot use the crappy apps or the crappy app
> store.
> >
> > which is fine until Microsoft ties in future software upgrades to the app
> > store and you find that you can't upgrade without tying yourself into a
> > Microsoft account.
> >
> > E.g. just like they did with the Windows 8.0 to 8.1 upgrade.
> >
>
>
>
>
> It's been a while but I'm near certain that they did not require a
> microsoft
> account to download the 8.1 update - you just had to use their sucky
> application to start the process
>
>

From mdapieve at gmail.com  Sat Aug  1 15:38:15 2015
From: mdapieve at gmail.com (marco da pieve)
Date: Sat, 1 Aug 2015 17:38:15 +0200
Subject: best practice for number of RR
Message-ID: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>

Hi all,
this is my first time in asking for advices here and I hope not to bother
you with this topic (if it has been already covered in the past, would you
please please point me to that discussion?).

Anyway, I need to decide whether to go for a BGP topology with a single
cluster of 3 Route Reflectors (to overcome a dual point of failure issue)
or maybe to two standalone clusters each with two RR (sacrificing half of
the network in case two RR of the same cluster fail).

To give you some input data:

- 8000 actual VPNV4 prefixes
- 180 BGP neighbors

In case of the 3 RRs option, prefixes will become 24000 on the clients (24k
received routes in total but 1/3 installed. No BGP multipath will be used).
In this scenario considering network growth up to doubling the current
number of VPNV4 prefixes, I would end up to have 16k actual vpnv4 prefixes
and 48k vpnv4 prefixes received by the clients, which is almost the limit
for the HW used.

In the case of two standalone clusters each with two RRs, BGP neighborships
will be halved among the two clusters and vpnv4 prefixes too. In case of
network growth up to doubling the number of prefixes, the clients will
receive up to 24k vpnv4 prefixes and this is still far below the HW limits.
Of course this option will not prevent a dual failure in the single cluster
and half of the network would end up in outage.

My choice would be to go for the two clusters assuming that each RR has
supervisor/controlling card protection capabilities.

However I'd like to have a feedback on the pros and cons on the design
itself if any. I know that design is planned on the resources available but
just for discussing and abstracting from the HW, would there be any
drawbacks in having an odd number of RR in the network? is one of the two
option a no to go choice? what was your experience?

thanks a lot for your time and patience to go through this email,

M.

From shane at ronan-online.com  Sat Aug  1 16:16:45 2015
From: shane at ronan-online.com (Shane Ronan)
Date: Sat, 1 Aug 2015 12:16:45 -0400
Subject: best practice for number of RR
In-Reply-To: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
References: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
Message-ID: <CAJ_LqoEkYBJa6EZQF44RMEuKG+L2DMJ53y1xt7-YjC+dFroAAg@mail.gmail.com>

Have you considered a virtual route reflector rather than physical hardware?
On Aug 1, 2015 11:39 AM, "marco da pieve" <mdapieve at gmail.com> wrote:

> Hi all,
> this is my first time in asking for advices here and I hope not to bother
> you with this topic (if it has been already covered in the past, would you
> please please point me to that discussion?).
>
> Anyway, I need to decide whether to go for a BGP topology with a single
> cluster of 3 Route Reflectors (to overcome a dual point of failure issue)
> or maybe to two standalone clusters each with two RR (sacrificing half of
> the network in case two RR of the same cluster fail).
>
> To give you some input data:
>
> - 8000 actual VPNV4 prefixes
> - 180 BGP neighbors
>
> In case of the 3 RRs option, prefixes will become 24000 on the clients (24k
> received routes in total but 1/3 installed. No BGP multipath will be used).
> In this scenario considering network growth up to doubling the current
> number of VPNV4 prefixes, I would end up to have 16k actual vpnv4 prefixes
> and 48k vpnv4 prefixes received by the clients, which is almost the limit
> for the HW used.
>
> In the case of two standalone clusters each with two RRs, BGP neighborships
> will be halved among the two clusters and vpnv4 prefixes too. In case of
> network growth up to doubling the number of prefixes, the clients will
> receive up to 24k vpnv4 prefixes and this is still far below the HW limits.
> Of course this option will not prevent a dual failure in the single cluster
> and half of the network would end up in outage.
>
> My choice would be to go for the two clusters assuming that each RR has
> supervisor/controlling card protection capabilities.
>
> However I'd like to have a feedback on the pros and cons on the design
> itself if any. I know that design is planned on the resources available but
> just for discussing and abstracting from the HW, would there be any
> drawbacks in having an odd number of RR in the network? is one of the two
> option a no to go choice? what was your experience?
>
> thanks a lot for your time and patience to go through this email,
>
> M.
>

From mdapieve at gmail.com  Sat Aug  1 16:34:13 2015
From: mdapieve at gmail.com (marco da pieve)
Date: Sat, 1 Aug 2015 18:34:13 +0200
Subject: best practice for number of RR
In-Reply-To: <CAJ_LqoEkYBJa6EZQF44RMEuKG+L2DMJ53y1xt7-YjC+dFroAAg@mail.gmail.com>
References: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
 <CAJ_LqoEkYBJa6EZQF44RMEuKG+L2DMJ53y1xt7-YjC+dFroAAg@mail.gmail.com>
Message-ID: <CACTuH9f=zPw6K_q79Hj75Nabi+q0x2ituEa=zcLpWisZji33mw@mail.gmail.com>

Hi Shane,
for the boxes that are currently installed in the network, this is not a
valid option (politically/commercially speaking).

thanks,
Marco

On 1 August 2015 at 18:16, Shane Ronan <shane at ronan-online.com> wrote:

> Have you considered a virtual route reflector rather than physical
> hardware?
> On Aug 1, 2015 11:39 AM, "marco da pieve" <mdapieve at gmail.com> wrote:
>
>> Hi all,
>> this is my first time in asking for advices here and I hope not to bother
>> you with this topic (if it has been already covered in the past, would you
>> please please point me to that discussion?).
>>
>> Anyway, I need to decide whether to go for a BGP topology with a single
>> cluster of 3 Route Reflectors (to overcome a dual point of failure issue)
>> or maybe to two standalone clusters each with two RR (sacrificing half of
>> the network in case two RR of the same cluster fail).
>>
>> To give you some input data:
>>
>> - 8000 actual VPNV4 prefixes
>> - 180 BGP neighbors
>>
>> In case of the 3 RRs option, prefixes will become 24000 on the clients
>> (24k
>> received routes in total but 1/3 installed. No BGP multipath will be
>> used).
>> In this scenario considering network growth up to doubling the current
>> number of VPNV4 prefixes, I would end up to have 16k actual vpnv4 prefixes
>> and 48k vpnv4 prefixes received by the clients, which is almost the limit
>> for the HW used.
>>
>> In the case of two standalone clusters each with two RRs, BGP
>> neighborships
>> will be halved among the two clusters and vpnv4 prefixes too. In case of
>> network growth up to doubling the number of prefixes, the clients will
>> receive up to 24k vpnv4 prefixes and this is still far below the HW
>> limits.
>> Of course this option will not prevent a dual failure in the single
>> cluster
>> and half of the network would end up in outage.
>>
>> My choice would be to go for the two clusters assuming that each RR has
>> supervisor/controlling card protection capabilities.
>>
>> However I'd like to have a feedback on the pros and cons on the design
>> itself if any. I know that design is planned on the resources available
>> but
>> just for discussing and abstracting from the HW, would there be any
>> drawbacks in having an odd number of RR in the network? is one of the two
>> option a no to go choice? what was your experience?
>>
>> thanks a lot for your time and patience to go through this email,
>>
>> M.
>>
>


-- 
Marco Da Pieve

From marine64 at gmail.com  Sat Aug  1 16:54:20 2015
From: marine64 at gmail.com (Brian Henson)
Date: Sat, 1 Aug 2015 12:54:20 -0400
Subject: Leak or legit ? 11/8
In-Reply-To: <CAJB2g-H5b8NdcCgrAxxSOFkFCXbj0YpkgfZqmPkraRTHf-Duzg@mail.gmail.com>
References: <55BC822A.9040409@ceriz.fr>
 <CAJB2g-H5b8NdcCgrAxxSOFkFCXbj0YpkgfZqmPkraRTHf-Duzg@mail.gmail.com>
Message-ID: <CAE_vMvcvTVMu+mNBmX0wRPjLyuvxoQSEz-y5SnSDj8C4RE=7=A@mail.gmail.com>

They could be part of the private cloud initiative that I read about
recently. The DOD is trying to condense down the number of data centers
they have to cut costs and leverage better control over security.

On Sat, Aug 1, 2015 at 11:03 AM, Rafael Possamai <rafael at gav.ufsc.br> wrote:

> This is interesting, the DoD has a half trillion dollar budget, so not sure
> what the motivation was to get rid of a /8.
>
> On Sat, Aug 1, 2015 at 3:24 AM, J?r?me Nicolle <jerome at ceriz.fr> wrote:
>
> > Hello,
> >
> > Just saw something suprising : 11/8 just came live from AS23352
> > (ServerCentral)
> > http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=11.0.0.0 .
> >
> > ARIN's registry didn't change :
> >
> > Net Range       11.0.0.0 - 11.255.255.255
> > CIDR    11.0.0.0/8
> > Name    DODIIS
> > Handle  NET-11-0-0-0-1
> > Parent
> > Net Type        Direct Allocation
> > Origin AS
> > Organization    DoD Network Information Center (DNIC)
> > Registration Date       1984-01-19
> > Last Updated    2007-08-22
> >
> > But on ALTDB it's declared as legit :
> >
> > http://www.altdb.net/whois.cgi?query=11.0.0.0%2F8
> >
> > So it's unlikely a mistake. What do you think happened here ?
> >
> > Best regards,
> >
> > --
> > J?r?me Nicolle
> >
>

From eric at ericheather.com  Sat Aug  1 17:50:44 2015
From: eric at ericheather.com (Eric C. Miller)
Date: Sat, 1 Aug 2015 17:50:44 +0000
Subject: NANOG isn't for desktop OS licensing support, was: Windows 10
 Release
In-Reply-To: <011b01d0cb09$0c63ddc0$252b9940$@gmail.com>
References: <011b01d0cb09$0c63ddc0$252b9940$@gmail.com>
Message-ID: <DC85D08B84BB854086E9524DAB67D18757E4B825@Teriwood.miller.local>

I will say that our peering traffic with Akamai has doubled since Thursday. It's starting to come back down, now.



Eric



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chuck Church
Sent: Thursday, July 30, 2015 4:48 PM
To: nanog at nanog.org
Subject: NANOG isn't for desktop OS licensing support, was: Windows 10 Release

I hate to be that guy, but this is getting really outside the scope of NANOG.

Chuck

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Greco
Sent: Thursday, July 30, 2015 12:58 PM
To: Scott Helms <khelms at zcorum.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: Windows 10 Release

> I was just thinking about my remaining Win 7 box _after_ I hit send 
> and I believe you're correct (I have one still to upgrade).  Which 
> means users upgrading from 7 to 10 will need to create an ID, but 
> users of 8 and 8.1 will use the one they already have.


This is incorrect.  While the Win 8{,.1} install process makes it appear as though you need a Microsoft ID, you can actually go into the "create a new Microsoft ID" option and there's a way to proceed without creating a Microsoft ID, which leaves you with all local accounts.

It does appear to be designed to make you THINK you need a Microsoft account however.

I have a freshly installed Windows 8.1 box here (no Microsoft ID) that I then upgraded to Windows 10, and it also does not have any Microsoft ID attached to it.  Activation shows as "Windows 10 Home"
and "Windows is activated."  There's a beggy-screen on the user account page saying something like "Windows is better when your settings and files automatically sync.  Switch to a Microsoft Account now!"

So, again, totally optional, but admittedly the path of least resistance has users creating a Microsoft Account or linking to their existing one.  You have to trawl around a little to get the better (IMHO) behaviour.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.


From jneiberger at gmail.com  Sat Aug  1 18:11:19 2015
From: jneiberger at gmail.com (John Neiberger)
Date: Sat, 1 Aug 2015 12:11:19 -0600
Subject: Comcast IPv6 issues
In-Reply-To: <CAL89SgK8qqMXeL6jhjBNLoopy_+u25HmDu==m2r24c6MonM_ZA@mail.gmail.com>
References: <CAL89SgK8qqMXeL6jhjBNLoopy_+u25HmDu==m2r24c6MonM_ZA@mail.gmail.com>
Message-ID: <CAOQYbjp=JYNRCHv0RdoFneNfqTr0Qp_gje4eyHw2tEJysauGrg@mail.gmail.com>

Has someone talked to you about this yet? If not, please unicast the
prefixes to me and I'll check into it.

John

On Sat, Aug 1, 2015 at 12:48 AM, Tom Paseka via NANOG <nanog at nanog.org>
wrote:

> Can someone from Comcast please reach out? Looks like you're black holing
> some prefixes.
>
> -Tom
>

From sean at donelan.com  Sat Aug  1 19:27:19 2015
From: sean at donelan.com (Sean Donelan)
Date: Sat, 1 Aug 2015 15:27:19 -0400 (EDT)
Subject: Quakecon: Network Operations Center tour
Message-ID: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>


Non-work, work related information.  Many NANOG geeks might be interested
in this video tour of the Quakecon NOC tour.  As any ISP operator knows,
gamers complain faster about problems than any NMS, so you've got to
admire the bravery of any NOC in the middle of a gaming convention floor.

What Powers Quakecon | Network Operations Center Tour
https://www.youtube.com/watch?v=mOv62lBdlXU


From alejandroacostaalamo at gmail.com  Sat Aug  1 19:57:07 2015
From: alejandroacostaalamo at gmail.com (Alejandro Acosta)
Date: Sat, 1 Aug 2015 15:27:07 -0430
Subject: best practice for number of era que
Message-ID: <CAOmxzdzNV-K5SP9cJNZmBu5NGQ5Gy=9bNiPcCut228CzdzweoA@mail.gmail.com>

A
El ago 1, 2015 12:05, "marco da pieve" <mdapieve at gmail.com> escribi?:
>
> Hi Shane,
> for the boxes that are currently installed in the network, this is not a
> valid option (politically/commercially speaking).
>
> thanks,
> Marco
>
> On 1 August 2015 at 18:16, Shane Ronan <shane at ronan-online.com> wrote:
>
> > Have you considered a virtual route reflector rather than physical
> > hardware?
> > On Aug 1, 2015 11:39 AM, "marco da pieve" <mdapieve at gmail.com> wrote:
> >
> >> Hi all,
> >> this is my first time in asking for advices here and I hope not to
bother
> >> you with this topic (if it has been already covered in the past, would
you
> >> please please point me to that discussion?).
> >>
> >> Anyway, I need to decide whether to go for a BGP topology with a single
> >> cluster of 3 Route Reflectors (to overcome a dual point of failure
issue)
> >> or maybe to two standalone clusters each with two RR (sacrificing half
of
> >> the network in case two RR of the same cluster fail).
> >>
> >> To give you some input data:
> >>
> >> - 8000 actual VPNV4 prefixes
> >> - 180 BGP neighbors
> >>
> >> In case of the 3 RRs option, prefixes will become 24000 on the clients
> >> (24k
> >> received routes in total but 1/3 installed. No BGP multipath will be
> >> used).
> >> In this scenario considering network growth up to doubling the current
> >> number of VPNV4 prefixes, I would end up to have 16k actual vpnv4
prefixes
> >> and 48k vpnv4 prefixes received by the clients, which is almost the
limit
> >> for the HW used.
> >>
> >> In the case of two standalone clusters each with two RRs, BGP
> >> neighborships
> >> will be halved among the two clusters and vpnv4 prefixes too. In case
of
> >> network growth up to doubling the number of prefixes, the clients will
> >> receive up to 24k vpnv4 prefixes and this is still far below the HW
> >> limits.
> >> Of course this option will not prevent a dual failure in the single
> >> cluster
> >> and half of the network would end up in outage.
> >>
> >> My choice would be to go for the two clusters assuming that each RR has
> >> supervisor/controlling card protection capabilities.
> >>
> >> However I'd like to have a feedback on the pros and cons on the design
> >> itself if any. I know that design is planned on the resources available
> >> but
> >> just for discussing and abstracting from the HW, would there be any
> >> drawbacks in having an odd number of RR in the network? is one of the
two
> >> option a no to go choice? what was your experience?
> >>
> >> thanks a lot for your time and patience to go through this email,
> >>
> >> M.
> >>
> >
>
>
> --
> Marco Da Pieve

From mdapieve at gmail.com  Sat Aug  1 22:14:04 2015
From: mdapieve at gmail.com (marco da pieve)
Date: Sun, 2 Aug 2015 00:14:04 +0200
Subject: best practice for number of RR
In-Reply-To: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
References: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
Message-ID: <CACTuH9ebgdzS=XdoBgxmZSB6neMCd+X2Cda9W2XcrbWS+8UYGA@mail.gmail.com>

Hi all,
I'm sorry about this email replication (or spam whatever you like most) but
one of the replies to my original email could have made this email
unnoticed.
This is my first time in asking for advices here and I hope not to bother
you with this topic (if it has been already covered in the past, would you
please please point me to that discussion?).

Anyway, I need to decide whether to go for a BGP topology with a single
cluster of 3 Route Reflectors (to overcome a dual point of failure issue)
or maybe to two standalone clusters each with two RR (sacrificing half of
the network in case two RR of the same cluster fail).

To give you some input data:

- 8000 actual VPNV4 prefixes
- 180 BGP neighbors

In case of the 3 RRs option, prefixes will become 24000 on the clients (24k
received routes in total but 1/3 installed. No BGP multipath will be used).
In this scenario considering network growth up to doubling the current
number of VPNV4 prefixes, I would end up to have 16k actual vpnv4 prefixes
and 48k vpnv4 prefixes received by the clients, which is almost the limit
for the HW used.

In the case of two standalone clusters each with two RRs, BGP neighborships
will be halved among the two clusters and vpnv4 prefixes too. In case of
network growth up to doubling the number of prefixes, the clients will
receive up to 24k vpnv4 prefixes and this is still far below the HW limits.
Of course this option will not prevent a dual failure in the single cluster
and half of the network would end up in outage.

My choice would be to go for the two clusters assuming that each RR has
supervisor/controlling card protection capabilities.

However I'd like to have a feedback on the pros and cons on the design
itself if any. I know that design is planned on the resources available but
just for discussing and abstracting from the HW, would there be any
drawbacks in having an odd number of RR in the network? is one of the two
option a no to go choice? what was your experience?

thanks a lot for your time and patience to go through this email,

M.





-- 
Marco Da Pieve

From morrowc.lists at gmail.com  Sun Aug  2 01:16:47 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 1 Aug 2015 21:16:47 -0400
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
Message-ID: <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>

highlights:
  "happy and blinking"
  "two firewalls for the two att 1gig links, and two spare doing ....."

catalyst 6500's

Also the 3750 on top of the services rack is funny... because empty.

On Sat, Aug 1, 2015 at 3:27 PM, Sean Donelan <sean at donelan.com> wrote:
>
> Non-work, work related information.  Many NANOG geeks might be interested
> in this video tour of the Quakecon NOC tour.  As any ISP operator knows,
> gamers complain faster about problems than any NMS, so you've got to
> admire the bravery of any NOC in the middle of a gaming convention floor.
>
> What Powers Quakecon | Network Operations Center Tour
> https://www.youtube.com/watch?v=mOv62lBdlXU
>

From mianosm at gmail.com  Sun Aug  2 01:51:16 2015
From: mianosm at gmail.com (Steven Miano)
Date: Sat, 1 Aug 2015 21:51:16 -0400
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
Message-ID: <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>

It would have been more interesting to see:

-- a network weather map
-- the ELK implementation
-- actual cache statistics (historically steam/game downloads are not
cahce'able)

Thanks for the share though Sean!





On Sat, Aug 1, 2015 at 9:16 PM, Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> highlights:
>   "happy and blinking"
>   "two firewalls for the two att 1gig links, and two spare doing ....."
>
> catalyst 6500's
>
> Also the 3750 on top of the services rack is funny... because empty.
>
> On Sat, Aug 1, 2015 at 3:27 PM, Sean Donelan <sean at donelan.com> wrote:
> >
> > Non-work, work related information.  Many NANOG geeks might be interested
> > in this video tour of the Quakecon NOC tour.  As any ISP operator knows,
> > gamers complain faster about problems than any NMS, so you've got to
> > admire the bravery of any NOC in the middle of a gaming convention floor.
> >
> > What Powers Quakecon | Network Operations Center Tour
> > https://www.youtube.com/watch?v=mOv62lBdlXU
> >
>



-- 
Miano, Steven M.
http://stevenmiano.com

From niels=nanog at bakker.net  Sun Aug  2 11:17:22 2015
From: niels=nanog at bakker.net (Niels Bakker)
Date: Sun, 2 Aug 2015 13:17:22 +0200
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
Message-ID: <20150802111722.GB4116@excession.tpb.net>

* mianosm at gmail.com (Steven Miano) [Sun 02 Aug 2015, 03:52 CEST]:
>It would have been more interesting to see:
>
>-- a network weather map
>-- the ELK implementation
>-- actual cache statistics (historically steam/game downloads are not
>cahce'able)

Not quite true according to 
http://blog.multiplay.co.uk/2014/04/lancache-dynamically-caching-game-installs-at-lans-using-nginx/

Also, 2 Gbps for 4,400 people?  Pretty lackluster compared to European 
events.  30C3 had 100 Gbps to the conference building.  And no NAT: 
every host got real IP addresses (IPv4 + IPv6).


	-- Niels.

From mark.tinka at seacom.mu  Sun Aug  2 11:30:07 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 2 Aug 2015 13:30:07 +0200
Subject: best practice for number of RR
In-Reply-To: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
References: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
Message-ID: <55BDFF3F.9020603@seacom.mu>



On 1/Aug/15 17:38, marco da pieve wrote:
> Hi all,
> this is my first time in asking for advices here and I hope not to bother
> you with this topic (if it has been already covered in the past, would you
> please please point me to that discussion?).
>
> Anyway, I need to decide whether to go for a BGP topology with a single
> cluster of 3 Route Reflectors (to overcome a dual point of failure issue)
> or maybe to two standalone clusters each with two RR (sacrificing half of
> the network in case two RR of the same cluster fail).
>
> To give you some input data:
>
> - 8000 actual VPNV4 prefixes
> - 180 BGP neighbors
>
> In case of the 3 RRs option, prefixes will become 24000 on the clients (24k
> received routes in total but 1/3 installed. No BGP multipath will be used).
> In this scenario considering network growth up to doubling the current
> number of VPNV4 prefixes, I would end up to have 16k actual vpnv4 prefixes
> and 48k vpnv4 prefixes received by the clients, which is almost the limit
> for the HW used.
>
> In the case of two standalone clusters each with two RRs, BGP neighborships
> will be halved among the two clusters and vpnv4 prefixes too. In case of
> network growth up to doubling the number of prefixes, the clients will
> receive up to 24k vpnv4 prefixes and this is still far below the HW limits.
> Of course this option will not prevent a dual failure in the single cluster
> and half of the network would end up in outage.
>
> My choice would be to go for the two clusters assuming that each RR has
> supervisor/controlling card protection capabilities.
>
> However I'd like to have a feedback on the pros and cons on the design
> itself if any. I know that design is planned on the resources available but
> just for discussing and abstracting from the HW, would there be any
> drawbacks in having an odd number of RR in the network? is one of the two
> option a no to go choice? what was your experience?

We deploy 2x RR's in each of our main PoP's.

All iBGP clients in that PoP speak to their local RR's.

The RR's all speak to one another in a full-mesh.

Each RR pair is its own cluster.

We run our RR's on Cisco's CSR1000v software, which is IOS XE in a VM
(VMware ESXi in our case). These are high-end servers, but we don't
worry too much about over-protecting one because there is a redundant
one in each cluster.

I once ran a network which ad 3x RR's per cluster. That is fine, but the
impact on the clients can become an issue over time.

Mark.

From mark.tinka at seacom.mu  Sun Aug  2 11:31:50 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 2 Aug 2015 13:31:50 +0200
Subject: best practice for number of RR
In-Reply-To: <CACTuH9f=zPw6K_q79Hj75Nabi+q0x2ituEa=zcLpWisZji33mw@mail.gmail.com>
References: <CACTuH9fLGv3nvpUb-_KSD_MiD3UvcGSs9wU4r8UTQhOUWRTrCg@mail.gmail.com>
 <CAJ_LqoEkYBJa6EZQF44RMEuKG+L2DMJ53y1xt7-YjC+dFroAAg@mail.gmail.com>
 <CACTuH9f=zPw6K_q79Hj75Nabi+q0x2ituEa=zcLpWisZji33mw@mail.gmail.com>
Message-ID: <55BDFFA6.4040501@seacom.mu>



On 1/Aug/15 18:34, marco da pieve wrote:
> Hi Shane,
> for the boxes that are currently installed in the network, this is not a
> valid option (politically/commercially speaking).

Well, Cisco, Juniper and ALU are shipping carrier-grade OS's that will
run on a server in a VM.

Brocade is also known to be doing good work there re: Vyatta, but I
don't know of anyone running that as an RR.

In 2015, I'd never spend money on a dedicated RR running on router
hardware. Server, VM, end of story.

Mark.

From randy at psg.com  Sun Aug  2 11:32:14 2015
From: randy at psg.com (Randy Bush)
Date: Sun, 02 Aug 2015 20:32:14 +0900
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <20150802111722.GB4116@excession.tpb.net>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net>
Message-ID: <m28u9u6i4h.wl%randy@psg.com>

> Also, 2 Gbps for 4,400 people?  Pretty lackluster compared to European
> events.  30C3 had 100 Gbps to the conference building.  And no NAT:
> every host got real IP addresses (IPv4 + IPv6).

ietf, >1k people, easily fits in 10g, but tries to have two for
redundancy.  also no nat, no firewall, and even ipv6.  but absorbing or
combatting scans and other attacks cause complexity one would prefer to
avoid.  in praha, there was even a tkip attack, or so it is  believed;
turned off tkip.

the quakecon net was explained very poorly.  what in particular provides
game-quality latency, or lack thereof?  with only 2g, i guess i can
understand the cache.  decent bandwidth would reduce complexity.  and
the network is flat?

randy

From niels=nanog at bakker.net  Sun Aug  2 11:56:07 2015
From: niels=nanog at bakker.net (Niels Bakker)
Date: Sun, 2 Aug 2015 13:56:07 +0200
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <m28u9u6i4h.wl%randy@psg.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net>
 <m28u9u6i4h.wl%randy@psg.com>
Message-ID: <20150802115607.GC4116@excession.tpb.net>

* randy at psg.com (Randy Bush) [Sun 02 Aug 2015, 13:37 CEST]:
>ietf, >1k people, easily fits in 10g, but tries to have two for 
>redundancy.  also no nat, no firewall, and even ipv6.  but absorbing 
>or combatting scans and other attacks cause complexity one would 
>prefer to avoid.  in praha, there was even a tkip attack, or so it 
>is believed; turned off tkip.

Didn't the IETF already deprecate TKIP?


>the quakecon net was explained very poorly.  what in particular 
>provides game-quality latency, or lack thereof?  with only 2g, i 
>guess i can understand the cache.  decent bandwidth would reduce 
>complexity.  and the network is flat?

Cabling up 4,400 ports does take a lot of effort, though.

The QuakeCon video was typical for a server guy talking about network: 
with a focus on the network periphery, i.e. some servers supporting 
the network.  I guess a tale of punching 300-odd patchpanels is not 
that captivating to everybody out there.


	-- Niels.

From shopik at inblock.ru  Sun Aug  2 12:02:20 2015
From: shopik at inblock.ru (Nikolay Shopik)
Date: Sun, 2 Aug 2015 15:02:20 +0300
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
Message-ID: <BCCC87F7-EEC2-4812-BF74-FFFD62E2106F@inblock.ru>

Steam moved to http streaming few years ago for exact that reason

> On 2 ???. 2015 ?., at 4:51, Steven Miano <mianosm at gmail.com> wrote:
> 
> historically steam/game downloads are not
> cahce'able

From sean at donelan.com  Sun Aug  2 12:08:11 2015
From: sean at donelan.com (Sean Donelan)
Date: Sun, 2 Aug 2015 08:08:11 -0400 (EDT)
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <20150802111722.GB4116@excession.tpb.net>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net>
Message-ID: <alpine.BSF.2.20.1508020743560.51062@cnex.qbaryna.pbz>

On Sun, 2 Aug 2015, Niels Bakker wrote:
> Also, 2 Gbps for 4,400 people?  Pretty lackluster compared to European 
> events.  30C3 had 100 Gbps to the conference building.  And no NAT: every 
> host got real IP addresses (IPv4 + IPv6).

Quakecon is essentially a giant LAN party.  Bring Your Own Computer 
(BYOC), and there are big gaming rigs at Quakecon, and compete on the LAN. 
There isn't that much Internet traffic.  There is only 100Mbps wired to
each gaming station.

I'm not a quake fanatic, I don't know what are the important network 
metrics for a good gaming experience.  But I assume the important metrics
are local, and they install a big central server complex in the center
of the room.  I'm assuming the critical lag is between the central
server and the competitors; not the Internet.   Otherwise they could
have all stayed home and played in their basements across the
Internet.  Latency is probably more important than bulk bandwidth.



From elfkin at gmail.com  Sun Aug  2 12:33:32 2015
From: elfkin at gmail.com (Harald F. Karlsen)
Date: Sun, 2 Aug 2015 14:33:32 +0200
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
Message-ID: <55BE0E1C.20807@gmail.com>

On 01.08.2015 21:27, Sean Donelan wrote:
> What Powers Quakecon | Network Operations Center Tour
> https://www.youtube.com/watch?v=mOv62lBdlXU
Cool stuff!

For reference here are the blog for the tech-crew at the worlds second 
largest LAN-party, The Gathering:
http://technical.gathering.org/

A few highlights:
* Over 12,000 Gigabit ports, 500 * 10Gigabit ports, 50 * 40Gigabit ports 
(not all utilized of course).
* Gigabit to all participants.
* Dual-stack public IPv4 and IPv6 to all participants.
* 30Gbit internet connection (upgradeable if needed).
* Zero-touch provisioning of all edge switches.

Most of the NMS and provisioning systems are made in-house and are 
available on github (https://github.com/tech-server/) and all 
configuration files are released to the public after each event on 
ftp://ftp.gathering.org (seems to be down at the moment).

-- 
Harald

From morrowc.lists at gmail.com  Sun Aug  2 15:32:00 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 2 Aug 2015 11:32:00 -0400
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <20150802115607.GC4116@excession.tpb.net>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net>
 <m28u9u6i4h.wl%randy@psg.com>
 <20150802115607.GC4116@excession.tpb.net>
Message-ID: <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>

On Sun, Aug 2, 2015 at 7:56 AM, Niels Bakker <niels=nanog at bakker.net> wrote:
> I guess a tale of punching 300-odd patchpanels is not that captivating to
> everybody out there.

I find this hard to believe.

:)

I was hoping for more 'how the network is built' (flat? segmented? any
security protections so competitors can't kill off their competition?)
and ideally some discussion of why the decisions made a difference.
(what tradeoffs were made and why?)

From rdobbins at arbor.net  Sun Aug  2 15:37:34 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sun, 02 Aug 2015 22:37:34 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net> <m28u9u6i4h.wl%randy@psg.com>
 <20150802115607.GC4116@excession.tpb.net>
 <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>
Message-ID: <679943E8-8EB9-4BEE-BDD7-992CCA5DFD7C@arbor.net>

On 2 Aug 2015, at 22:32, Christopher Morrow wrote:

> any security protections so competitors can't kill off their 
> competition?)

It would be interesting to learn whether they saw any DDoS attacks or 
cheating attempts during competitive play, or even casual 
non-competitive play amongst attendees.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From dave-nanog at pooserville.com  Sun Aug  2 15:44:39 2015
From: dave-nanog at pooserville.com (Dave Pooser)
Date: Sun, 02 Aug 2015 10:44:39 -0500
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <679943E8-8EB9-4BEE-BDD7-992CCA5DFD7C@arbor.net>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net>
 <m28u9u6i4h.wl%randy@psg.com>
 <20150802115607.GC4116@excession.tpb.net>
 <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>
 <679943E8-8EB9-4BEE-BDD7-992CCA5DFD7C@arbor.net>
Message-ID: <D1E3A416.333AA6%dave-lists@pooserville.com>

>>any security protections so competitors can't kill off their
>> competition?)
>
>It would be interesting to learn whether they saw any DDoS attacks or
>cheating attempts during competitive play, or even casual
>non-competitive play amongst attendees.

I wonder if that would be a reason for the relatively anemic 1Gb Internet
pipe-- making sure that a DDoS couldn't push enough packets through to
inconvenience the LAN party.

(Disclaimer: $DAYJOB did the audio/visual/lighting for QuakeCon but we had
nothing to do with the network and I was utterly uninvolved in any way,
so my speculation is based on no information obtained from outside my own
skull.)
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com



From rdobbins at arbor.net  Sun Aug  2 15:50:05 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sun, 02 Aug 2015 22:50:05 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <D1E3A416.333AA6%dave-lists@pooserville.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net> <m28u9u6i4h.wl%randy@psg.com>
 <20150802115607.GC4116@excession.tpb.net>
 <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>
 <679943E8-8EB9-4BEE-BDD7-992CCA5DFD7C@arbor.net>
 <D1E3A416.333AA6%dave-lists@pooserville.com>
Message-ID: <466B5BC3-04F0-47D2-BD37-BFC0315DC253@arbor.net>

On 2 Aug 2015, at 22:44, Dave Pooser wrote:

> I wonder if that would be a reason for the relatively anemic 1Gb 
> Internet
>
> pipe-- making sure that a DDoS couldn't push enough packets through to
> inconvenience the LAN party.

While increasing bandwidth is not a viable DDoS defense tactic, 
decreasing it isn't one, either.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From magicsata at gmail.com  Sun Aug  2 15:56:16 2015
From: magicsata at gmail.com (Alistair Mackenzie)
Date: Sun, 2 Aug 2015 16:56:16 +0100
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <466B5BC3-04F0-47D2-BD37-BFC0315DC253@arbor.net>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net>
 <m28u9u6i4h.wl%randy@psg.com>
 <20150802115607.GC4116@excession.tpb.net>
 <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>
 <679943E8-8EB9-4BEE-BDD7-992CCA5DFD7C@arbor.net>
 <D1E3A416.333AA6%dave-lists@pooserville.com>
 <466B5BC3-04F0-47D2-BD37-BFC0315DC253@arbor.net>
Message-ID: <CA+bbMksvFBUo0tqc77tFW=WpvhmcZ0pMnJFtBvA9m02DFzLRxQ@mail.gmail.com>

While increasing bandwidth to the endpoint isn't viable wouldn't increasing
the edge bandwidth out to the ISP be a start in the right direction?

I would assume this would a start to the problem if your attacks were
volumetric.

Once the bandwidth is there you can look at mitigation before it reaches
the endpoint, in this case the computers on the floor (assuming no NAT).
On 2 Aug 2015 16:51, "Roland Dobbins" <rdobbins at arbor.net> wrote:

> On 2 Aug 2015, at 22:44, Dave Pooser wrote:
>
> I wonder if that would be a reason for the relatively anemic 1Gb Internet
>>
>> pipe-- making sure that a DDoS couldn't push enough packets through to
>> inconvenience the LAN party.
>>
>
> While increasing bandwidth is not a viable DDoS defense tactic, decreasing
> it isn't one, either.
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
>

From nanog at ics-il.net  Sun Aug  2 15:56:48 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 2 Aug 2015 10:56:48 -0500 (CDT)
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <466B5BC3-04F0-47D2-BD37-BFC0315DC253@arbor.net>
Message-ID: <664735422.649.1438531041038.JavaMail.mhammett@ThunderFuck>

It's completely reasonable when the world at large is only secondary to the local, on-net operations. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Roland Dobbins" <rdobbins at arbor.net> 
To: "nanog list" <nanog at nanog.org> 
Sent: Sunday, August 2, 2015 10:50:05 AM 
Subject: Re: Quakecon: Network Operations Center tour 

On 2 Aug 2015, at 22:44, Dave Pooser wrote: 

> I wonder if that would be a reason for the relatively anemic 1Gb 
> Internet 
> 
> pipe-- making sure that a DDoS couldn't push enough packets through to 
> inconvenience the LAN party. 

While increasing bandwidth is not a viable DDoS defense tactic, 
decreasing it isn't one, either. 

----------------------------------- 
Roland Dobbins <rdobbins at arbor.net> 


From admin at coldnorthadmin.com  Sun Aug  2 16:10:37 2015
From: admin at coldnorthadmin.com (Laurent Dumont)
Date: Sun, 2 Aug 2015 12:10:37 -0400
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <m28u9u6i4h.wl%randy@psg.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net> <m28u9u6i4h.wl%randy@psg.com>
Message-ID: <55BE40FD.3000009@coldnorthadmin.com>

I recently wrapped up a 1300 players with gigabit connections where we 
had a single 5gig link. We never saturated the link and peaked at 
3.92Gbps for a new minutes. Bandwidth usage peaks on the first day and 
settles down after that (the event was during an entire weekend starting 
on friday). If I recall correctly, average was around 2Gpbs.

We did not have a steam/web cache and I expect it might reduce even more 
the actual load on actual BW usage.

On 8/2/2015 7:32 AM, Randy Bush wrote:
>> Also, 2 Gbps for 4,400 people?  Pretty lackluster compared to European
>> events.  30C3 had 100 Gbps to the conference building.  And no NAT:
>> every host got real IP addresses (IPv4 + IPv6).
> ietf, >1k people, easily fits in 10g, but tries to have two for
> redundancy.  also no nat, no firewall, and even ipv6.  but absorbing or
> combatting scans and other attacks cause complexity one would prefer to
> avoid.  in praha, there was even a tkip attack, or so it is  believed;
> turned off tkip.
>
> the quakecon net was explained very poorly.  what in particular provides
> game-quality latency, or lack thereof?  with only 2g, i guess i can
> understand the cache.  decent bandwidth would reduce complexity.  and
> the network is flat?
>
> randy


From rdobbins at arbor.net  Sun Aug  2 16:23:18 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sun, 02 Aug 2015 23:23:18 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <664735422.649.1438531041038.JavaMail.mhammett@ThunderFuck>
References: <664735422.649.1438531041038.JavaMail.mhammett@ThunderFuck>
Message-ID: <CC2099EB-2EE5-46ED-9DCC-F4FE5F5B95DB@arbor.net>

On 2 Aug 2015, at 22:56, Mike Hammett wrote:

> It's completely reasonable when the world at large is only secondary 
> to the local, on-net operations.

It has nothing to do with DDoS.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Sun Aug  2 16:25:32 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sun, 02 Aug 2015 23:25:32 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CA+bbMksvFBUo0tqc77tFW=WpvhmcZ0pMnJFtBvA9m02DFzLRxQ@mail.gmail.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net> <m28u9u6i4h.wl%randy@psg.com>
 <20150802115607.GC4116@excession.tpb.net>
 <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>
 <679943E8-8EB9-4BEE-BDD7-992CCA5DFD7C@arbor.net>
 <D1E3A416.333AA6%dave-lists@pooserville.com>
 <466B5BC3-04F0-47D2-BD37-BFC0315DC253@arbor.net>
 <CA+bbMksvFBUo0tqc77tFW=WpvhmcZ0pMnJFtBvA9m02DFzLRxQ@mail.gmail.com>
Message-ID: <E78A0DD2-A09F-41AB-9594-A6ACB3352B80@arbor.net>


On 2 Aug 2015, at 22:56, Alistair Mackenzie wrote:

> I would assume this would a start to the problem if your attacks were
> volumetric.

In a world of 430gb/sec reflection/amplification DDoS attacks, not 
really.

;>

Just increasing bandwidth has never been a viable DDoS defense tactic, 
due to the extreme asymmetry of resource ratios in favor of the 
attackers.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From swmike at swm.pp.se  Sun Aug  2 16:43:41 2015
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sun, 2 Aug 2015 18:43:41 +0200 (CEST)
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <D1E3A416.333AA6%dave-lists@pooserville.com>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
 <CAL9jLaajVK7hNTGU=fBovUSb9uZr1mHjJsB+w+zczyPFcXEd-g@mail.gmail.com>
 <CACkP6kkGLkcUVh68Ocq8bNKZNU2kN=q1Z=z10G-Rzv3KSszG3w@mail.gmail.com>
 <20150802111722.GB4116@excession.tpb.net>
 <m28u9u6i4h.wl%randy@psg.com> <20150802115607.GC4116@excession.tpb.net>
 <CAL9jLaaYoKTfA_6ideRcKVbUE3G2A8zPQxA+uY_2nZsjJDGLYg@mail.gmail.com>
 <679943E8-8EB9-4BEE-BDD7-992CCA5DFD7C@arbor.net>
 <D1E3A416.333AA6%dave-lists@pooserville.com>
Message-ID: <alpine.DEB.2.02.1508021840590.11810@uplift.swm.pp.se>

On Sun, 2 Aug 2015, Dave Pooser wrote:

> I wonder if that would be a reason for the relatively anemic 1Gb 
> Internet pipe-- making sure that a DDoS couldn't push enough packets 
> through to inconvenience the LAN party.

I was involved in delivering 1GigE to Dreamhack in 2001 which at the time 
(if I remember correctly), 4500 computers that participants brought with 
them.

Usually these events nowadays tend to use 5-20 gigabit/s for that amount 
of people, so 2x1GE is just not enough. Already in 2001 that GigE was 
fully loaded after 1-2 days.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From nanog at ics-il.net  Sun Aug  2 16:49:29 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 2 Aug 2015 11:49:29 -0500 (CDT)
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CC2099EB-2EE5-46ED-9DCC-F4FE5F5B95DB@arbor.net>
Message-ID: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>

It most certainly does. If the core of the mission is local LAN play and your Internet connection fills up.... who gives a shit? The games play on. If your 500 megabit corporate connection gets a 20 terabit DDoS, your RDP session to the finance department will continue to hum along just fine. 




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

----- Original Message -----

From: "Roland Dobbins" <rdobbins at arbor.net> 
To: "nanog list" <nanog at nanog.org> 
Sent: Sunday, August 2, 2015 11:23:18 AM 
Subject: Re: Quakecon: Network Operations Center tour 

On 2 Aug 2015, at 22:56, Mike Hammett wrote: 

> It's completely reasonable when the world at large is only secondary 
> to the local, on-net operations. 

It has nothing to do with DDoS. 

----------------------------------- 
Roland Dobbins <rdobbins at arbor.net> 


From rdobbins at arbor.net  Sun Aug  2 17:03:08 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 00:03:08 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
Message-ID: <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>

On 2 Aug 2015, at 23:49, Mike Hammett wrote:

> If the core of the mission is local LAN play and your Internet 
> connection fills up

You're assuming the DDoS attack originates from outside the local 
network(s).  I was curious as to whether they'd seen any *internal* DDoS 
attacks.

And again, external bandwidth doesn't matter for externally-sourced DDoS 
attacks.  If the attacker wishes to do so, he'll completely overwhelm 
your transit bandwidth.

> .... who gives a shit? The games play on.

No, they don't, if they require a connection across the Internet to game 
servers for matchmaking/auth purposes, etc.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From jra at baylink.com  Sun Aug  2 18:54:45 2015
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 02 Aug 2015 14:54:45 -0400
Subject: Bright House IMAP highwater warning real?
In-Reply-To: <4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>
References: <4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>
Message-ID: <BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>

Any brighthouse email admins on the list? My sister got the following high water warning message, with the included headers which, since they appear to include no Received: headers, look like they actually came from brighthouse's email cluster. 

If this is a real Bright House warning message, somebody should be flogged. Teaching people which messages is to believe is hard enough...

Cheers,
-- jra


-------- Original Message --------
Subject: Re: Fwd: ATTENTION: High Water Mark Notification, bytes in the mailbox!

I lied. The header to yours - which I finally found - is nice and long.
 the header on this one is

Return-Path: <>
From: admin
Subject: ATTENTION: High Water Mark Notification, bytes in the mailbox!
Date: Sun, 2 Aug 2015 06:22:44 +0000
Message-ID: e31468ce-38de-11e5-b0a6-17507733086b

>>-----Original Message-----
>>From: admin
>>Sent: Sun, 02 Aug 2015 2:22 AM
>>Subject: ATTENTION: High Water Mark Notification, bytes in the
>mailbox!
>>
>>Your mailbox is over the high water mark.
>>Please delete some messages from your mailbox.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From frnkblk at iname.com  Sun Aug  2 19:44:35 2015
From: frnkblk at iname.com (Frank Bulk)
Date: Sun, 2 Aug 2015 14:44:35 -0500
Subject: Bright House IMAP highwater warning real?
In-Reply-To: <BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>
References: <4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>
 <BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>
Message-ID: <000601d0cd5b$aa7f1e80$ff7d5b80$@iname.com>

What do you think their message should say?  We struggled over this, too, and settled on some soft language, included information on how to purchase more storage, and also provided our email address and phone numbers.

Frank

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth
Sent: Sunday, August 02, 2015 1:55 PM
To: nanog at nanog.org
Subject: Bright House IMAP highwater warning real?

Any brighthouse email admins on the list? My sister got the following high water warning message, with the included headers which, since they appear to include no Received: headers, look like they actually came from brighthouse's email cluster. 

If this is a real Bright House warning message, somebody should be flogged. Teaching people which messages is to believe is hard enough...

Cheers,
-- jra


-------- Original Message --------
Subject: Re: Fwd: ATTENTION: High Water Mark Notification, bytes in the mailbox!

I lied. The header to yours - which I finally found - is nice and long.
 the header on this one is

Return-Path: <>
From: admin
Subject: ATTENTION: High Water Mark Notification, bytes in the mailbox!
Date: Sun, 2 Aug 2015 06:22:44 +0000
Message-ID: e31468ce-38de-11e5-b0a6-17507733086b

>>-----Original Message-----
>>From: admin
>>Sent: Sun, 02 Aug 2015 2:22 AM
>>Subject: ATTENTION: High Water Mark Notification, bytes in the
>mailbox!
>>
>>Your mailbox is over the high water mark.
>>Please delete some messages from your mailbox.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.



From jra at baylink.com  Sun Aug  2 19:53:50 2015
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 02 Aug 2015 15:53:50 -0400
Subject: Bright House IMAP highwater warning real?
In-Reply-To: <000601d0cd5b$aa7f1e80$ff7d5b80$@iname.com>
References: <4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>
 <BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>
 <000601d0cd5b$aa7f1e80$ff7d5b80$@iname.com>
Message-ID: <548CC203-E345-45CF-9C3C-37A0786E94A8@baylink.com>

I think the body text of the message should identify it as coming from the Bright House email system? I think it should be written in standard USAdian English, which that is decidedly not.

Or perhaps the problem is that that subject line was supposed to be parameterized, and the number of bytes is missing for some reason. But in any event that is a common message to spoof, and the more bits of identity that are in it the harder it is to do so. That message format has almost zero bit of provider-identifiable data.

"""
Your Bright House Networks IMAP email storage for user at domain.com is at 490MB, approaching your quota of 500MB.

IMAP email permits you to access all your mail folders by storing them on the mail server, but because of this, all mail in your folders contributes to your storage limit.

You can delete messages to reduce your storage, or move them to your PC. If you delete them, or have already deleted them, you usually must 'compact' each folder to reclaim the extra space.

Alternatively, you can contact Customer Care to see about having your quota increased.
"""

Cheers,
-- jra

On August 2, 2015 3:44:35 PM EDT, Frank Bulk <frnkblk at iname.com> wrote:
>What do you think their message should say?  We struggled over this,
>too, and settled on some soft language, included information on how to
>purchase more storage, and also provided our email address and phone
>numbers.
>
>Frank
>
>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth
>Sent: Sunday, August 02, 2015 1:55 PM
>To: nanog at nanog.org
>Subject: Bright House IMAP highwater warning real?
>
>Any brighthouse email admins on the list? My sister got the following
>high water warning message, with the included headers which, since they
>appear to include no Received: headers, look like they actually came
>from brighthouse's email cluster. 
>
>If this is a real Bright House warning message, somebody should be
>flogged. Teaching people which messages is to believe is hard enough...
>
>Cheers,
>-- jra
>
>
>-------- Original Message --------
>Subject: Re: Fwd: ATTENTION: High Water Mark Notification, bytes in the
>mailbox!
>
>I lied. The header to yours - which I finally found - is nice and long.
> the header on this one is
>
>Return-Path: <>
>From: admin
>Subject: ATTENTION: High Water Mark Notification, bytes in the mailbox!
>Date: Sun, 2 Aug 2015 06:22:44 +0000
>Message-ID: e31468ce-38de-11e5-b0a6-17507733086b
>
>>>-----Original Message-----
>>>From: admin
>>>Sent: Sun, 02 Aug 2015 2:22 AM
>>>Subject: ATTENTION: High Water Mark Notification, bytes in the
>>mailbox!
>>>
>>>Your mailbox is over the high water mark.
>>>Please delete some messages from your mailbox.
>-- 
>Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From tqr2813d376cjozqap1l at tutanota.com  Sun Aug  2 19:56:24 2015
From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com)
Date: Sun, 2 Aug 2015 19:56:24 +0000 (UTC)
Subject: Bright House IMAP highwater warning real?
In-Reply-To: <000601d0cd5b$aa7f1e80$ff7d5b80$@iname.com>
References: <4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>
 <<4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>>
 <BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>
 <<BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>>
 <000601d0cd5b$aa7f1e80$ff7d5b80$@iname.com>
Message-ID: <Jvjz8IG----0@tutanota.com>

- Tell user that they're nearly out of storage. Specify how much they've used 
and how much they have total. Perhaps include a percentage
- Mention that they could delete email that isn't needed to recover space.
- (optional but nice) Show the subject and sender of the biggest
messages
- (optional but nice) Mention how big the trash folder is (with percentage) 
and tell them they could empty it
- Tell user to visit website or call if they have any questions or want to 
add more storage

None of this 'high water mark' crap

2. Aug 2015 19:44 by frnkblk at iname.com:


> What do you think their message should say?  We struggled over this, too, 
> and settled on some soft language, included information on how to purchase 
> more storage, and also provided our email address and phone numbers.
>
> Frank
>
> -----Original Message-----
> From: NANOG [> mailto:nanog-bounces at nanog.org> ] On Behalf Of Jay Ashworth
> Sent: Sunday, August 02, 2015 1:55 PM
> To: > nanog at nanog.org
> Subject: Bright House IMAP highwater warning real?
>
> Any brighthouse email admins on the list? My sister got the following high 
> water warning message, with the included headers which, since they appear 
> to include no Received: headers, look like they actually came from 
> brighthouse's email cluster.
>
> If this is a real Bright House warning message, somebody should be flogged. 
> Teaching people which messages is to believe is hard enough...
>
> Cheers,
> -- jra
>
>
> -------- Original Message --------
> Subject: Re: Fwd: ATTENTION: High Water Mark Notification, bytes in the 
> mailbox!
>
> I lied. The header to yours - which I finally found - is nice and long.
>  the header on this one is
>
> Return-Path: <>
> From: admin
> Subject: ATTENTION: High Water Mark Notification, bytes in the mailbox!
> Date: Sun, 2 Aug 2015 06:22:44 +0000
> Message-ID: e31468ce-38de-11e5-b0a6-17507733086b
>
> >>-----Original Message-----
> >>From: admin
> >>Sent: Sun, 02 Aug 2015 2:22 AM
> >>Subject: ATTENTION: High Water Mark Notification, bytes in the
> >mailbox!

> >>Your mailbox is over the high water mark.
> >>Please delete some messages from your mailbox.
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From jra at baylink.com  Sun Aug  2 20:15:44 2015
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 02 Aug 2015 16:15:44 -0400
Subject: Windows 10 Release
In-Reply-To: <495D0934DA46854A9CA758393724D590BBE7CC@NI-MAIL02.nii.ads>
References: <92dd60f4f62646ad814ac32179db95c8@flhsi.com>
 <20150728220404.GA4116@excession.tpb.net>
 <92CF8900-4301-45E0-838D-D9F28D7838CC@xyonet.com>
 <495D0934DA46854A9CA758393724D590BBE7CC@NI-MAIL02.nii.ads>
Message-ID: <5FE0FD32-B717-4B4E-9A96-1AC226362388@baylink.com>

An article in VARGuy said they'd booked 40 Tb/s of capacity from Akamai, Limelight, and four or five other CDNs that I did not recognize by name.

I presume each machine will have to contact at least one machine at microsoft.com to confirm signatures on downloaded packages, et alia.

- jra

On July 28, 2015 8:09:52 PM EDT, Erik Sundberg <ESundberg at nitelusa.com> wrote:
>Does anyone know if Microsoft will be hosting the downloads from there
>ASN 8075 or from an CDN Provider like Akamai?
>
>
>
>-----Original Message-----
>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Curtis
>Maurand
>Sent: Tuesday, July 28, 2015 6:43 PM
>To: Niels Bakker <niels=nanog at bakker.net>; nanog at nanog.org
>Subject: Re: Windows 10 Release
>
>Microsoft tells me 3.2 GB for win 10 pro 64 bit.
>
>On July 28, 2015 6:04:04 PM EDT, Niels Bakker <niels=nanog at bakker.net>
>wrote:
>>* nick at flhsi.com (Nick Olsen) [Tue 28 Jul 2015, 22:46 CEST]:
>>>Being a 3-4GB download. Each device is moving more data than any
>Apple
>>
>>>update ever did.
>>
>>I'm not so sure of that.  The 10.9 install image clocked in at 4.9 GB,
>>and the Mac App Store for 10.10 Yosemite says "Size: 5.67 GB";
>>http://www.microsoft.com/en-us/windows/features says "3GB download
>>required" in the small print at the bottom.
>>
>>
>>       -- Niels.
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>________________________________
>
>CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents,
>files or previous e-mail messages attached to it may contain
>confidential information that is legally privileged. If you are not the
>intended recipient, or a person responsible for delivering it to the
>intended recipient, you are hereby notified that any disclosure,
>copying, distribution or use of any of the information contained in or
>attached to this transmission is STRICTLY PROHIBITED. If you have
>received this transmission in error please notify the sender
>immediately by replying to this e-mail. You must destroy the original
>transmission and its attachments without reading or saving in any
>manner. Thank you.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From josh.hoppes at gmail.com  Sun Aug  2 21:36:41 2015
From: josh.hoppes at gmail.com (Josh Hoppes)
Date: Sun, 2 Aug 2015 16:36:41 -0500
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
Message-ID: <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>

Not that often you see a bunch of people talking about a video you're
in, especially so on NANOG. So here goes.

BYOC is around 2700 seats. Total attendance was around 11,000.

2Gbps has been saturated at some point every year we have had it.
Additional bandwidth is definitely a serious consideration going
forward. It is a lot better than the 45mbps or less we dealt with 2010
and prior, but better doesn't mean good enough. Many games these days
do depend upon online services, and forced us to look for options.
AT&T has been sponsoring since then and we do appreciate it.

We have had the potential for DDoS attacks on our minds. Our first
option in those cases is blackhole announcements to the carrier for
the targeted /32. AT&T did provide address space for us to use so the
BYOC was using public IPs, and hopefully the impact of blackholing a
single IP could be made minimal. Thankfully we have not yet been
targeted, and we can only keep hoping it stays that way.

We haven't tackled IPv6 yet since it adds complexity that our primary
focus doesn't significantly benefit from yet since most games just
don't support it. Our current table switches don't have an RA guard,
and will probably require replacement to get ones that are capable.

We also re-designed the LAN back in 2011 to break up the giant single
broadcast domain down to a subnet per table switch. This has
definitely gotten us some flack from the BYOC since it breaks their
LAN browsers, but we thought a stable network was more important with
how much games have become dependent on stable Internet connectivity.
Still trying to find a good way to provide a middle ground for
attendees on that one, but I'm sure everyone here would understand how
insane a single broadcast domain with 2000+ hosts that aren't under
your control is. We have tried to focus on latency on the LAN, however
when so many games are no longer LAN oriented Internet connectivity
became a dominant issue.

Some traffic is routed out a separate lower capacity connection to
keep saturation issues from impacting it during the event.

Squid and nginx do help with caching, and thankfully Steam migrated to
a http distribution method and allows for easy caching. Some other
services make it more difficult, but we try our best. Before Steam
changed to http distribution there were a few years they helped in
providing a local mirror but that seems to have been discontinued with
the migration to http. The cache pushed a little over 4Gbps of traffic
at peak at the event.

The core IT team which handles the network (L2 and above) is about 9
volunteers. The physical infrastructure is our IP & D team, which gets
a huge team of volunteers put together in order to get that 13 miles
of cable ready between Monday and Wednesday. The event is very
volunteer driven, like many LAN parties across the planet. We try to
reuse cable from year to year, including loading up the table runs
onto a pallet to be used in making new cables out of in future years.

I imagine I haven't answered everyone's questions, but hopefully that
fills in some of the blanks.

If this has anyone considering sponsorship interest in the event the
contact email is sponsors(at)quakecon.org. Information is also
available on the website http://www.quakecon.org/.

From randy at psg.com  Sun Aug  2 21:59:26 2015
From: randy at psg.com (Randy Bush)
Date: Mon, 03 Aug 2015 06:59:26 +0900
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
Message-ID: <m2380173nl.wl%randy@psg.com>

josh,

thanks for the more technical scoop.  now i get it a bit better.

> We also re-designed the LAN back in 2011 to break up the giant single
> broadcast domain down to a subnet per table switch.

so it is heavily routed using L3 on the core 'switches'?  makes a lot of
sense.

randy

From nick at foobar.org  Sun Aug  2 22:18:14 2015
From: nick at foobar.org (Nick Hilliard)
Date: Sun, 2 Aug 2015 23:18:14 +0100
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <m2380173nl.wl%randy@psg.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <m2380173nl.wl%randy@psg.com>
Message-ID: <55BE9726.8020701@foobar.org>

On 02/08/2015 22:59, Randy Bush wrote:
> so it is heavily routed using L3 on the core 'switches'?  makes a lot of
> sense.

Lots of switches will happily forward layer 3 packets.

Nick


From josh.hoppes at gmail.com  Sun Aug  2 22:29:46 2015
From: josh.hoppes at gmail.com (Josh Hoppes)
Date: Sun, 2 Aug 2015 17:29:46 -0500
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <m2380173nl.wl%randy@psg.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <m2380173nl.wl%randy@psg.com>
Message-ID: <CAMcDhon4W1uW9kvOy01uhEJCs3D6ZZWS2cd+XiWjeKa3+9UoBg@mail.gmail.com>

On Sun, Aug 2, 2015 at 4:59 PM, Randy Bush <randy at psg.com> wrote:
> josh,
>
> thanks for the more technical scoop.  now i get it a bit better.
>
>> We also re-designed the LAN back in 2011 to break up the giant single
>> broadcast domain down to a subnet per table switch.
>
> so it is heavily routed using L3 on the core 'switches'?  makes a lot of
> sense.

Single core switch, the Cisco 6509 VE in the video, handles routing
between subnets. Table switches have an IP for management and
monitoring. We have some 3750Gs for additional routing in other parts
of the event.

From randy at psg.com  Sun Aug  2 22:30:46 2015
From: randy at psg.com (Randy Bush)
Date: Mon, 03 Aug 2015 07:30:46 +0900
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <55BE9726.8020701@foobar.org>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <m2380173nl.wl%randy@psg.com> <55BE9726.8020701@foobar.org>
Message-ID: <m2y4ht5nmx.wl%randy@psg.com>

>> so it is heavily routed using L3 on the core 'switches'?  makes a lot
>> of sense.
> Lots of switches will happily forward layer 3 packets.

and a lot of so-called switches will happily *route* at L3, which is i
think the point.  in this case, heavily subnetting a LAN, it makes a lot
of sense.

otoh, i did not believe in the fad of using 65xxs at the bgp global
edge.  while it was temporarily cheap, two years later not a lot of folk
had that many boats which needed anchoring.

randy

From nick at foobar.org  Sun Aug  2 22:57:36 2015
From: nick at foobar.org (Nick Hilliard)
Date: Sun, 2 Aug 2015 23:57:36 +0100
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <m2y4ht5nmx.wl%randy@psg.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <m2380173nl.wl%randy@psg.com> <55BE9726.8020701@foobar.org>
 <m2y4ht5nmx.wl%randy@psg.com>
Message-ID: <55BEA060.5040905@foobar.org>

On 02/08/2015 23:30, Randy Bush wrote:
> otoh, i did not believe in the fad of using 65xxs at the bgp global
> edge.  while it was temporarily cheap, two years later not a lot of folk
> had that many boats which needed anchoring.

A juniper EX9200 is a switch and a cisco sup2t box is a router.  The vendor
said it so it must be true.

As anchors, I would be hard put to make a choice between a 6500 and a 7500,
which was a fine router in its day but alas only had a useful lifetime of a
small number of years.  Obsolescence happens.

The distinction between layer 2 and layer 3 capable kit is not that
important these days.  What's important is whether the device's packet or
frame forwarding capabilities are a good match for the expected workload
and that the total operating cost over the depreciation period works.

Nick



From jason.leblanc at infusionsoft.com  Sun Aug  2 19:59:45 2015
From: jason.leblanc at infusionsoft.com (Jason LeBlanc)
Date: Sun, 2 Aug 2015 19:59:45 +0000
Subject: GoDaddy : DDoS :: Contact
Message-ID: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>

My company is being DDoS'd by a single IP from a GoDaddy customer.

I havent had success with the abuse at godaddy.com email.  Was hoping someone
that could help might be watching the list and could contact me off-list.


//Jason


From tqr2813d376cjozqap1l at tutanota.com  Sun Aug  2 23:16:27 2015
From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com)
Date: Sun, 2 Aug 2015 23:16:27 +0000 (UTC)
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
Message-ID: <Jvkgvm-----0@tutanota.com>

2. Aug 2015 19:59 by jason.leblanc at infusionsoft.com:


> My company is being DDoS'd by a single IP from a GoDaddy customer.
>




DDoS = multiple IPs

DoS = single IP


From mel at beckman.org  Sun Aug  2 23:20:24 2015
From: mel at beckman.org (Mel Beckman)
Date: Sun, 2 Aug 2015 23:20:24 +0000
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
Message-ID: <5B63E462-D883-4236-9871-D2624C53A503@beckman.org>

Not to be difficult, but how can it be a DDoS attack if it?s coming from a single IP? Normally you would just block this IP at your borders or ask your upstreams to do so before it consumes your bandwidth. You still want to get GoDaddy to address the problem, of course, but you should do that via their abuse at godaddy.com<mailto:abuse at godaddy.com> contact, or their abuse page at https://supportcenter.godaddy.com/AbuseReport/Index (submit via the ?malware? button).

 -mel

On Aug 2, 2015, at 12:59 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>> wrote:

My company is being DDoS'd by a single IP from a GoDaddy customer.

I havent had success with the abuse at godaddy.com<mailto:abuse at godaddy.com> email.  Was hoping someone
that could help might be watching the list and could contact me off-list.


//Jason



From jhellenthal at dataix.net  Sun Aug  2 23:41:45 2015
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Sun, 2 Aug 2015 18:41:45 -0500
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
Message-ID: <ED7380D2-94C7-49FB-B602-90588F566F2B@dataix.net>

Just block it 

-- 
 Jason Hellenthal
 JJH48-ARIN

On Aug 2, 2015, at 14:59, Jason LeBlanc <jason.leblanc at infusionsoft.com> wrote:

My company is being DDoS'd by a single IP from a GoDaddy customer.

I havent had success with the abuse at godaddy.com email.  Was hoping someone
that could help might be watching the list and could contact me off-list.


//Jason


From jason.leblanc at infusionsoft.com  Mon Aug  3 00:17:51 2015
From: jason.leblanc at infusionsoft.com (Jason LeBlanc)
Date: Mon, 3 Aug 2015 00:17:51 +0000
Subject: GoDaddy : DoS :: Contact
Message-ID: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>

Thanks Mel.  You are not being difficult, I meant DoS.  The network I inherited doesn?t have BGP yet so I have asked our upstream to blackhole it and I emailed abuse neither have happened yet.  I do block it but that?s after it hits our side.

//Jason

From: Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>>
Date: Sunday, August 2, 2015 at 4:20 PM
To: Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>>
Cc: NANOG <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: GoDaddy : DDoS :: Contact

Not to be difficult, but how can it be a DDoS attack if it?s coming from a single IP? Normally you would just block this IP at your borders or ask your upstreams to do so before it consumes your bandwidth. You still want to get GoDaddy to address the problem, of course, but you should do that via their abuse at godaddy.com<mailto:abuse at godaddy.com> contact, or their abuse page at https://supportcenter.godaddy.com/AbuseReport/Index (submit via the ?malware? button).

 -mel

On Aug 2, 2015, at 12:59 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>> wrote:

My company is being DDoS'd by a single IP from a GoDaddy customer.

I havent had success with the abuse at godaddy.com<mailto:abuse at godaddy.com> email.  Was hoping someone
that could help might be watching the list and could contact me off-list.


//Jason



From mel at beckman.org  Mon Aug  3 00:56:02 2015
From: mel at beckman.org (Mel Beckman)
Date: Mon, 3 Aug 2015 00:56:02 +0000
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
Message-ID: <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>

Blackholing isn't what you want. That will still permit his source IP into your network, and only blackhole replies from your network, so the attack will still consume bandwidth. What you should request is a source IP ACL blocking that address at your upstream' border.

BGP is no help in these situations, unless you use a BGP-based DDoS protection service.

 -mel beckman

On Aug 2, 2015, at 5:17 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>> wrote:

Thanks Mel.  You are not being difficult, I meant DoS.  The network I inherited doesn't have BGP yet so I have asked our upstream to blackhole it and I emailed abuse neither have happened yet.  I do block it but that's after it hits our side.

//Jason

From: Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>>
Date: Sunday, August 2, 2015 at 4:20 PM
To: Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>>
Cc: NANOG <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: GoDaddy : DDoS :: Contact

Not to be difficult, but how can it be a DDoS attack if it's coming from a single IP? Normally you would just block this IP at your borders or ask your upstreams to do so before it consumes your bandwidth. You still want to get GoDaddy to address the problem, of course, but you should do that via their abuse at godaddy.com<mailto:abuse at godaddy.com> contact, or their abuse page at https://supportcenter.godaddy.com/AbuseReport/Index (submit via the "malware" button).

 -mel

On Aug 2, 2015, at 12:59 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>> wrote:

My company is being DDoS'd by a single IP from a GoDaddy customer.

I havent had success with the abuse at godaddy.com<mailto:abuse at godaddy.com> email.  Was hoping someone
that could help might be watching the list and could contact me off-list.


//Jason



From morrowc.lists at gmail.com  Mon Aug  3 01:46:36 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 2 Aug 2015 21:46:36 -0400
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <55BEA060.5040905@foobar.org>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <m2380173nl.wl%randy@psg.com> <55BE9726.8020701@foobar.org>
 <m2y4ht5nmx.wl%randy@psg.com> <55BEA060.5040905@foobar.org>
Message-ID: <CAL9jLaYn3nYk_3Uc3n4Vt91ko70oKpjMnjH2DJkc2Yq8FYrfwA@mail.gmail.com>

On Sun, Aug 2, 2015 at 6:57 PM, Nick Hilliard <nick at foobar.org> wrote:
> As anchors, I would be hard put to make a choice between a 6500 and a 7500,
> which was a fine router in its day but alas only had a useful lifetime of a
> small number of years.  Obsolescence happens.

isn't some of L3's edge still 7500's? I think some of 703/702's edges
are still 7500's even.

From morrowc.lists at gmail.com  Mon Aug  3 01:47:57 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 2 Aug 2015 21:47:57 -0400
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CAL9jLaYn3nYk_3Uc3n4Vt91ko70oKpjMnjH2DJkc2Yq8FYrfwA@mail.gmail.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <m2380173nl.wl%randy@psg.com> <55BE9726.8020701@foobar.org>
 <m2y4ht5nmx.wl%randy@psg.com> <55BEA060.5040905@foobar.org>
 <CAL9jLaYn3nYk_3Uc3n4Vt91ko70oKpjMnjH2DJkc2Yq8FYrfwA@mail.gmail.com>
Message-ID: <CAL9jLaaVghjTgc9EfNSvXaR0ye2S+e_sJ6Ap6TFNhiMWfR1L_g@mail.gmail.com>

On Sun, Aug 2, 2015 at 9:46 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> On Sun, Aug 2, 2015 at 6:57 PM, Nick Hilliard <nick at foobar.org> wrote:
>> As anchors, I would be hard put to make a choice between a 6500 and a 7500,
>> which was a fine router in its day but alas only had a useful lifetime of a
>> small number of years.  Obsolescence happens.
>
> isn't some of L3's edge still 7500's? I think some of 703/702's edges
> are still 7500's even.

"Last Date of Support:
HW
The last date to receive service and support for the product. After
this date, all support services for the product are unavailable, and
the product becomes obsolete.
December 31, 2012"

oh .. maybe they really are all gone :)

From jra at baylink.com  Mon Aug  3 03:19:02 2015
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 02 Aug 2015 23:19:02 -0400
Subject: Did *bufferbloat* cause the 2010 flashcrash?
Message-ID: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>

This guy seems to think so, and his arguments seem pretty convincing to me, but I don't understand the financial system as well as I might.

yarchive.net/blog/computers/flash_crash.html

Gettys is namechecked in the piece.

Cheers,
-- jra
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From rdobbins at arbor.net  Mon Aug  3 03:52:10 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 10:52:10 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CAL9jLaaVghjTgc9EfNSvXaR0ye2S+e_sJ6Ap6TFNhiMWfR1L_g@mail.gmail.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <m2380173nl.wl%randy@psg.com> <55BE9726.8020701@foobar.org>
 <m2y4ht5nmx.wl%randy@psg.com> <55BEA060.5040905@foobar.org>
 <CAL9jLaYn3nYk_3Uc3n4Vt91ko70oKpjMnjH2DJkc2Yq8FYrfwA@mail.gmail.com>
 <CAL9jLaaVghjTgc9EfNSvXaR0ye2S+e_sJ6Ap6TFNhiMWfR1L_g@mail.gmail.com>
Message-ID: <E096A160-BA17-4040-A632-1A81FED25635@arbor.net>

On 3 Aug 2015, at 8:47, Christopher Morrow wrote:

> oh .. maybe they really are all gone :)

People still run things long after EoS, heh.

A 6500 *with a Sup2T* is OK at the edge, for now - it has decent ASICs 
which support critical edge features, unlike its predecessors.  Myself, 
I'd much rather use an ASR9K or CRS (I don't know much about Juniper 
routers) as an edge device.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Mon Aug  3 03:54:03 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 10:54:03 +0700
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <Jvkgvm-----0@tutanota.com>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
 <Jvkgvm-----0@tutanota.com>
Message-ID: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>

On 3 Aug 2015, at 6:16, tqr2813d376cjozqap1l at tutanota.com wrote:

> DDoS = multiple IPs
>
> DoS = single IP

It seems most people colloquially use DDoS for both, and reserve DoS for 
magic-packet blocking exploits like the latest BIND CVE, FYI.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From tqr2813d376cjozqap1l at tutanota.com  Mon Aug  3 03:58:31 2015
From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com)
Date: Mon, 3 Aug 2015 03:58:31 +0000 (UTC)
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
 <Jvkgvm-----0@tutanota.com> <<Jvkgvm-----0@tutanota.com>>
 <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
Message-ID: <JvlhUPV----0@tutanota.com>

3. Aug 2015 03:54 by rdobbins at arbor.net:


> On 3 Aug 2015, at 6:16, > tqr2813d376cjozqap1l at tutanota.com>  wrote:
>
>> DDoS = multiple IPs
>>
>> DoS = single IP
>
> It seems most people colloquially use DDoS for both, and reserve DoS for 
> magic-packet blocking exploits like the latest BIND CVE, FYI.
>




Then they are mistaken, unfortunately.


From rdobbins at arbor.net  Mon Aug  3 04:00:13 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 11:00:13 +0700
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <JvlhUPV----0@tutanota.com>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
 <Jvkgvm-----0@tutanota.com> <<Jvkgvm-----0@tutanota.com>
 <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net> <JvlhUPV----0@tutanota.com>
Message-ID: <52F3C3CB-ED7A-4242-8E87-D40DFA1513E5@arbor.net>


On 3 Aug 2015, at 10:58, tqr2813d376cjozqap1l at tutanota.com wrote:

> Then they are mistaken, unfortunately.

Bring pedantic for its own sake, when there's little possibility of 
confusion, isn't really constructive.  Everyone, including you, knew 
what he meant.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From Valdis.Kletnieks at vt.edu  Mon Aug  3 04:20:23 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 03 Aug 2015 00:20:23 -0400
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: Your message of "Mon, 03 Aug 2015 03:58:31 -0000."
 <JvlhUPV----0@tutanota.com>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
 <Jvkgvm-----0@tutanota.com> <<Jvkgvm-----0@tutanota.com>>
 <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <JvlhUPV----0@tutanota.com>
Message-ID: <131048.1438575623@turing-police.cc.vt.edu>

On Mon, 03 Aug 2015 03:58:31 -0000, tqr2813d376cjozqap1l at tutanota.com said:

> > It seems most people colloquially use DDoS for both, and reserve DoS for
> > magic-packet blocking exploits like the latest BIND CVE, FYI.

> Then they are mistaken, unfortunately.

Feel free to try to reclaim the old meaning of the word "hacker" while
you're at it.  That ship sailed long ago, and so has the DoS/DDoS distinction.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150803/85c2fcf0/attachment.pgp>

From tqr2813d376cjozqap1l at tutanota.com  Mon Aug  3 04:22:50 2015
From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com)
Date: Mon, 3 Aug 2015 04:22:50 +0000 (UTC)
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <131048.1438575623@turing-police.cc.vt.edu>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
 <Jvkgvm-----0@tutanota.com> <<Jvkgvm-----0@tutanota.com>>
 <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net> <JvlhUPV----0@tutanota.com>
 <Your message of "Mon, 03 Aug 2015 03:58:31 -0000."
 <JvlhUPV----0@tutanota.com>> <131048.1438575623@turing-police.cc.vt.edu>
Message-ID: <Jvln2pD----0@tutanota.com>

3. Aug 2015 04:20 by Valdis.Kletnieks at vt.edu:
On Mon, 03 Aug 2015 03:58:31 -0000, tqr2813d376cjozqap1l at tutanota.com said:

>> > It seems most people colloquially use DDoS for both, and reserve DoS for
>> > magic-packet blocking exploits like the latest BIND CVE, FYI.
>> Then they are mistaken, unfortunately.
>
> Feel free to try to reclaim the old meaning of the word "hacker" while
> you're at it.  That ship sailed long ago, and so has the DoS/DDoS 
> distinction.




I suppose you're right. Let the 'wordification' of? DDoS continue.. it 
certainly isn't an acronym anymore.


From johnl at iecc.com  Mon Aug  3 05:10:42 2015
From: johnl at iecc.com (John Levine)
Date: 3 Aug 2015 05:10:42 -0000
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
Message-ID: <20150803051042.11782.qmail@ary.lan>

>> DDoS = multiple IPs
>>
>> DoS = single IP
>
>It seems most people colloquially use DDoS for both, and reserve DoS for 
>magic-packet blocking exploits like the latest BIND CVE, FYI.

Given how easy it still is to put a fake source address in an IP
packet, it seems optimistic to assume that just because the packets
all have the same return address, they're actually coming from the
same place.

R's,
John

From rdobbins at arbor.net  Mon Aug  3 05:18:00 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 12:18:00 +0700
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <20150803051042.11782.qmail@ary.lan>
References: <20150803051042.11782.qmail@ary.lan>
Message-ID: <67EC0798-A8E2-4261-9532-0462A7598042@arbor.net>


On 3 Aug 2015, at 12:10, John Levine wrote:

> Given how easy it still is to put a fake source address in an IP
> packet, it seems optimistic to assume that just because the packets
> all have the same return address, they're actually coming from the
> same place.

Concur 100% - we see that from time to time, multiple sources spoofing 
the same source IP.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From elfkin at gmail.com  Mon Aug  3 08:35:50 2015
From: elfkin at gmail.com (Harald F. Karlsen)
Date: Mon, 3 Aug 2015 10:35:50 +0200
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
Message-ID: <55BF27E6.5070905@gmail.com>

On 02.08.2015 23:36, Josh Hoppes wrote:
> We haven't tackled IPv6 yet since it adds complexity that our primary
> focus doesn't significantly benefit from yet since most games just
> don't support it. Our current table switches don't have an RA guard,
> and will probably require replacement to get ones that are capable.

The lack of RA-guard/DHCPv6-guard can still bite you. A client can still 
send rogue RAs and set up a rogue DNS-server and start hijacking traffic 
as AAAA is preferred over A records by most operating systems these 
days. IPv6 first-hop security is really underrated these days and not 
providing the clients with IPv6 does not exclude IPv6 as a potential 
attack vector.

> We also re-designed the LAN back in 2011 to break up the giant single
> broadcast domain down to a subnet per table switch. This has
> definitely gotten us some flack from the BYOC since it breaks their
> LAN browsers, but we thought a stable network was more important with
> how much games have become dependent on stable Internet connectivity.
> Still trying to find a good way to provide a middle ground for
> attendees on that one, but I'm sure everyone here would understand how
> insane a single broadcast domain with 2000+ hosts that aren't under
> your control is. We have tried to focus on latency on the LAN, however
> when so many games are no longer LAN oriented Internet connectivity
> became a dominant issue.

At The Gathering we solved this by using ip helper-address for specific 
game ports and a broadcast forwarder daemon (which has been made 
publicly available). It sounds really ugly, but it works pretty good, 
just make sure to rate-limit the broadcast as it can be pretty ugly in 
the case of a potential loop/broadcast-storm.

> Some traffic is routed out a separate lower capacity connection to
> keep saturation issues from impacting it during the event.
>
> Squid and nginx do help with caching, and thankfully Steam migrated to
> a http distribution method and allows for easy caching. Some other
> services make it more difficult, but we try our best. Before Steam
> changed to http distribution there were a few years they helped in
> providing a local mirror but that seems to have been discontinued with
> the migration to http. The cache pushed a little over 4Gbps of traffic
> at peak at the event.
>
> The core IT team which handles the network (L2 and above) is about 9
> volunteers. The physical infrastructure is our IP & D team, which gets
> a huge team of volunteers put together in order to get that 13 miles
> of cable ready between Monday and Wednesday. The event is very
> volunteer driven, like many LAN parties across the planet. We try to
> reuse cable from year to year, including loading up the table runs
> onto a pallet to be used in making new cables out of in future years.
>

Thanks for the write-up, it's always cool to read how others in the 
"LAN-party scene" does things! :)

-- 
Harald

From mel at beckman.org  Mon Aug  3 12:40:49 2015
From: mel at beckman.org (Mel Beckman)
Date: Mon, 3 Aug 2015 12:40:49 +0000
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <20150803051042.11782.qmail@ary.lan>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>,
 <20150803051042.11782.qmail@ary.lan>
Message-ID: <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>

John,

What would be the point of spoofing the source IPs to be identical? You're just making the attack trivial to block.  Plus you could never do any kind of TCP session attack, since you can't complete a handshake. I would have to call this sort of attack a LAAADDoS (Lame Attempt At A DDoS). :)

 -mel beckman

On Aug 2, 2015, at 10:11 PM, John Levine <johnl at iecc.com> wrote:

>>> DDoS = multiple IPs
>>> 
>>> DoS = single IP
>> 
>> It seems most people colloquially use DDoS for both, and reserve DoS for 
>> magic-packet blocking exploits like the latest BIND CVE, FYI.
> 
> Given how easy it still is to put a fake source address in an IP
> packet, it seems optimistic to assume that just because the packets
> all have the same return address, they're actually coming from the
> same place.
> 
> R's,
> John

From rdobbins at arbor.net  Mon Aug  3 12:51:23 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 19:51:23 +0700
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
Message-ID: <D9544E51-19BA-4E38-AF12-B79BC4E4AC73@arbor.net>

On 3 Aug 2015, at 19:40, Mel Beckman wrote:

> What would be the point of spoofing the source IPs to be identical? 
> You're just making the attack trivial to block.

Attackers do strange things all the time.

Most endpoint organizations don't have any way to detect/classify DDoS 
traffic, so they've no idea how to block it.

Plus, it can asymmetrically strain load-balanced server instances, 
links, et. al.

Most DDoS attacks don't involve TCP and 3-way handshakes.  That isn't to 
say they aren't common, but one oughtn't to assume that having the 
ability to do so is a prerequisite for an attacker.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From A.L.M.Buxey at lboro.ac.uk  Mon Aug  3 12:56:18 2015
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 3 Aug 2015 12:56:18 +0000
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
Message-ID: <20150803125618.GA17246@lboro.ac.uk>

Hi,

> What would be the point of spoofing the source IPs to be identical? You're just making the attack trivial to block.  Plus you could never do any kind of TCP session attack, since you can't complete a handshake. I would have to call this sort of attack a LAAADDoS (Lame Attempt At A DDoS). :)

perhaps spoofing an IP that cannot be blocked as its one that needs to be allowed for the site IT to operate? some
cloud service IP or such.... ?

alan

From dovid at telecurve.com  Mon Aug  3 12:59:42 2015
From: dovid at telecurve.com (Dovid Bender)
Date: Mon, 3 Aug 2015 12:59:42 +0000
Subject: GoDaddy : DDoS :: Contact
In-Reply-To: <131048.1438575623@turing-police.cc.vt.edu>
References: <D1E3C2F1.2F37F%jason.leblanc@infusionsoft.com>
 <Jvkgvm-----0@tutanota.com> <<Jvkgvm-----0@tutanota.com> >
 <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <JvlhUPV----0@tutanota.com>
 <131048.1438575623@turing-police.cc.vt.edu>
Message-ID: <1594493212-1438606782-cardhu_decombobulator_blackberry.rim.net-50697709-@b11.c3.bise6.blackberry>

Children!

Regards,

Dovid

-----Original Message-----
From: Valdis.Kletnieks at vt.edu
Sender: "NANOG" <nanog-bounces at nanog.org>Date: Mon, 03 Aug 2015 00:20:23 
To: <tqr2813d376cjozqap1l at tutanota.com>
Cc: <nanog at nanog.org>
Subject: Re: GoDaddy : DDoS :: Contact

On Mon, 03 Aug 2015 03:58:31 -0000, tqr2813d376cjozqap1l at tutanota.com said:

> > It seems most people colloquially use DDoS for both, and reserve DoS for
> > magic-packet blocking exploits like the latest BIND CVE, FYI.

> Then they are mistaken, unfortunately.

Feel free to try to reclaim the old meaning of the word "hacker" while
you're at it.  That ship sailed long ago, and so has the DoS/DDoS distinction.



From list at satchell.net  Mon Aug  3 13:00:03 2015
From: list at satchell.net (Stephen Satchell)
Date: Mon, 03 Aug 2015 06:00:03 -0700
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>,
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
Message-ID: <55BF65D3.9000602@satchell.net>

On 08/03/2015 05:40 AM, Mel Beckman wrote:
> What would be the point of spoofing the source IPs to be identical?
> You're just making the attack trivial to block.  Plus you could never
> do any kind of TCP session attack, since you can't complete a
> handshake. I would have to call this sort of attack a LAAADDoS (Lame
> Attempt At A DDoS).:)

Reflection attack as a secondary goal against the spoofed source IP? 
Primary goal would be a SYN flood of many servers.

From magicsata at gmail.com  Mon Aug  3 13:20:11 2015
From: magicsata at gmail.com (Alistair Mackenzie)
Date: Mon, 3 Aug 2015 14:20:11 +0100
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
 <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
Message-ID: <CA+bbMkv8kFH-cUOYtfCt_N+dh7tEu43PWzXJODZwRWzGmp7C4Q@mail.gmail.com>

Source based black holing would work in this case providing it was done at
GoDaddy's edge.
On 3 Aug 2015 01:58, "Mel Beckman" <mel at beckman.org> wrote:

> Blackholing isn't what you want. That will still permit his source IP into
> your network, and only blackhole replies from your network, so the attack
> will still consume bandwidth. What you should request is a source IP ACL
> blocking that address at your upstream' border.
>
> BGP is no help in these situations, unless you use a BGP-based DDoS
> protection service.
>
>  -mel beckman
>
> On Aug 2, 2015, at 5:17 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com
> <mailto:jason.leblanc at infusionsoft.com>> wrote:
>
> Thanks Mel.  You are not being difficult, I meant DoS.  The network I
> inherited doesn't have BGP yet so I have asked our upstream to blackhole it
> and I emailed abuse neither have happened yet.  I do block it but that's
> after it hits our side.
>
> //Jason
>
> From: Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>>
> Date: Sunday, August 2, 2015 at 4:20 PM
> To: Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:
> jason.leblanc at infusionsoft.com>>
> Cc: NANOG <nanog at nanog.org<mailto:nanog at nanog.org>>
> Subject: Re: GoDaddy : DDoS :: Contact
>
> Not to be difficult, but how can it be a DDoS attack if it's coming from a
> single IP? Normally you would just block this IP at your borders or ask
> your upstreams to do so before it consumes your bandwidth. You still want
> to get GoDaddy to address the problem, of course, but you should do that
> via their abuse at godaddy.com<mailto:abuse at godaddy.com> contact, or their
> abuse page at https://supportcenter.godaddy.com/AbuseReport/Index (submit
> via the "malware" button).
>
>  -mel
>
> On Aug 2, 2015, at 12:59 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com
> <mailto:jason.leblanc at infusionsoft.com>> wrote:
>
> My company is being DDoS'd by a single IP from a GoDaddy customer.
>
> I havent had success with the abuse at godaddy.com<mailto:abuse at godaddy.com>
> email.  Was hoping someone
> that could help might be watching the list and could contact me off-list.
>
>
> //Jason
>
>
>

From rdobbins at arbor.net  Mon Aug  3 13:26:06 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 20:26:06 +0700
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
 <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
Message-ID: <1D2A7BB4-4DAA-4256-8DBC-0992173BDA64@arbor.net>


On 3 Aug 2015, at 7:56, Mel Beckman wrote:

> BGP is no help in these situations, unless you use a BGP-based DDoS 
> protection service.

Anyone can set up S/RTBH on their transit-/peering-edge routers, even if 
they aren't using BGP for routing.

Likewise flowspec, on routers which support it.

If attack volume is high, it still may flood the link, but keeping the 
traffic off one's own core and off the actual target(s) of the attack 
are still very worthwhile.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From mel at beckman.org  Mon Aug  3 13:28:54 2015
From: mel at beckman.org (Mel Beckman)
Date: Mon, 3 Aug 2015 13:28:54 +0000
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <CA+bbMkv8kFH-cUOYtfCt_N+dh7tEu43PWzXJODZwRWzGmp7C4Q@mail.gmail.com>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
 <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
 <CA+bbMkv8kFH-cUOYtfCt_N+dh7tEu43PWzXJODZwRWzGmp7C4Q@mail.gmail.com>
Message-ID: <70DD7E65-3E01-41E2-AAD0-2A7F30153E52@beckman.org>

I don?t see how. Blackholing works on destination address ? it?s a route to null0. The source address isn?t considered and thus the traffic will still leave GoDaddy. GoDaddy could, I suppose, implement a policy route based on source address, but that?s really no different than an ACL. And it?s not a blackhole.

Anyway, since it's the GoDaddy edge your talking about, GoDaddy can simply disconnect the customer.

 -mel

On Aug 3, 2015, at 6:20 AM, Alistair Mackenzie <magicsata at gmail.com<mailto:magicsata at gmail.com>> wrote:


Source based black holing would work in this case providing it was done at GoDaddy's edge.

On 3 Aug 2015 01:58, "Mel Beckman" <mel at beckman.org<mailto:mel at beckman.org>> wrote:
Blackholing isn't what you want. That will still permit his source IP into your network, and only blackhole replies from your network, so the attack will still consume bandwidth. What you should request is a source IP ACL blocking that address at your upstream' border.

BGP is no help in these situations, unless you use a BGP-based DDoS protection service.

 -mel beckman

On Aug 2, 2015, at 5:17 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com><mailto:jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>>> wrote:

Thanks Mel.  You are not being difficult, I meant DoS.  The network I inherited doesn't have BGP yet so I have asked our upstream to blackhole it and I emailed abuse neither have happened yet.  I do block it but that's after it hits our side.

//Jason

From: Mel Beckman <mel at beckman.org<mailto:mel at beckman.org><mailto:mel at beckman.org<mailto:mel at beckman.org>>>
Date: Sunday, August 2, 2015 at 4:20 PM
To: Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com><mailto:jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>>>
Cc: NANOG <nanog at nanog.org<mailto:nanog at nanog.org><mailto:nanog at nanog.org<mailto:nanog at nanog.org>>>
Subject: Re: GoDaddy : DDoS :: Contact

Not to be difficult, but how can it be a DDoS attack if it's coming from a single IP? Normally you would just block this IP at your borders or ask your upstreams to do so before it consumes your bandwidth. You still want to get GoDaddy to address the problem, of course, but you should do that via their abuse at godaddy.com<mailto:abuse at godaddy.com><mailto:abuse at godaddy.com<mailto:abuse at godaddy.com>> contact, or their abuse page at https://supportcenter.godaddy.com/AbuseReport/Index (submit via the "malware" button).

 -mel

On Aug 2, 2015, at 12:59 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com><mailto:jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>>> wrote:

My company is being DDoS'd by a single IP from a GoDaddy customer.

I havent had success with the abuse at godaddy.com<mailto:abuse at godaddy.com><mailto:abuse at godaddy.com<mailto:abuse at godaddy.com>> email.  Was hoping someone
that could help might be watching the list and could contact me off-list.


//Jason




From rdobbins at arbor.net  Mon Aug  3 13:31:32 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 20:31:32 +0700
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <70DD7E65-3E01-41E2-AAD0-2A7F30153E52@beckman.org>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
 <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
 <CA+bbMkv8kFH-cUOYtfCt_N+dh7tEu43PWzXJODZwRWzGmp7C4Q@mail.gmail.com>
 <70DD7E65-3E01-41E2-AAD0-2A7F30153E52@beckman.org>
Message-ID: <2E141B12-BCB4-4473-9910-EAE5F662CC9C@arbor.net>

On 3 Aug 2015, at 20:28, Mel Beckman wrote:

> Blackholing works on destination address ? it?s a route to null0.

<https://tools.ietf.org/html/rfc5635>

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From mel at beckman.org  Mon Aug  3 13:35:26 2015
From: mel at beckman.org (Mel Beckman)
Date: Mon, 3 Aug 2015 13:35:26 +0000
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <55BF65D3.9000602@satchell.net>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
 <55BF65D3.9000602@satchell.net>
Message-ID: <D6E3F91B-B97C-4165-ADD9-9BDB0D0A4079@beckman.org>

But SYN floods are easily detected and deflected by all modern firewalls. If a handshake doesn?t complete within a certain time interval, the SYN is discarded. 

Many DDOS attacks are full-fledged TCP sessions. The zombies are used to simulate legitimate users, and because they?re coming from thousands of legitimate IP addresses sending what looks like completely normal traffic (e.g. HTTP queries) they are difficult to distinguish from real clients systems. There are of course unicast DDOS attacks prosecuted over UDP or ICMP. The majority I?ve seen, however, are TCP.

In any event, I think it?s not useful to misuse the term DDoS, and that it refers to any attack where the source addresses are distributed across the Internet, making them difficult to identify and therefore block.

 -mel

> On Aug 3, 2015, at 6:00 AM, Stephen Satchell <list at satchell.net> wrote:
> 
> On 08/03/2015 05:40 AM, Mel Beckman wrote:
>> What would be the point of spoofing the source IPs to be identical?
>> You're just making the attack trivial to block.  Plus you could never
>> do any kind of TCP session attack, since you can't complete a
>> handshake. I would have to call this sort of attack a LAAADDoS (Lame
>> Attempt At A DDoS).:)
> 
> Reflection attack as a secondary goal against the spoofed source IP? Primary goal would be a SYN flood of many servers.


From colton.conor at gmail.com  Mon Aug  3 13:36:20 2015
From: colton.conor at gmail.com (Colton Conor)
Date: Mon, 3 Aug 2015 08:36:20 -0500
Subject: DE-CIX vs Equinix
In-Reply-To: <CALB2hAckCU2w7jYG2Z=6n5znet1z4iq8V3BsY9YLYOjHwbFioA@mail.gmail.com>
References: <CAMDdSzOJ+OUeKrwCYr4Joh+HYp7d7K74aFeb0i6qUg+iVe5vhQ@mail.gmail.com>
 <CALB2hAckCU2w7jYG2Z=6n5znet1z4iq8V3BsY9YLYOjHwbFioA@mail.gmail.com>
Message-ID: <CAMDdSzP0B_Wq33V-0HgV6U7Vcd8+Nbzf6SrfWG74B5voKR7mkQ@mail.gmail.com>

Charles,

You mentioned to not use " DE-CIX NYC pricing as a benchmark" for Dallas,
but it looks like DE-CIX has priced their Dallas ports, according to their
website, at the same prices at NYC:

https://www.de-cix.net/products-services/pricing/#c2374

PortSpeed/GbpsMRC1GE1US$ 57510GE10US$ 1,250100GE100On request

Pricing table effective from 1 August 2015.


There is a special offer:


*Join us now and get your 1GE or 10GE port free of charge for*

   - *6 months* (minimum contract term of 12 months) or
   - *12 months* (minimum contract term of 36 months).


https://www.de-cix.net/products-services/pricing/#c2374


So it seems that their 10G port price, after promo, is $1250, and it does
not mention cross connect would be included. Compare this to Equinix's 10G
port with a cross connect included at $1000 per month. Considering Equinix's
cross connects are usually $350 per month, this means Equinix's actual 10G
port really cost $650 per month.

So, I will ask the question again, why are providers going to jump and
use DE-CIX
over Equinix's peering exchange? I am failing to see the benefit.
I thought it would be price, but apparently not.

On Wed, Jul 22, 2015 at 9:25 AM, Charles Gucker <cgucker at onesc.net> wrote:

> On Wed, Jul 22, 2015 at 9:48 AM, Colton Conor <colton.conor at gmail.com>
> wrote:
> > What are the main difference between these two peering companies,
> > exchanges, and overall operating model? The market in question would be
> > Dallas Texas where Equinix already has the only established peering
> > exchange with over 100 members, and DE-CIX just announced today that that
> > would also be building one in Dallas. It will take time for DE-CIX to
> > establish their exchange in Dallas and get members, but they better
> > question is why would people switch?
>
>     In short, Equinix is by far and large a data center operator and
> the Internet exchange is an add-on service only available within their
> data center locations.     DE-CIX is an exchange point operator who
> operates in multiple dis-parent data center locations.
>
> > For a 10G port with a cross connect to the exchange included Equinix
> > charges $1000 per month. According to DE-CIX it looks like they charge
> > $1250 per month for a 10G port in NYC, so I asusme the same would be true
> > in Dallas. https://nyc.de-cix.net/products-services/pricing/
>
>     I would not use DE-CIX NYC pricing as a benchmark.    As DE-CIX
> learned, NYC is a very difficult market to get connectivity and to
> build an exchange in.    As such their operating costs are a lot
> higher than in other markets and I don't believe it would be a good
> assumption to use NYC based pricing in Dallas.    But keep in mind,
> DE-CIX likes to distribute their network access nodes to get a larger
> audience than within ones own facility.
>
>     Also, I would suggest looking at the big picture and the cost of
> colocation services in a facility other than Equinix to "level the
> playing field".
>
> > Looks like DE-CIX will offer a promo to entice new members to join, and
> > their exchange will be in the carrier neatural meet me room operated by
> the
> > infomart that will have little to no cross connect fees.
> >
> > Why would people pay more to connect to an exchange with less members?
> What
> > is the european exchange that is a non-profit and basically only covers
> the
> > cost of operating the exchange?
>
>      As stated above, when looking at the big picture, it may or may
> not be more expensive when all of your other services are considered.
>
>     It should be said that I don't have any axe to grind and think
> very highly of Equinix.    But with respect to Dallas, I would suggest
> looking at bigger picture and see if your assumptions still hold true.
>
> charles
>

From nanog at ics-il.net  Mon Aug  3 13:44:36 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Aug 2015 08:44:36 -0500 (CDT)
Subject: DE-CIX vs Equinix
In-Reply-To: <CAMDdSzP0B_Wq33V-0HgV6U7Vcd8+Nbzf6SrfWG74B5voKR7mkQ@mail.gmail.com>
Message-ID: <688372940.1303.1438609524412.JavaMail.mhammett@ThunderFuck>

I'd expect that eventually DE-CIX will build into every Dallas datacenter as they have done in New York and Germany whereas Equinix is only available... in Equinix. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Colton Conor" <colton.conor at gmail.com> 
To: "Charles Gucker" <cgucker at onesc.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Monday, August 3, 2015 8:36:20 AM 
Subject: Re: DE-CIX vs Equinix 

Charles, 

You mentioned to not use " DE-CIX NYC pricing as a benchmark" for Dallas, 
but it looks like DE-CIX has priced their Dallas ports, according to their 
website, at the same prices at NYC: 

https://www.de-cix.net/products-services/pricing/#c2374 

PortSpeed/GbpsMRC1GE1US$ 57510GE10US$ 1,250100GE100On request 

Pricing table effective from 1 August 2015. 


There is a special offer: 


*Join us now and get your 1GE or 10GE port free of charge for* 

- *6 months* (minimum contract term of 12 months) or 
- *12 months* (minimum contract term of 36 months). 


https://www.de-cix.net/products-services/pricing/#c2374 


So it seems that their 10G port price, after promo, is $1250, and it does 
not mention cross connect would be included. Compare this to Equinix's 10G 
port with a cross connect included at $1000 per month. Considering Equinix's 
cross connects are usually $350 per month, this means Equinix's actual 10G 
port really cost $650 per month. 

So, I will ask the question again, why are providers going to jump and 
use DE-CIX 
over Equinix's peering exchange? I am failing to see the benefit. 
I thought it would be price, but apparently not. 

On Wed, Jul 22, 2015 at 9:25 AM, Charles Gucker <cgucker at onesc.net> wrote: 

> On Wed, Jul 22, 2015 at 9:48 AM, Colton Conor <colton.conor at gmail.com> 
> wrote: 
> > What are the main difference between these two peering companies, 
> > exchanges, and overall operating model? The market in question would be 
> > Dallas Texas where Equinix already has the only established peering 
> > exchange with over 100 members, and DE-CIX just announced today that that 
> > would also be building one in Dallas. It will take time for DE-CIX to 
> > establish their exchange in Dallas and get members, but they better 
> > question is why would people switch? 
> 
> In short, Equinix is by far and large a data center operator and 
> the Internet exchange is an add-on service only available within their 
> data center locations. DE-CIX is an exchange point operator who 
> operates in multiple dis-parent data center locations. 
> 
> > For a 10G port with a cross connect to the exchange included Equinix 
> > charges $1000 per month. According to DE-CIX it looks like they charge 
> > $1250 per month for a 10G port in NYC, so I asusme the same would be true 
> > in Dallas. https://nyc.de-cix.net/products-services/pricing/ 
> 
> I would not use DE-CIX NYC pricing as a benchmark. As DE-CIX 
> learned, NYC is a very difficult market to get connectivity and to 
> build an exchange in. As such their operating costs are a lot 
> higher than in other markets and I don't believe it would be a good 
> assumption to use NYC based pricing in Dallas. But keep in mind, 
> DE-CIX likes to distribute their network access nodes to get a larger 
> audience than within ones own facility. 
> 
> Also, I would suggest looking at the big picture and the cost of 
> colocation services in a facility other than Equinix to "level the 
> playing field". 
> 
> > Looks like DE-CIX will offer a promo to entice new members to join, and 
> > their exchange will be in the carrier neatural meet me room operated by 
> the 
> > infomart that will have little to no cross connect fees. 
> > 
> > Why would people pay more to connect to an exchange with less members? 
> What 
> > is the european exchange that is a non-profit and basically only covers 
> the 
> > cost of operating the exchange? 
> 
> As stated above, when looking at the big picture, it may or may 
> not be more expensive when all of your other services are considered. 
> 
> It should be said that I don't have any axe to grind and think 
> very highly of Equinix. But with respect to Dallas, I would suggest 
> looking at bigger picture and see if your assumptions still hold true. 
> 
> charles 
> 


From mel at beckman.org  Mon Aug  3 13:46:10 2015
From: mel at beckman.org (Mel Beckman)
Date: Mon, 3 Aug 2015 13:46:10 +0000
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <2E141B12-BCB4-4473-9910-EAE5F662CC9C@arbor.net>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
 <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
 <CA+bbMkv8kFH-cUOYtfCt_N+dh7tEu43PWzXJODZwRWzGmp7C4Q@mail.gmail.com>
 <70DD7E65-3E01-41E2-AAD0-2A7F30153E52@beckman.org>
 <2E141B12-BCB4-4473-9910-EAE5F662CC9C@arbor.net>
Message-ID: <280C93BA-7CFF-49D8-A248-0B1DF97B9224@beckman.org>

There are two problems with Source-Based Remote Triggered Black Hole (S/RTBH):

1. From the RFC itself, you by definition sacrifice the victims address:

   3.1. ...While this does "complete" the attack in that the target address(es)
   are made unreachable, collateral damage is minimized.  It may also be
   possible to move the host or service on the target IP address(es) to
   another address and keep the service up, for example, by updating
   associated DNS resource records.

2. No ISP I know of supports it (e.g., via BGP communities)

 -mel

> On Aug 3, 2015, at 6:31 AM, Roland Dobbins <rdobbins at arbor.net> wrote:
> 
> On 3 Aug 2015, at 20:28, Mel Beckman wrote:
> 
>> Blackholing works on destination address ? it?s a route to null0.
> 
> <https://tools.ietf.org/html/rfc5635>
> 
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>


From colton.conor at gmail.com  Mon Aug  3 13:50:26 2015
From: colton.conor at gmail.com (Colton Conor)
Date: Mon, 3 Aug 2015 08:50:26 -0500
Subject: DE-CIX vs Equinix
In-Reply-To: <688372940.1303.1438609524412.JavaMail.mhammett@ThunderFuck>
References: <CAMDdSzP0B_Wq33V-0HgV6U7Vcd8+Nbzf6SrfWG74B5voKR7mkQ@mail.gmail.com>
 <688372940.1303.1438609524412.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAMDdSzPy79Vfir9kxaKdL6jydertA7bmjLuO2Y3oAOEcuCUvxg@mail.gmail.com>

Does DE-CIX usually go to market with at least some of the big content
providers already on board? For example, will guys like Netflix, Google,
and other CDN's more than likely be on the exchange starting day 1?

How does  DE-CIX work if you want to cross connect over the exchange to
another provider in a different on-net datacenter of the exchange in the
same metro market?

On Mon, Aug 3, 2015 at 8:44 AM, Mike Hammett <nanog at ics-il.net> wrote:

> I'd expect that eventually DE-CIX will build into every Dallas datacenter
> as they have done in New York and Germany whereas Equinix is only
> available... in Equinix.
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
> ----- Original Message -----
>
> From: "Colton Conor" <colton.conor at gmail.com>
> To: "Charles Gucker" <cgucker at onesc.net>
> Cc: "NANOG" <nanog at nanog.org>
> Sent: Monday, August 3, 2015 8:36:20 AM
> Subject: Re: DE-CIX vs Equinix
>
> Charles,
>
> You mentioned to not use " DE-CIX NYC pricing as a benchmark" for Dallas,
> but it looks like DE-CIX has priced their Dallas ports, according to their
> website, at the same prices at NYC:
>
> https://www.de-cix.net/products-services/pricing/#c2374
>
> PortSpeed/GbpsMRC1GE1US$ 57510GE10US$ 1,250100GE100On request
>
> Pricing table effective from 1 August 2015.
>
>
> There is a special offer:
>
>
> *Join us now and get your 1GE or 10GE port free of charge for*
>
> - *6 months* (minimum contract term of 12 months) or
> - *12 months* (minimum contract term of 36 months).
>
>
> https://www.de-cix.net/products-services/pricing/#c2374
>
>
> So it seems that their 10G port price, after promo, is $1250, and it does
> not mention cross connect would be included. Compare this to Equinix's 10G
> port with a cross connect included at $1000 per month. Considering
> Equinix's
> cross connects are usually $350 per month, this means Equinix's actual 10G
> port really cost $650 per month.
>
> So, I will ask the question again, why are providers going to jump and
> use DE-CIX
> over Equinix's peering exchange? I am failing to see the benefit.
> I thought it would be price, but apparently not.
>
> On Wed, Jul 22, 2015 at 9:25 AM, Charles Gucker <cgucker at onesc.net> wrote:
>
> > On Wed, Jul 22, 2015 at 9:48 AM, Colton Conor <colton.conor at gmail.com>
> > wrote:
> > > What are the main difference between these two peering companies,
> > > exchanges, and overall operating model? The market in question would be
> > > Dallas Texas where Equinix already has the only established peering
> > > exchange with over 100 members, and DE-CIX just announced today that
> that
> > > would also be building one in Dallas. It will take time for DE-CIX to
> > > establish their exchange in Dallas and get members, but they better
> > > question is why would people switch?
> >
> > In short, Equinix is by far and large a data center operator and
> > the Internet exchange is an add-on service only available within their
> > data center locations. DE-CIX is an exchange point operator who
> > operates in multiple dis-parent data center locations.
> >
> > > For a 10G port with a cross connect to the exchange included Equinix
> > > charges $1000 per month. According to DE-CIX it looks like they charge
> > > $1250 per month for a 10G port in NYC, so I asusme the same would be
> true
> > > in Dallas. https://nyc.de-cix.net/products-services/pricing/
> >
> > I would not use DE-CIX NYC pricing as a benchmark. As DE-CIX
> > learned, NYC is a very difficult market to get connectivity and to
> > build an exchange in. As such their operating costs are a lot
> > higher than in other markets and I don't believe it would be a good
> > assumption to use NYC based pricing in Dallas. But keep in mind,
> > DE-CIX likes to distribute their network access nodes to get a larger
> > audience than within ones own facility.
> >
> > Also, I would suggest looking at the big picture and the cost of
> > colocation services in a facility other than Equinix to "level the
> > playing field".
> >
> > > Looks like DE-CIX will offer a promo to entice new members to join, and
> > > their exchange will be in the carrier neatural meet me room operated by
> > the
> > > infomart that will have little to no cross connect fees.
> > >
> > > Why would people pay more to connect to an exchange with less members?
> > What
> > > is the european exchange that is a non-profit and basically only covers
> > the
> > > cost of operating the exchange?
> >
> > As stated above, when looking at the big picture, it may or may
> > not be more expensive when all of your other services are considered.
> >
> > It should be said that I don't have any axe to grind and think
> > very highly of Equinix. But with respect to Dallas, I would suggest
> > looking at bigger picture and see if your assumptions still hold true.
> >
> > charles
> >
>
>

From rdobbins at arbor.net  Mon Aug  3 13:52:46 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 20:52:46 +0700
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <280C93BA-7CFF-49D8-A248-0B1DF97B9224@beckman.org>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
 <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
 <CA+bbMkv8kFH-cUOYtfCt_N+dh7tEu43PWzXJODZwRWzGmp7C4Q@mail.gmail.com>
 <70DD7E65-3E01-41E2-AAD0-2A7F30153E52@beckman.org>
 <2E141B12-BCB4-4473-9910-EAE5F662CC9C@arbor.net>
 <280C93BA-7CFF-49D8-A248-0B1DF97B9224@beckman.org>
Message-ID: <7549E59F-9362-476A-A6E3-59055A200B3A@arbor.net>

On 3 Aug 2015, at 20:46, Mel Beckman wrote:

> 1. From the RFC itself, you by definition sacrifice the victims 
> address:
>
> 3.1. ...While this does "complete" the attack in that the target 
> address(es)
> are made unreachable, collateral damage is minimized.  It may also be
> possible to move the host or service on the target IP address(es) to
> another address and keep the service up, for example, by updating
> associated DNS resource records.

This is incorrect.  I've used S/RTBH for the last 15 years or so to 
mitigate attacks.  One absolutely does *not* 'sacrifice the victim's IP 
address'.

The section you're quoting is describing D/RTBH, by way of explaining 
its deficiencies.  It would probably be a good idea to read the RFC in 
its entirety.  S/RTBH is described in Section 4 - e.g., the very next 
section.

> 2. No ISP I know of supports it (e.g., via BGP communities)

As noted in my previous message in this thread, one applies this on 
one's own transit-/peering-edge router.  While it won't prevent said 
link from being saturated, it keeps traffic from the blackholed source 
off one's own core, and off the targeted IP(s), which is of operational 
utility.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Mon Aug  3 14:00:15 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 21:00:15 +0700
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <D6E3F91B-B97C-4165-ADD9-9BDB0D0A4079@beckman.org>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
 <55BF65D3.9000602@satchell.net>
 <D6E3F91B-B97C-4165-ADD9-9BDB0D0A4079@beckman.org>
Message-ID: <164C3700-C1DC-4320-97D5-8947C06D3052@arbor.net>

On 3 Aug 2015, at 20:35, Mel Beckman wrote:

> But SYN floods are easily detected and deflected by all modern 
> firewalls. If a handshake doesn?t complete within a certain time 
> interval, the SYN is discarded.

This is incorrect.  I've seen a 20gb/sec stateful firewall taken down by 
a 3mb/sec spoofed SYN-flood due to DDoS exhaustion.  I've seen a 
10gb/sec load-balancer taken down by 60s of 6kpps of HOIC:

<https://app.box.com/s/a3oqqlgwe15j8svojvzl>

> The majority I?ve seen, however, are TCP.

<https://en.wikipedia.org/wiki/Hasty_generalization>

> In any event, I think it?s not useful to misuse the term DDoS, and 
> that it refers to any attack where the source addresses are 
> distributed across the Internet, making them difficult to identify and 
> therefore block.

Again, that ship sailed long ago.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From rdobbins at arbor.net  Mon Aug  3 14:04:11 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 21:04:11 +0700
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <164C3700-C1DC-4320-97D5-8947C06D3052@arbor.net>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
 <55BF65D3.9000602@satchell.net>
 <D6E3F91B-B97C-4165-ADD9-9BDB0D0A4079@beckman.org>
 <164C3700-C1DC-4320-97D5-8947C06D3052@arbor.net>
Message-ID: <59056E47-29A2-4AB1-87D2-562631F038C9@arbor.net>

On 3 Aug 2015, at 21:00, Roland Dobbins wrote:

> due to DDoS exhaustion

That should read 'state exhaustion', apologies.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From nanog at ics-il.net  Mon Aug  3 14:14:12 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Aug 2015 09:14:12 -0500 (CDT)
Subject: DE-CIX vs Equinix
In-Reply-To: <CAMDdSzPy79Vfir9kxaKdL6jydertA7bmjLuO2Y3oAOEcuCUvxg@mail.gmail.com>
Message-ID: <690572121.1333.1438611293582.JavaMail.mhammett@ThunderFuck>

Usually on a distributed exchange, everyone on the same fabric is available at the same standard price. Local datacenter or the furthest datacenter, same price. 

Look at what happened in NYC. I'd expect something similar in Dallas, though I have no inside information behind that. https://nyc.de-cix.net/news/news-archive/ 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Colton Conor" <colton.conor at gmail.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Monday, August 3, 2015 8:50:26 AM 
Subject: Re: DE-CIX vs Equinix 


Does DE-CIX usually go to market with at least some of the big content providers already on board? For example, will guys like Netflix, Google, and other CDN's more than likely be on the exchange starting day 1? 


How does DE-CIX work if you want to cross connect over the exchange to another provider in a different on-net datacenter of the exchange in the same metro market? 


On Mon, Aug 3, 2015 at 8:44 AM, Mike Hammett < nanog at ics-il.net > wrote: 


I'd expect that eventually DE-CIX will build into every Dallas datacenter as they have done in New York and Germany whereas Equinix is only available... in Equinix. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message ----- 

From: "Colton Conor" < colton.conor at gmail.com > 
To: "Charles Gucker" < cgucker at onesc.net > 
Cc: "NANOG" < nanog at nanog.org > 
Sent: Monday, August 3, 2015 8:36:20 AM 
Subject: Re: DE-CIX vs Equinix 

Charles, 

You mentioned to not use " DE-CIX NYC pricing as a benchmark" for Dallas, 
but it looks like DE-CIX has priced their Dallas ports, according to their 
website, at the same prices at NYC: 

https://www.de-cix.net/products-services/pricing/#c2374 

PortSpeed/GbpsMRC1GE1US$ 57510GE10US$ 1,250100GE100On request 

Pricing table effective from 1 August 2015. 


There is a special offer: 


*Join us now and get your 1GE or 10GE port free of charge for* 

- *6 months* (minimum contract term of 12 months) or 
- *12 months* (minimum contract term of 36 months). 




https://www.de-cix.net/products-services/pricing/#c2374 


So it seems that their 10G port price, after promo, is $1250, and it does 
not mention cross connect would be included. Compare this to Equinix's 10G 
port with a cross connect included at $1000 per month. Considering Equinix's 
cross connects are usually $350 per month, this means Equinix's actual 10G 
port really cost $650 per month. 

So, I will ask the question again, why are providers going to jump and 
use DE-CIX 
over Equinix's peering exchange? I am failing to see the benefit. 
I thought it would be price, but apparently not. 

On Wed, Jul 22, 2015 at 9:25 AM, Charles Gucker < cgucker at onesc.net > wrote: 

> On Wed, Jul 22, 2015 at 9:48 AM, Colton Conor < colton.conor at gmail.com > 
> wrote: 
> > What are the main difference between these two peering companies, 
> > exchanges, and overall operating model? The market in question would be 
> > Dallas Texas where Equinix already has the only established peering 
> > exchange with over 100 members, and DE-CIX just announced today that that 
> > would also be building one in Dallas. It will take time for DE-CIX to 
> > establish their exchange in Dallas and get members, but they better 
> > question is why would people switch? 
> 
> In short, Equinix is by far and large a data center operator and 
> the Internet exchange is an add-on service only available within their 
> data center locations. DE-CIX is an exchange point operator who 
> operates in multiple dis-parent data center locations. 
> 
> > For a 10G port with a cross connect to the exchange included Equinix 
> > charges $1000 per month. According to DE-CIX it looks like they charge 
> > $1250 per month for a 10G port in NYC, so I asusme the same would be true 
> > in Dallas. https://nyc.de-cix.net/products-services/pricing/ 
> 
> I would not use DE-CIX NYC pricing as a benchmark. As DE-CIX 
> learned, NYC is a very difficult market to get connectivity and to 
> build an exchange in. As such their operating costs are a lot 
> higher than in other markets and I don't believe it would be a good 
> assumption to use NYC based pricing in Dallas. But keep in mind, 
> DE-CIX likes to distribute their network access nodes to get a larger 
> audience than within ones own facility. 
> 
> Also, I would suggest looking at the big picture and the cost of 
> colocation services in a facility other than Equinix to "level the 
> playing field". 
> 
> > Looks like DE-CIX will offer a promo to entice new members to join, and 
> > their exchange will be in the carrier neatural meet me room operated by 
> the 
> > infomart that will have little to no cross connect fees. 
> > 
> > Why would people pay more to connect to an exchange with less members? 
> What 
> > is the european exchange that is a non-profit and basically only covers 
> the 
> > cost of operating the exchange? 
> 
> As stated above, when looking at the big picture, it may or may 
> not be more expensive when all of your other services are considered. 
> 
> It should be said that I don't have any axe to grind and think 
> very highly of Equinix. But with respect to Dallas, I would suggest 
> looking at bigger picture and see if your assumptions still hold true. 
> 
> charles 
> 






From list at satchell.net  Mon Aug  3 14:19:28 2015
From: list at satchell.net (Stephen Satchell)
Date: Mon, 03 Aug 2015 07:19:28 -0700
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <59056E47-29A2-4AB1-87D2-562631F038C9@arbor.net>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
 <55BF65D3.9000602@satchell.net>
 <D6E3F91B-B97C-4165-ADD9-9BDB0D0A4079@beckman.org>
 <164C3700-C1DC-4320-97D5-8947C06D3052@arbor.net>
 <59056E47-29A2-4AB1-87D2-562631F038C9@arbor.net>
Message-ID: <55BF7870.2020006@satchell.net>

On 08/03/2015 07:04 AM, Roland Dobbins wrote:
> On 3 Aug 2015, at 21:00, Roland Dobbins wrote:
>
>> due to DDoS exhaustion
>
> That should read '[TCP] state exhaustion', apologies.

And any half-awake server operator would have turned on SYNCOOKIES a 
long time ago.


From rdobbins at arbor.net  Mon Aug  3 14:34:50 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 21:34:50 +0700
Subject: GoDaddy : DDoS : : Contact
In-Reply-To: <55BF7870.2020006@satchell.net>
References: <22C7992E-8A8A-4689-A58B-0AF87B78284F@arbor.net>
 <20150803051042.11782.qmail@ary.lan>
 <C5936B5A-552D-4067-8F24-01B1B6909DDD@beckman.org>
 <55BF65D3.9000602@satchell.net>
 <D6E3F91B-B97C-4165-ADD9-9BDB0D0A4079@beckman.org>
 <164C3700-C1DC-4320-97D5-8947C06D3052@arbor.net>
 <59056E47-29A2-4AB1-87D2-562631F038C9@arbor.net>
 <55BF7870.2020006@satchell.net>
Message-ID: <843BE123-E1F6-4028-BED1-A7DC1C3F9009@arbor.net>

On 3 Aug 2015, at 21:19, Stephen Satchell wrote:

> And any half-awake server operator would have turned on SYNCOOKIES a 
> long time ago.

I hate to tell you this, but a) SYN-cookies aren't a perfect response, 
as servers don't have infinite resources, and b) stateful firewalls go 
down *all the time* under DDoS attacks.

It might be a good idea to search the list archives for more on this 
phenomenon.

There's also information available in the Arbor WISRs; I think the first 
time we explicitly asked in the survey about stateful devices going down 
under DDoS was in 2010:

[Warning:  free registration required, but you can opt-out of email as 
part of the registration process]

<http://www.arbornetworks.com/resources/infrastructure-security-report>

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From telmnstr at 757.org  Mon Aug  3 14:58:35 2015
From: telmnstr at 757.org (Ethan)
Date: Mon, 3 Aug 2015 10:58:35 -0400 (EDT)
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <55BF27E6.5070905@gmail.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com>
Message-ID: <Pine.LNX.4.64.1508031030430.6548@users.757.org>


I help with an event that has a pretty decent sized lan party as well. 
We're not just focused on the lan party, more of a rock concerts - huge 
arcade - panels - lan party type event.

It was a few years ago that a mincraft "griefing" team came and attacked 
the network internally. At the time the BYOC LAN party I think was using 
3com switches on the edge. Griefers were doing MAC flooding or something 
that was causing the switches to fall over. And not just the switch they 
were connected to it was bringing down many of them. They were doing it in 
spurts and the people dealing with the network thought the issue was 
misbehaving equipment for a bit (it seemed foreign at that time that 
someone from the community would be doing it.)

Mind you the people running things (volunteers) are running on little 
sleep, had no time to build out security appliances let alone watch a 
bunch of logs. They're pretty smart but you know - you get a bunch of 
smart people together they all bicker about how to do things their way.

In the end, one of the griefers friends went and told on them, and that's 
how they were discovered. Badges yanked and banned for life.

Most of these cons and events run on surplus hardware. Granted, these days 
there is more and more higher end stuff being cast away. More and more 10 
gig, Juniper, Force10 and other decent equipment coming into play.

Getting bandwidth into the events is a pain. Huge venues are meant for 
large corporate events not lower budget cons and festivals. Venue pricing 
I believe is 750-1500$ per megabit. 100 megabit = $75,000 for the weekend. 
One year I rememeber there being a switch with 8 vlans on it sitting 
outside the back door with 8 clear modems spread out all blinking away.
Geeks get creative.

These days, a random family next door gets their business class FiOS paid 
for the entire year (with a good TV package) in return for a weekend or 
two a year of it being slammed. But that isn't keeping up with demand.
I think sponsorship is in our future as far as bandwidth goes.

Internally, the hotels charge for any ports. So if you need cross connects 
between rooms, it's pretty expensive. And it's managed by them so running 
tagged traffic is a no go an other things. So out comes miles of fiber and 
rolls of gaffers tape every year. And miles of cat5. The lan party is 
fairly concentrated, but other departments all have other network needs. 
HD video streams outbound, voip telephones, ARTNet, etc.

It's crazy. But I guess it's a good way to keep skills sharp and learn new 
things.

Also, Steam and others should make a caching server solution similar to 
what exists in Apple OSX server.

             - Ethan

From rdobbins at arbor.net  Mon Aug  3 15:06:28 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Mon, 03 Aug 2015 22:06:28 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <Pine.LNX.4.64.1508031030430.6548@users.757.org>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com> <Pine.LNX.4.64.1508031030430.6548@users.757.org>
Message-ID: <99A68587-997C-4925-A9D8-A3538F3BD4A9@arbor.net>


On 3 Aug 2015, at 21:58, Ethan wrote:

> In the end, one of the griefers friends went and told on them, and 
> that's how they were discovered.

Pretty much how it works on the general Internet, too, it seems.

;>

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From nanog at ics-il.net  Mon Aug  3 15:07:11 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Aug 2015 10:07:11 -0500 (CDT)
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <Pine.LNX.4.64.1508031030430.6548@users.757.org>
Message-ID: <1785579917.1498.1438614466570.JavaMail.mhammett@ThunderFuck>

Venue Internet is the bane of events. Crazy expensive. Almost as expensive as a laborer in Chicago to move your box from the truck to your booth. ;-) 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Ethan" <telmnstr at 757.org> 
To: nanog at nanog.org 
Sent: Monday, August 3, 2015 9:58:35 AM 
Subject: Re: Quakecon: Network Operations Center tour 


I help with an event that has a pretty decent sized lan party as well. 
We're not just focused on the lan party, more of a rock concerts - huge 
arcade - panels - lan party type event. 

It was a few years ago that a mincraft "griefing" team came and attacked 
the network internally. At the time the BYOC LAN party I think was using 
3com switches on the edge. Griefers were doing MAC flooding or something 
that was causing the switches to fall over. And not just the switch they 
were connected to it was bringing down many of them. They were doing it in 
spurts and the people dealing with the network thought the issue was 
misbehaving equipment for a bit (it seemed foreign at that time that 
someone from the community would be doing it.) 

Mind you the people running things (volunteers) are running on little 
sleep, had no time to build out security appliances let alone watch a 
bunch of logs. They're pretty smart but you know - you get a bunch of 
smart people together they all bicker about how to do things their way. 

In the end, one of the griefers friends went and told on them, and that's 
how they were discovered. Badges yanked and banned for life. 

Most of these cons and events run on surplus hardware. Granted, these days 
there is more and more higher end stuff being cast away. More and more 10 
gig, Juniper, Force10 and other decent equipment coming into play. 

Getting bandwidth into the events is a pain. Huge venues are meant for 
large corporate events not lower budget cons and festivals. Venue pricing 
I believe is 750-1500$ per megabit. 100 megabit = $75,000 for the weekend. 
One year I rememeber there being a switch with 8 vlans on it sitting 
outside the back door with 8 clear modems spread out all blinking away. 
Geeks get creative. 

These days, a random family next door gets their business class FiOS paid 
for the entire year (with a good TV package) in return for a weekend or 
two a year of it being slammed. But that isn't keeping up with demand. 
I think sponsorship is in our future as far as bandwidth goes. 

Internally, the hotels charge for any ports. So if you need cross connects 
between rooms, it's pretty expensive. And it's managed by them so running 
tagged traffic is a no go an other things. So out comes miles of fiber and 
rolls of gaffers tape every year. And miles of cat5. The lan party is 
fairly concentrated, but other departments all have other network needs. 
HD video streams outbound, voip telephones, ARTNet, etc. 

It's crazy. But I guess it's a good way to keep skills sharp and learn new 
things. 

Also, Steam and others should make a caching server solution similar to 
what exists in Apple OSX server. 

- Ethan 


From mstorck at voipgate.com  Mon Aug  3 15:42:32 2015
From: mstorck at voipgate.com (Marc Storck)
Date: Mon, 3 Aug 2015 15:42:32 +0000
Subject: DE-CIX vs Equinix
In-Reply-To: <CAMDdSzPy79Vfir9kxaKdL6jydertA7bmjLuO2Y3oAOEcuCUvxg@mail.gmail.com>
References: <CAMDdSzP0B_Wq33V-0HgV6U7Vcd8+Nbzf6SrfWG74B5voKR7mkQ@mail.gmail.com>
 <688372940.1303.1438609524412.JavaMail.mhammett@ThunderFuck>
 <CAMDdSzPy79Vfir9kxaKdL6jydertA7bmjLuO2Y3oAOEcuCUvxg@mail.gmail.com>
Message-ID: <CD849CBA-85FB-456F-A8BC-4E97C288E314@voipgate.com>


> On 03 Aug 2015, at 15:50, Colton Conor <colton.conor at gmail.com> wrote:
> 
> How does  DE-CIX work if you want to cross connect over the exchange to
> another provider in a different on-net datacenter of the exchange in the
> same metro market?

I?m not sure, but you may be looking for the GlobePEER service

https://www.de-cix.net/products-services/globepeer/

This seems to be included in your port price.

Regards, Marc

From Matthew.Black at csulb.edu  Mon Aug  3 17:09:22 2015
From: Matthew.Black at csulb.edu (Matthew Black)
Date: Mon, 3 Aug 2015 17:09:22 +0000
Subject: [BULK] Verizon exiting California
In-Reply-To: <55BB8711.7090607@tiedyenetworks.com>
References: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck>
 <55BB8711.7090607@tiedyenetworks.com>
Message-ID: <ED78B1C68B84A14FA706D13A230D7B4378200811@ITS-MAIL02.campus.ad.csulb.edu>

I ran a few Google searches and came across a trove of complaints against Frontier. Seems they are far worse than GTE/Verizon. On the few occasions I have called for FIOS support, always reached someone knowledgeable and helpful. Not looking forward to the changeover, as the new owners have to pay off debts from their acquisition. That can only be accomplished through rate increases. I see a Verizon tech outside my kitchen window every two to three days as he replaces two nitrogen tanks keeping copper trunks pressurized against water intrusion.

matthew black
california state university, long beach


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike
Sent: Friday, July 31, 2015 7:33 AM
To: nanog at nanog.org
Subject: Re: [BULK] Verizon exiting California

On 07/31/2015 06:27 AM, Mike Hammett wrote:
> Can anyone else back that up (or refute it)?
>
>


I am a CLEC operating in California west, and I collocate with verizon. 
Yes, Verizon is proposing to sell it's wireline assets to Frontier and 
become effectively an all-wireless carrier.


Frontier is going to get a patchwork of ancient switches and poorly 
maintained outside plant, in rural areas that would require tens of 
millions of dollars in upgrades for sparely populaed areas it could 
never turn a profit on. I seriously wonder about the viability of taking 
on the debt to get those areas and even just maintain them, vz itself 
has done a very poor job and it presently operates a network where E911 
routinely fails along with pots for many, for weeks at a time. And 
somehow, Verizon has been allowed to skate along without being held to 
the fire for it's mandated utility / carrier of last resort obligations.

I worry that Frontier, with all the new added debt obligations, will not 
able to swallow this pill.

Mike-


From jason.leblanc at infusionsoft.com  Mon Aug  3 17:29:53 2015
From: jason.leblanc at infusionsoft.com (Jason LeBlanc)
Date: Mon, 3 Aug 2015 17:29:53 +0000
Subject: GoDaddy : DoS :: Contact
In-Reply-To: <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
References: <D1E4002A.2F3A3%jason.leblanc@infusionsoft.com>
 <B2808195-0458-4A4A-9D07-94B72813743F@beckman.org>
Message-ID: <D1E4ED93.2F404%jason.leblanc@infusionsoft.com>

Thanks Mel.

The ISP got back to me and has asked me to build a Juniper block list ACL for them so I am doing that now.

//Jason

From: Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>>
Date: Sunday, August 2, 2015 at 5:56 PM
To: Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>>
Cc: NANOG <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: GoDaddy : DoS :: Contact

Blackholing isn't what you want. That will still permit his source IP into your network, and only blackhole replies from your network, so the attack will still consume bandwidth. What you should request is a source IP ACL blocking that address at your upstream' border.

BGP is no help in these situations, unless you use a BGP-based DDoS protection service.

 -mel beckman

On Aug 2, 2015, at 5:17 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>> wrote:

Thanks Mel.  You are not being difficult, I meant DoS.  The network I inherited doesn?t have BGP yet so I have asked our upstream to blackhole it and I emailed abuse neither have happened yet.  I do block it but that?s after it hits our side.

//Jason

From: Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>>
Date: Sunday, August 2, 2015 at 4:20 PM
To: Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>>
Cc: NANOG <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: GoDaddy : DDoS :: Contact

Not to be difficult, but how can it be a DDoS attack if it?s coming from a single IP? Normally you would just block this IP at your borders or ask your upstreams to do so before it consumes your bandwidth. You still want to get GoDaddy to address the problem, of course, but you should do that via their abuse at godaddy.com<mailto:abuse at godaddy.com> contact, or their abuse page at https://supportcenter.godaddy.com/AbuseReport/Index (submit via the ?malware? button).

 -mel

On Aug 2, 2015, at 12:59 PM, Jason LeBlanc <jason.leblanc at infusionsoft.com<mailto:jason.leblanc at infusionsoft.com>> wrote:

My company is being DDoS'd by a single IP from a GoDaddy customer.

I havent had success with the abuse at godaddy.com<mailto:abuse at godaddy.com> email.  Was hoping someone
that could help might be watching the list and could contact me off-list.


//Jason



From morrowc.lists at gmail.com  Mon Aug  3 18:12:38 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 3 Aug 2015 14:12:38 -0400
Subject: [BULK] Verizon exiting California
In-Reply-To: <ED78B1C68B84A14FA706D13A230D7B4378200811@ITS-MAIL02.campus.ad.csulb.edu>
References: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck>
 <55BB8711.7090607@tiedyenetworks.com>
 <ED78B1C68B84A14FA706D13A230D7B4378200811@ITS-MAIL02.campus.ad.csulb.edu>
Message-ID: <CAL9jLabBW5dDMmBpXyv1K7A--+fCVGqnV1d1Vaq5as0O+5AiVw@mail.gmail.com>

On Mon, Aug 3, 2015 at 1:09 PM, Matthew Black <Matthew.Black at csulb.edu> wrote:
> I ran a few Google searches and came across a trove of complaints against Frontier. Seems they are far worse than GTE/Verizon. On the few occasions I have called for FIOS support, always reached someone knowledgeable and helpful. Not looking forward to the changeover, as the new owners have to pay off debts from their acquisition. That can only be accomplished through rate increases. I see a Verizon tech outside my kitchen window every two to three days as he replaces two nitrogen tanks keeping copper trunks pressurized against water intrusion.
>

though, on the positive side... maybe you'll see ipv6 on frontier fios
before the heat death of the universe? (*which is when vz fios folk
will see it, apparently).

From asr at latency.net  Mon Aug  3 18:37:11 2015
From: asr at latency.net (Adam Rothschild)
Date: Mon, 3 Aug 2015 14:37:11 -0400
Subject: [BULK] Verizon exiting California
In-Reply-To: <CAL9jLabBW5dDMmBpXyv1K7A--+fCVGqnV1d1Vaq5as0O+5AiVw@mail.gmail.com>
References: <900471531.5122.1438349265932.JavaMail.mhammett@ThunderFuck>
 <55BB8711.7090607@tiedyenetworks.com>
 <ED78B1C68B84A14FA706D13A230D7B4378200811@ITS-MAIL02.campus.ad.csulb.edu>
 <CAL9jLabBW5dDMmBpXyv1K7A--+fCVGqnV1d1Vaq5as0O+5AiVw@mail.gmail.com>
Message-ID: <CAPZUUwV3sdq0xgi8j2yDycYCzAvBZwz0ER49UMrN6Lx=96jPJQ@mail.gmail.com>

An additional advantage for Frontier customers, post acquisition:

  http://ipadmin.frontier.com/bilateralpeering_policy.pdf
  http://www.verizonenterprise.com/terms/peering/

$0.02,
-a

On Mon, Aug 3, 2015 at 2:12 PM, Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> On Mon, Aug 3, 2015 at 1:09 PM, Matthew Black <Matthew.Black at csulb.edu>
> wrote:
> > I ran a few Google searches and came across a trove of complaints
> against Frontier. Seems they are far worse than GTE/Verizon. On the few
> occasions I have called for FIOS support, always reached someone
> knowledgeable and helpful. Not looking forward to the changeover, as the
> new owners have to pay off debts from their acquisition. That can only be
> accomplished through rate increases. I see a Verizon tech outside my
> kitchen window every two to three days as he replaces two nitrogen tanks
> keeping copper trunks pressurized against water intrusion.
> >
>
> though, on the positive side... maybe you'll see ipv6 on frontier fios
> before the heat death of the universe? (*which is when vz fios folk
> will see it, apparently).
>

From nanogml at Mail.DDoS-Mitigator.net  Mon Aug  3 20:52:17 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Mon, 3 Aug 2015 13:52:17 -0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <Pine.LNX.4.64.1508031030430.6548@users.757.org>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com>
 <Pine.LNX.4.64.1508031030430.6548@users.757.org>
Message-ID: <20150803205217.GA15703@Mail.DDoS-Mitigator.net>


hi ethan

On 08/03/15 at 10:58am, Ethan wrote:
> 
> Getting bandwidth into the events is a pain. Huge venues are meant for large
> corporate events not lower budget cons and festivals. Venue pricing I
> believe is 750-1500$ per megabit. 100 megabit = $75,000 for the weekend. One
> year I rememeber there being a switch with 8 vlans on it sitting outside the
> back door with 8 clear modems spread out all blinking away.

for connectivity, does the hotels and convention centers still have wifi jammers 
so you cannot use your own 56Mbit wifi to get connection to the outside world ? 
if possible, stick a bunch of dark mirrored-glass covered vans outside the event
for wifi access

the "expensive part" is due to labor unions that control the workers and
everything else working the capitalistic "supply" and demand model to the max.
the unions disallow you to carry your own gear from your car to the event
which is good and bad ... 

i dont buy their $10 budweiser, $5 water, etc especially when no outside drinks
allowed inside the event

> Geeks get creative.

good thing .... and no unions to control what we did/do ...

another ( 40yr old ) boat that has long since sailed since the days
of why we had to fight off the unions in the electronics industrt ... 

pixie dust
alvin

From mikea at mikea.ath.cx  Mon Aug  3 21:03:27 2015
From: mikea at mikea.ath.cx (mikea)
Date: Mon, 3 Aug 2015 16:03:27 -0500
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <20150803205217.GA15703@Mail.DDoS-Mitigator.net>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com>
 <Pine.LNX.4.64.1508031030430.6548@users.757.org>
 <20150803205217.GA15703@Mail.DDoS-Mitigator.net>
Message-ID: <20150803210327.GA16357@mikea.ath.cx>

On Mon, Aug 03, 2015 at 01:52:17PM -0700, alvin nanog wrote:
> 
> hi ethan
> 
> On 08/03/15 at 10:58am, Ethan wrote:
> > 
> > Getting bandwidth into the events is a pain. Huge venues are meant for large
> > corporate events not lower budget cons and festivals. Venue pricing I
> > believe is 750-1500$ per megabit. 100 megabit = $75,000 for the weekend. One
> > year I rememeber there being a switch with 8 vlans on it sitting outside the
> > back door with 8 clear modems spread out all blinking away.
> 
> for connectivity, does the hotels and convention centers still have wifi jammers 
> so you cannot use your own 56Mbit wifi to get connection to the outside world ? 
> if possible, stick a bunch of dark mirrored-glass covered vans outside the event
> for wifi access

In the US, the FCC has ruled that wifi jammers violate one or more parts of
the FCC Rules and Regs. Marriott hotels paid a USD600K fine. A quick Google
search on "FCC hotel jammer" pulls up a great many hits, of which these are
the first seven: 

Jammer Enforcement | FCC.gov
https://www.fcc.gov/.../jamme...
U.S. Federal Communications Commission
Federal law prohibits the operation, marketing, or sale of any type of jamming equipment, including devices that interfere with cellular and Personal ...

Marriott to Pay $600K to Resolve WiFi-Blocking ... - FCC
https://www.fcc.gov/.../marrio...
U.S. Federal Communications Commission
Oct 3, 2014 - Hotel Operator Admits Employees Improperly Used Wi-Fi Monitoring ... The complainant alleged that the Gaylord Opryland was ?jamming ...

WARNING: Wi-Fi Blocking is Prohibited | FCC.gov
https://www.fcc.gov/.../warnin...
U.S. Federal Communications Commission
Jan 27, 2015 - which hotels and other commercial establishments block wireless ... into this kind of unlawful activity by the operator of a resort hotel and ...

FCC warns hotels against blocking guests' wi-fi
www.consumeraffairs.com/.../fcc-warns-hotels-against-blocking-guests-...
Jan 28, 2015 - Hotels, miffed by guests who used their own wi-fi hotspots instead of paying ... It's illegal to jam legal radio transmissions of any kind, FCC vows tough enforcement ... Some had argued that jamming wi-fi and cellphone calls is ...

Hotels ask FCC for permission to block guests' personal Wi ...
www.pcworld.com/.../hotel-group-asks-fcc-for-permission-to-...
PC World
Dec 22, 2014 - Marriott argued some hotspot blocking may be justified, as long as the hotel isn't using illegal signal jammers. Unlicensed Wi-Fi hotspots ...

FCC fines Marriott $600,000 for blocking guests' Wi-Fi ...
www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/
CNN
Oct 4, 2014 - It's the first time the FCC has investigated a hotel property for ... sense, where someone uses a jammer device to block wireless signals. Instead ...

How This Hotel Made Sure Your Wi-Fi Hotspot Sucked ...
readwrite.com/2014/.../marriott-nashville-opryland-jams-wifi-internet-wt...
Oct 4, 2014 - Caught by FCC for Wi-Fi jamming, Marriott's still not sorry.

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin 

From rdobbins at arbor.net  Mon Aug  3 21:09:45 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Tue, 04 Aug 2015 04:09:45 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <20150803210327.GA16357@mikea.ath.cx>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com> <Pine.LNX.4.64.1508031030430.6548@users.757.org>
 <20150803205217.GA15703@Mail.DDoS-Mitigator.net>
 <20150803210327.GA16357@mikea.ath.cx>
Message-ID: <2567811D-5196-4B13-821F-4FC2EE67070D@arbor.net>

On 4 Aug 2015, at 4:03, mikea wrote:

> In the US, the FCC has ruled that wifi jammers violate one or more 
> parts of the FCC Rules and Regs.

I travel quite a bit worldwide, and I've never run into this.  I run my 
portable AP on 5GHz, FWIW.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From bugs at debmi.com  Mon Aug  3 21:38:56 2015
From: bugs at debmi.com (Mr Bugs)
Date: Mon, 3 Aug 2015 17:38:56 -0400
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <2567811D-5196-4B13-821F-4FC2EE67070D@arbor.net>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com>
 <Pine.LNX.4.64.1508031030430.6548@users.757.org>
 <20150803205217.GA15703@Mail.DDoS-Mitigator.net>
 <20150803210327.GA16357@mikea.ath.cx>
 <2567811D-5196-4B13-821F-4FC2EE67070D@arbor.net>
Message-ID: <CADNoncunVrgTV5gmqJwt8tqv-k1iQHZ-nHX1M6qnwBfFkN6KFg@mail.gmail.com>

The WiFi jammers have an interesting MO. They don't throw up static on the
frequency, that would also block their own wifi. They spoof
de-authentication packets. I've been looking for a way to detect this kind
of jamming because my WiFi sucks and I live next to three hotels, what you
get for living in downtown Atlanta.

On Mon, Aug 3, 2015 at 5:09 PM, Roland Dobbins <rdobbins at arbor.net> wrote:

> On 4 Aug 2015, at 4:03, mikea wrote:
>
> In the US, the FCC has ruled that wifi jammers violate one or more parts
>> of the FCC Rules and Regs.
>>
>
> I travel quite a bit worldwide, and I've never run into this.  I run my
> portable AP on 5GHz, FWIW.
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
>

From rdobbins at arbor.net  Mon Aug  3 21:42:27 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Tue, 04 Aug 2015 04:42:27 +0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CADNoncunVrgTV5gmqJwt8tqv-k1iQHZ-nHX1M6qnwBfFkN6KFg@mail.gmail.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com> <Pine.LNX.4.64.1508031030430.6548@users.757.org>
 <20150803205217.GA15703@Mail.DDoS-Mitigator.net>
 <20150803210327.GA16357@mikea.ath.cx>
 <2567811D-5196-4B13-821F-4FC2EE67070D@arbor.net>
 <CADNoncunVrgTV5gmqJwt8tqv-k1iQHZ-nHX1M6qnwBfFkN6KFg@mail.gmail.com>
Message-ID: <524BFB53-832D-4189-818D-DDA1D9D05C9B@arbor.net>

On 4 Aug 2015, at 4:38, Mr Bugs wrote:

> They don't throw up static on the frequency, that would also block 
> their own wifi. They spoof
> de-authentication packets.

Sure - I'm saying, I don't see this anywhere, is it possible most of 
this activity is on 2.4GHz and not 5GHz?

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From nanogml at Mail.DDoS-Mitigator.net  Mon Aug  3 22:18:13 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Mon, 3 Aug 2015 15:18:13 -0700
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CADNoncunVrgTV5gmqJwt8tqv-k1iQHZ-nHX1M6qnwBfFkN6KFg@mail.gmail.com>
References: <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <55BF27E6.5070905@gmail.com>
 <Pine.LNX.4.64.1508031030430.6548@users.757.org>
 <20150803205217.GA15703@Mail.DDoS-Mitigator.net>
 <20150803210327.GA16357@mikea.ath.cx>
 <2567811D-5196-4B13-821F-4FC2EE67070D@arbor.net>
 <CADNoncunVrgTV5gmqJwt8tqv-k1iQHZ-nHX1M6qnwBfFkN6KFg@mail.gmail.com>
Message-ID: <20150803221813.GA18041@Mail.DDoS-Mitigator.net>


hi mr bugs :-)

On 08/03/15 at 05:38pm, Mr Bugs wrote:
> The WiFi jammers have an interesting MO. They don't throw up static on the
> frequency, that would also block their own wifi. They spoof
> de-authentication packets. I've been looking for a way to detect this kind
> of jamming because my WiFi sucks and I live next to three hotels, what you
> get for living in downtown Atlanta.

i forgot if kismet showed signal strengths of the wifi ap's ...
"stronger" signal wins over weaker signal strengths

might not be a jamming issue ??  kismet and tcpdump might be able to show
you the packets you're looking for ?

what happens if you put up a properly designed wire mess around the exterior 
windows of your house/condo/aptr??

i'd wag/blindly say the area is probably full of rogue wifi ap's floating around
where evergbody is trying to wardrive each other and pick up un-suspecting
traveling visitor's login and passwd info ... signals bouncing off steel/concrete
is not ez to filter out what should be random background white noise if
you're sitting next to the radiating source ..

pixie dust
alvin
# DDoS-Mitigator.net  
# DDoS-Simulator.net  

From tqr2813d376cjozqap1l at tutanota.com  Mon Aug  3 22:28:05 2015
From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com)
Date: Mon, 3 Aug 2015 22:28:05 +0000 (UTC)
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <CADNoncunVrgTV5gmqJwt8tqv-k1iQHZ-nHX1M6qnwBfFkN6KFg@mail.gmail.com>
References: <<CC2099EB-2EE5-46ED-9DCC-F4FE5F5B95DB@arbor.net>>
 <1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>
 <<1394981054.43.1438534214823.JavaMail.mhammett@ThunderFuck>>
 <C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>
 <<C11FAFFF-52A5-4C99-A3C1-D1670E18880D@arbor.net>>
 <CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>
 <<CAMcDhomugfi8gS7s61WZv5GeEn2+b9x_h6xZqwOBRtNyFiyu3Q@mail.gmail.com>>
 <55BF27E6.5070905@gmail.com> <<55BF27E6.5070905@gmail.com>>
 <Pine.LNX.4.64.1508031030430.6548@users.757.org>
 <<Pine.LNX.4.64.1508031030430.6548@users.757.org>>
 <20150803205217.GA15703@Mail.DDoS-Mitigator.net>
 <<20150803205217.GA15703@Mail.DDoS-Mitigator.net>>
 <20150803210327.GA16357@mikea.ath.cx> <<20150803210327.GA16357@mikea.ath.cx>>
 <2567811D-5196-4B13-821F-4FC2EE67070D@arbor.net>
 <<2567811D-5196-4B13-821F-4FC2EE67070D@arbor.net>>
 <CADNoncunVrgTV5gmqJwt8tqv-k1iQHZ-nHX1M6qnwBfFkN6KFg@mail.gmail.com>
Message-ID: <JvpfRpB----0@tutanota.com>

3. Aug 2015 21:38 by bugs at debmi.com:


> The WiFi jammers have an interesting MO. They don't throw up static on the
> frequency, that would also block their own wifi. They spoof
> de-authentication packets. I've been looking for a way to detect this kind
> of jamming because my WiFi sucks and I live next to three hotels, what you
> get for living in downtown Atlanta.
>

Blocking WiFi (jamming or deauth attacks) isn't allowed. The Marriott 
recently got slapped with a fine for doing so. Tell the FCC that the local 
hotels are doing it:

??? https://www.fcc.gov/document/warning-wi-fi-blocking-prohibited
??? 
http://arstechnica.com/tech-policy/2015/01/fcc-blocking-wi-fi-in-hotels-is-prohibited
??? https://www.fcc.gov/encyclopedia/jammer-enforcement
??? https://transition.fcc.gov/eb/jammerenforcement/jamfaq.pdf

From kb3ien+nanog at databit7.com  Mon Aug  3 22:52:58 2015
From: kb3ien+nanog at databit7.com (kb3ien+nanog at databit7.com)
Date: Mon, 3 Aug 2015 22:52:58 +0000 (UTC)
Subject: ISPs/Carriers in LATA 138
Message-ID: <Pine.NEB.4.64.1507110403550.18172@andromeda.ziaspace.com>


I'm looking for a solution to provide one-weekend per year access in a 
rural area 20 km outside Binghamton NY, LATA 138


Can anyone provide any recomendations?

Robin

kb3ien


From keefe-af at ethoplex.com  Mon Aug  3 22:56:09 2015
From: keefe-af at ethoplex.com (Keefe John)
Date: Mon, 03 Aug 2015 17:56:09 -0500
Subject: ISPs/Carriers in LATA 138
In-Reply-To: <Pine.NEB.4.64.1507110403550.18172@andromeda.ziaspace.com>
References: <Pine.NEB.4.64.1507110403550.18172@andromeda.ziaspace.com>
Message-ID: <55BFF189.406@ethoplex.com>

Try the local WISP.

http://www.plexicomm.net/

Keefe

On 8/3/2015 5:52 PM, kb3ien+nanog at databit7.com wrote:
>
> I'm looking for a solution to provide one-weekend per year access in a 
> rural area 20 km outside Binghamton NY, LATA 138
>
>
> Can anyone provide any recomendations?
>
> Robin
>
> kb3ien
>


From sthomas at lart.net  Mon Aug  3 23:12:14 2015
From: sthomas at lart.net (Sam Thomas)
Date: Mon, 3 Aug 2015 18:12:14 -0500
Subject: Quakecon: Network Operations Center tour
In-Reply-To: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1508011519430.23165@cnex.qbaryna.pbz>
Message-ID: <CAJ_saMGa=DFPRSegPPqUDm=ndOFeqxPYQD6r5exJjeQ83m-F4w@mail.gmail.com>

Very interesting. I still have in ~/ a 6509 config I did for an early
Quakecon (or some predecessor or similar event) as a favor for a friend in
~2003. The more things change...

BTW, ISTR there's some dark fiber between Anatole and INFOMART. I'm sure
there's somebody in the 'mart who could provide $REALLY_FAST connectivity
if the fiber is still in place.

On Sat, Aug 1, 2015 at 2:27 PM, Sean Donelan <sean at donelan.com> wrote:

>
> Non-work, work related information.  Many NANOG geeks might be interested
> in this video tour of the Quakecon NOC tour.  As any ISP operator knows,
> gamers complain faster about problems than any NMS, so you've got to
> admire the bravery of any NOC in the middle of a gaming convention floor.
>
> What Powers Quakecon | Network Operations Center Tour
> https://www.youtube.com/watch?v=mOv62lBdlXU
>
>

From bhatton at htva.net  Mon Aug  3 23:13:42 2015
From: bhatton at htva.net (Benjamin Hatton)
Date: Mon, 3 Aug 2015 19:13:42 -0400
Subject: ISPs/Carriers in LATA 138
In-Reply-To: <Pine.NEB.4.64.1507110403550.18172@andromeda.ziaspace.com>
References: <Pine.NEB.4.64.1507110403550.18172@andromeda.ziaspace.com>
Message-ID: <CADvg1U9qAXuDQGFL2CqVuwDMfhAqnOZCcBGF_gB=VaT9CurGAw@mail.gmail.com>

I have Fiber / DOCSIS / EPON in some rural areas of LATA 138,  Where
exactly are you looking? feel free to respond off list.



On Mon, Aug 3, 2015 at 6:52 PM, <kb3ien+nanog at databit7.com> wrote:

>
> I'm looking for a solution to provide one-weekend per year access in a
> rural area 20 km outside Binghamton NY, LATA 138
>
>
> Can anyone provide any recomendations?
>
> Robin
>
> kb3ien
>
>

From nanog at ics-il.net  Tue Aug  4 00:27:40 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 3 Aug 2015 19:27:40 -0500 (CDT)
Subject: [BULK] Verizon exiting California
In-Reply-To: <CAPZUUwV3sdq0xgi8j2yDycYCzAvBZwz0ER49UMrN6Lx=96jPJQ@mail.gmail.com>
Message-ID: <1442546064.4206.1438648072273.JavaMail.mhammett@ThunderFuck>

"Revision 7 (8/3/2006) " 

That now explains why they were talking about ATM exchanges and DS3 international links... 

Speaking of Frontier peering... does anyone have a contact over there? They haven't responded to my e-mail. I didn't send more than one (I think) because I didn't want to be annoying. Some may call that an impossible task. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Adam Rothschild" <asr at latency.net> 
To: "Christopher Morrow" <morrowc.lists at gmail.com> 
Cc: nanog at nanog.org 
Sent: Monday, August 3, 2015 1:37:11 PM 
Subject: Re: [BULK] Verizon exiting California 

An additional advantage for Frontier customers, post acquisition: 

http://ipadmin.frontier.com/bilateralpeering_policy.pdf 
http://www.verizonenterprise.com/terms/peering/ 

$0.02, 
-a 

On Mon, Aug 3, 2015 at 2:12 PM, Christopher Morrow <morrowc.lists at gmail.com> 
wrote: 

> On Mon, Aug 3, 2015 at 1:09 PM, Matthew Black <Matthew.Black at csulb.edu> 
> wrote: 
> > I ran a few Google searches and came across a trove of complaints 
> against Frontier. Seems they are far worse than GTE/Verizon. On the few 
> occasions I have called for FIOS support, always reached someone 
> knowledgeable and helpful. Not looking forward to the changeover, as the 
> new owners have to pay off debts from their acquisition. That can only be 
> accomplished through rate increases. I see a Verizon tech outside my 
> kitchen window every two to three days as he replaces two nitrogen tanks 
> keeping copper trunks pressurized against water intrusion. 
> > 
> 
> though, on the positive side... maybe you'll see ipv6 on frontier fios 
> before the heat death of the universe? (*which is when vz fios folk 
> will see it, apparently). 
> 


From jra at baylink.com  Tue Aug  4 14:03:33 2015
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 04 Aug 2015 10:03:33 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
Message-ID: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>

Everyone got BIND updated?

http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-could-hamstring-huge-swaths-of-internet/
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From bortzmeyer at nic.fr  Tue Aug  4 14:17:56 2015
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 4 Aug 2015 16:17:56 +0200
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
Message-ID: <20150804141756.GA14301@nic.fr>

On Tue, Aug 04, 2015 at 10:03:33AM -0400,
 Jay Ashworth <jra at baylink.com> wrote 
 a message of 6 lines which said:

> Everyone got BIND updated?

For instance by replacing it with NSD or Unbound?

From morrowc.lists at gmail.com  Tue Aug  4 14:38:21 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 4 Aug 2015 10:38:21 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <20150804141756.GA14301@nic.fr>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <20150804141756.GA14301@nic.fr>
Message-ID: <CAL9jLaZmJP_2KOPhFZSfSxigCBbkF5U6ZfT7xA6sckOQtXNdBg@mail.gmail.com>

On Tue, Aug 4, 2015 at 10:17 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> On Tue, Aug 04, 2015 at 10:03:33AM -0400,
>  Jay Ashworth <jra at baylink.com> wrote
>  a message of 6 lines which said:
>
>> Everyone got BIND updated?
>
> For instance by replacing it with NSD or Unbound?

always great to jump ship from one platform to another ... under
stress and without knowing scaling, management, etc properties.

Also, it's not like the alternatives have clean shorts when it comes
to code mistakes, right?

From jgreco at ns.sol.net  Tue Aug  4 15:01:27 2015
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 4 Aug 2015 10:01:27 -0500 (CDT)
Subject: Exploits start against flaw that could hamstring huge swaths of
In-Reply-To: <20150804141756.GA14301@nic.fr>
Message-ID: <201508041501.t74F1Rgv095600@aurora.sol.net>

> On Tue, Aug 04, 2015 at 10:03:33AM -0400,
>  Jay Ashworth <jra at baylink.com> wrote 
>  a message of 6 lines which said:
> 
> > Everyone got BIND updated?
> 
> For instance by replacing it with NSD or Unbound?

Or doing something better like not just replacing one evil with another,
and instead moving to a heterogeneous environment where possible.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

From leonardo.ortiz at marisolsa.com  Tue Aug  4 15:06:36 2015
From: leonardo.ortiz at marisolsa.com (Leonardo Oliveira Ortiz)
Date: Tue, 4 Aug 2015 15:06:36 +0000
Subject: RES: Exploits start against flaw that could hamstring huge swaths of
In-Reply-To: <201508041501.t74F1Rgv095600@aurora.sol.net>
References: <20150804141756.GA14301@nic.fr>
 <201508041501.t74F1Rgv095600@aurora.sol.net>
Message-ID: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>

So, you guys recommend replace Bind for another option ?


-----Mensagem original-----
De: NANOG [mailto:nanog-bounces at nanog.org] Em nome de Joe Greco
Enviada em: ter?a-feira, 4 de agosto de 2015 12:01
Para: Stephane Bortzmeyer
Cc: nanog at nanog.org
Assunto: Re: Exploits start against flaw that could hamstring huge swaths of

> On Tue, Aug 04, 2015 at 10:03:33AM -0400,  Jay Ashworth 
> <jra at baylink.com> wrote  a message of 6 lines which said:
> 
> > Everyone got BIND updated?
> 
> For instance by replacing it with NSD or Unbound?

Or doing something better like not just replacing one evil with another, and instead moving to a heterogeneous environment where possible.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

From jimpop at gmail.com  Tue Aug  4 15:15:54 2015
From: jimpop at gmail.com (Jim Popovitch)
Date: Tue, 4 Aug 2015 11:15:54 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
In-Reply-To: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
References: <20150804141756.GA14301@nic.fr>
 <201508041501.t74F1Rgv095600@aurora.sol.net>
 <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
Message-ID: <CAGfsgR0ZfhGZDaP-ZX8vZyfNRwkqV-wKr9HQ8uVSa7JJKA02+w@mail.gmail.com>

On Tue, Aug 4, 2015 at 11:06 AM, Leonardo Oliveira Ortiz
<leonardo.ortiz at marisolsa.com> wrote:
> So, you guys recommend replace Bind for another option ?

The humorous thing is that the security researcher who showed the
recent bind9 error (note: it isn't a vulnerability or a hack, it's
just a way to remotely crash named), well, he criticized bind9 for
doing more than simple basic name services.  So, it's very easy to
find bind9 alternatives if you are only looking for basic minimal DNS
functionality.  But once you start looking for features... well there
aren't many options.

-Jim P.

From jgreco at ns.sol.net  Tue Aug  4 15:46:34 2015
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 4 Aug 2015 10:46:34 -0500 (CDT)
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
Message-ID: <201508041546.t74FkZlN096153@aurora.sol.net>

> So, you guys recommend replace Bind for another option ?

No.  Replacing one occasionally faulty product with another occasionally
faulty product is foolish.  There's no particular reason to think that
another product will be impervious to code bugs.  What I was suggesting
was to use several different devices, much as some networks prefer to
buy some Cisco gear and some Juniper gear and make them redundant, or
as a well-built ZFS storage array consists of drives from different
manufacturers.

Heterogeneous environments tend to be more resilient because they are
less likely to all suffer the same defect at once.  Problems still result
in some pain and trouble, but it usually doesn't result in a service
outage.

This doesn't seem like a horribly catastrophic bug in any case.  Anyone 
who is reliant on a critical bit like a DNS server probably has it set 
up to automatically restart if it doesn't exit cleanly.  If you don't,
you should!

So if it matters to you, I suggest that you instead use a combination
of different products, and you'll be more resilient.  If you have two
recursers for your customers, one can be BIND and one can be Unbound. 
And when some critical vuln comes along and knocks out Unbound, you'll 
still be resolving names.  Ditto BIND.  You're not likely to see both
happen at the same time.

However, at least here, we actually *use* TSIG updates, and other 
functionality that'd be hard to replace (BIND9 is pretty much THE only
option for some functionality).

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

From khelms at zcorum.com  Tue Aug  4 15:29:41 2015
From: khelms at zcorum.com (Scott Helms)
Date: Tue, 4 Aug 2015 11:29:41 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <201508041546.t74FkZlN096153@aurora.sol.net>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
Message-ID: <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>

With the (large) caveat that heterogenous networks are more subject to
human error in many cases.
On Aug 4, 2015 9:25 AM, "Joe Greco" <jgreco at ns.sol.net> wrote:

> > So, you guys recommend replace Bind for another option ?
>
> No.  Replacing one occasionally faulty product with another occasionally
> faulty product is foolish.  There's no particular reason to think that
> another product will be impervious to code bugs.  What I was suggesting
> was to use several different devices, much as some networks prefer to
> buy some Cisco gear and some Juniper gear and make them redundant, or
> as a well-built ZFS storage array consists of drives from different
> manufacturers.
>
> Heterogeneous environments tend to be more resilient because they are
> less likely to all suffer the same defect at once.  Problems still result
> in some pain and trouble, but it usually doesn't result in a service
> outage.
>
> This doesn't seem like a horribly catastrophic bug in any case.  Anyone
> who is reliant on a critical bit like a DNS server probably has it set
> up to automatically restart if it doesn't exit cleanly.  If you don't,
> you should!
>
> So if it matters to you, I suggest that you instead use a combination
> of different products, and you'll be more resilient.  If you have two
> recursers for your customers, one can be BIND and one can be Unbound.
> And when some critical vuln comes along and knocks out Unbound, you'll
> still be resolving names.  Ditto BIND.  You're not likely to see both
> happen at the same time.
>
> However, at least here, we actually *use* TSIG updates, and other
> functionality that'd be hard to replace (BIND9 is pretty much THE only
> option for some functionality).
>
> ... JG
> --
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and]
> then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail
> spam(CNN)
> With 24 million small businesses in the US alone, that's way too many
> apples.
>

From morrowc.lists at gmail.com  Tue Aug  4 15:38:11 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 4 Aug 2015 11:38:11 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
Message-ID: <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>

On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com> wrote:
> With the (large) caveat that heterogenous networks are more subject to
> human error in many cases.

<cough>automate!</cough>

> On Aug 4, 2015 9:25 AM, "Joe Greco" <jgreco at ns.sol.net> wrote:
>
>> > So, you guys recommend replace Bind for another option ?
>>
>> No.  Replacing one occasionally faulty product with another occasionally
>> faulty product is foolish.  There's no particular reason to think that
>> another product will be impervious to code bugs.  What I was suggesting
>> was to use several different devices, much as some networks prefer to
>> buy some Cisco gear and some Juniper gear and make them redundant, or
>> as a well-built ZFS storage array consists of drives from different
>> manufacturers.
>>
>> Heterogeneous environments tend to be more resilient because they are
>> less likely to all suffer the same defect at once.  Problems still result
>> in some pain and trouble, but it usually doesn't result in a service
>> outage.
>>
>> This doesn't seem like a horribly catastrophic bug in any case.  Anyone
>> who is reliant on a critical bit like a DNS server probably has it set
>> up to automatically restart if it doesn't exit cleanly.  If you don't,
>> you should!
>>
>> So if it matters to you, I suggest that you instead use a combination
>> of different products, and you'll be more resilient.  If you have two
>> recursers for your customers, one can be BIND and one can be Unbound.
>> And when some critical vuln comes along and knocks out Unbound, you'll
>> still be resolving names.  Ditto BIND.  You're not likely to see both
>> happen at the same time.
>>
>> However, at least here, we actually *use* TSIG updates, and other
>> functionality that'd be hard to replace (BIND9 is pretty much THE only
>> option for some functionality).
>>
>> ... JG
>> --
>> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
>> "We call it the 'one bite at the apple' rule. Give me one chance [and]
>> then I
>> won't contact you again." - Direct Marketing Ass'n position on e-mail
>> spam(CNN)
>> With 24 million small businesses in the US alone, that's way too many
>> apples.
>>

From Valdis.Kletnieks at vt.edu  Tue Aug  4 15:45:59 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 04 Aug 2015 11:45:59 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: Your message of "Tue, 04 Aug 2015 15:06:36 -0000."
 <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
References: <20150804141756.GA14301@nic.fr>
 <201508041501.t74F1Rgv095600@aurora.sol.net>
 <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
Message-ID: <9929.1438703159@turing-police.cc.vt.edu>

On Tue, 04 Aug 2015 15:06:36 -0000, Leonardo Oliveira Ortiz said:
> So, you guys recommend replace Bind for another option ?

The *good* recommendation is to get some onboard security clue, and
learn procedures to mitigate the inevitable exploits against flaws in
infrastructure software.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150804/148b5179/attachment.pgp>

From khelms at zcorum.com  Tue Aug  4 15:46:51 2015
From: khelms at zcorum.com (Scott Helms)
Date: Tue, 4 Aug 2015 11:46:51 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
Message-ID: <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>

Automation just means your mistake goes many more places more quickly.
On Aug 4, 2015 9:38 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
wrote:

> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com> wrote:
> > With the (large) caveat that heterogenous networks are more subject to
> > human error in many cases.
>
> <cough>automate!</cough>
>
> > On Aug 4, 2015 9:25 AM, "Joe Greco" <jgreco at ns.sol.net> wrote:
> >
> >> > So, you guys recommend replace Bind for another option ?
> >>
> >> No.  Replacing one occasionally faulty product with another occasionally
> >> faulty product is foolish.  There's no particular reason to think that
> >> another product will be impervious to code bugs.  What I was suggesting
> >> was to use several different devices, much as some networks prefer to
> >> buy some Cisco gear and some Juniper gear and make them redundant, or
> >> as a well-built ZFS storage array consists of drives from different
> >> manufacturers.
> >>
> >> Heterogeneous environments tend to be more resilient because they are
> >> less likely to all suffer the same defect at once.  Problems still
> result
> >> in some pain and trouble, but it usually doesn't result in a service
> >> outage.
> >>
> >> This doesn't seem like a horribly catastrophic bug in any case.  Anyone
> >> who is reliant on a critical bit like a DNS server probably has it set
> >> up to automatically restart if it doesn't exit cleanly.  If you don't,
> >> you should!
> >>
> >> So if it matters to you, I suggest that you instead use a combination
> >> of different products, and you'll be more resilient.  If you have two
> >> recursers for your customers, one can be BIND and one can be Unbound.
> >> And when some critical vuln comes along and knocks out Unbound, you'll
> >> still be resolving names.  Ditto BIND.  You're not likely to see both
> >> happen at the same time.
> >>
> >> However, at least here, we actually *use* TSIG updates, and other
> >> functionality that'd be hard to replace (BIND9 is pretty much THE only
> >> option for some functionality).
> >>
> >> ... JG
> >> --
> >> Joe Greco - sol.net Network Services - Milwaukee, WI -
> http://www.sol.net
> >> "We call it the 'one bite at the apple' rule. Give me one chance [and]
> >> then I
> >> won't contact you again." - Direct Marketing Ass'n position on e-mail
> >> spam(CNN)
> >> With 24 million small businesses in the US alone, that's way too many
> >> apples.
> >>
>

From jared at puck.nether.net  Tue Aug  4 16:00:32 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 4 Aug 2015 12:00:32 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
Message-ID: <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>

I recommend using DNSDIST to balance traffic at a protocol level as you can have implementation diversity on the backside. 

I can send an example config out later for people. You can balance to bind NSD and others all at the same time :-) just move your SPoF

Jared Mauch

> On Aug 4, 2015, at 10:03 AM, Jay Ashworth <jra at baylink.com> wrote:
> 
> Everyone got BIND updated?
> 
> http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-could-hamstring-huge-swaths-of-internet/
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From morrowc.lists at gmail.com  Tue Aug  4 16:21:14 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 4 Aug 2015 12:21:14 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
Message-ID: <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>

On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms <khelms at zcorum.com> wrote:
> Automation just means your mistake goes many more places more quickly.
>

and letting people keep poking at things that computers should be
doing is... much worse. people do not have reliability and
repeat-ability over time.


If you fear 'many more places' problems, improve your testing.

> On Aug 4, 2015 9:38 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
> wrote:
>>
>> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com> wrote:
>> > With the (large) caveat that heterogenous networks are more subject to
>> > human error in many cases.
>>
>> <cough>automate!</cough>
>>
>> > On Aug 4, 2015 9:25 AM, "Joe Greco" <jgreco at ns.sol.net> wrote:
>> >
>> >> > So, you guys recommend replace Bind for another option ?
>> >>
>> >> No.  Replacing one occasionally faulty product with another
>> >> occasionally
>> >> faulty product is foolish.  There's no particular reason to think that
>> >> another product will be impervious to code bugs.  What I was suggesting
>> >> was to use several different devices, much as some networks prefer to
>> >> buy some Cisco gear and some Juniper gear and make them redundant, or
>> >> as a well-built ZFS storage array consists of drives from different
>> >> manufacturers.
>> >>
>> >> Heterogeneous environments tend to be more resilient because they are
>> >> less likely to all suffer the same defect at once.  Problems still
>> >> result
>> >> in some pain and trouble, but it usually doesn't result in a service
>> >> outage.
>> >>
>> >> This doesn't seem like a horribly catastrophic bug in any case.  Anyone
>> >> who is reliant on a critical bit like a DNS server probably has it set
>> >> up to automatically restart if it doesn't exit cleanly.  If you don't,
>> >> you should!
>> >>
>> >> So if it matters to you, I suggest that you instead use a combination
>> >> of different products, and you'll be more resilient.  If you have two
>> >> recursers for your customers, one can be BIND and one can be Unbound.
>> >> And when some critical vuln comes along and knocks out Unbound, you'll
>> >> still be resolving names.  Ditto BIND.  You're not likely to see both
>> >> happen at the same time.
>> >>
>> >> However, at least here, we actually *use* TSIG updates, and other
>> >> functionality that'd be hard to replace (BIND9 is pretty much THE only
>> >> option for some functionality).
>> >>
>> >> ... JG
>> >> --
>> >> Joe Greco - sol.net Network Services - Milwaukee, WI -
>> >> http://www.sol.net
>> >> "We call it the 'one bite at the apple' rule. Give me one chance [and]
>> >> then I
>> >> won't contact you again." - Direct Marketing Ass'n position on e-mail
>> >> spam(CNN)
>> >> With 24 million small businesses in the US alone, that's way too many
>> >> apples.
>> >>

From jgreco at ns.sol.net  Tue Aug  4 16:48:10 2015
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 4 Aug 2015 11:48:10 -0500 (CDT)
Subject: RES: Exploits start against flaw that could hamstring huge swaths
In-Reply-To: <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
Message-ID: <201508041648.t74GmAhP097198@aurora.sol.net>

> With the (large) caveat that heterogenous networks are more subject to
> human error in many cases.

Indeed.  Everything comes with tradeoffs.  More intimate familiarity
with the product and a uniformity of deployment strategy has made it
more practical here to stick with BIND; an update is a simple matter
of a tarball and running a script that manages the dirty work.

However, the original point was that switching from BIND to Unbound
or other options is silly, because you're just trading one codebase
for another, and they all have bugs.  However, collectively, two
different products cooperatively providing a service are likely to
have a higher uptime in a well-designed environment.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

From marka at isc.org  Tue Aug  4 16:39:18 2015
From: marka at isc.org (Mark Andrews)
Date: Wed, 05 Aug 2015 02:39:18 +1000
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: Your message of "Tue, 04 Aug 2015 12:00:32 -0400."
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
Message-ID: <20150804163918.338973422640@rock.dv.isc.org>


In message <9C2ACA5A-755D-4FCF-8491-745A1F9111BA at puck.nether.net>, Jared Mauch writes:
> I recommend using DNSDIST to balance traffic at a protocol level as you can h=
> ave implementation diversity on the backside.=20
> 
> I can send an example config out later for people. You can balance to bind N=
> SD and others all at the same time :-) just move your SPoF
> 
> Jared Mauch

Unless the same client hits the same server all the time this is a
bad idea.

Resolvers actually track capabilities of servers as it is the only
way to get answers due to firewalls dropping legitimate packet and
protocol misimplementations.  Add to that different vendors /
versions supporting different extensions randomly flipping between
vendors / versions is frought with danger unless you take extreme
care.

> > On Aug 4, 2015, at 10:03 AM, Jay Ashworth <jra at baylink.com> wrote:
> >
> > Everyone got BIND updated?
> >
> >
> http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-c
> ould-hamstring-huge-swaths-of-internet/
> > --
> > Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From damian at google.com  Tue Aug  4 16:49:21 2015
From: damian at google.com (Damian Menscher)
Date: Tue, 4 Aug 2015 09:49:21 -0700
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <20150804163918.338973422640@rock.dv.isc.org>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
 <20150804163918.338973422640@rock.dv.isc.org>
Message-ID: <CABSP1OdF45KEYeeYA1Gb8Vqz4ck6mN151UhLPpPQkA8C7uUARA@mail.gmail.com>

On Tue, Aug 4, 2015 at 9:39 AM, Mark Andrews <marka at isc.org> wrote:

> In message <9C2ACA5A-755D-4FCF-8491-745A1F9111BA at puck.nether.net>, Jared
> Mauch writes:
> > I recommend using DNSDIST to balance traffic at a protocol level as you
> can h=
> > ave implementation diversity on the backside.=20
> >
> > I can send an example config out later for people. You can balance to
> bind N=
> > SD and others all at the same time :-) just move your SPoF
>
> Unless the same client hits the same server all the time this is a
> bad idea.
>

But tying a set of clients to the same backend puts them all in the same
failure domain....

Resolvers actually track capabilities of servers as it is the only
> way to get answers due to firewalls dropping legitimate packet and
> protocol misimplementations.  Add to that different vendors /
> versions supporting different extensions randomly flipping between
> vendors / versions is frought with danger unless you take extreme
> care.


Out of curiosity, do any resolvers other than BIND do this?  I ask because
BIND has a reputation for having "too many" features, and I wonder if this
is one of them.

Damian

> > On Aug 4, 2015, at 10:03 AM, Jay Ashworth <jra at baylink.com> wrote:
> > >
> > > Everyone got BIND updated?
> > >
> > >
> >
> http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-c
> > ould-hamstring-huge-swaths-of-internet/
> > > --
> > > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>

From baldur.norddahl at gmail.com  Tue Aug  4 16:51:12 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Tue, 4 Aug 2015 18:51:12 +0200
Subject: RES: Exploits start against flaw that could hamstring huge swaths
In-Reply-To: <201508041648.t74GmAhP097198@aurora.sol.net>
References: <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <201508041648.t74GmAhP097198@aurora.sol.net>
Message-ID: <CAPkb-7A3cBw2LrNh=m0W+qV0RuUnx=77HEi+KhRYe4w4YUNxPA@mail.gmail.com>

On 4 August 2015 at 18:48, Joe Greco <jgreco at ns.sol.net> wrote:

> However, the original point was that switching from BIND to Unbound
> or other options is silly, because you're just trading one codebase
> for another, and they all have bugs.


It is equally silly to assume that all codebase are the same quality and
have equally many bugs. Maybe we should be looking at the track record of
those two products and maybe we should let someone do a code review. And
then choose based on that.

Regards,

Baldur

From jra at baylink.com  Tue Aug  4 16:58:53 2015
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 4 Aug 2015 12:58:53 -0400 (EDT)
Subject: RES: Exploits start against flaw that could hamstring huge
 swaths of
In-Reply-To: <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
Message-ID: <22289663.30.1438707533265.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Scott Helms" <khelms at zcorum.com>

> On Aug 4, 2015 9:38 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
> wrote:
> 
> > On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com>
> > wrote:
> > > With the (large) caveat that heterogenous networks are more
> > > subject to human error in many cases.
> >
> > <cough>automate!</cough>

> Automation just means your mistake goes many more places more quickly.

Not necessarily.

The sort of failure you're talking about, Scott, is "user did the wrong 
thing", and sure, automation makes it easier for that to spread.

Chris was, though, I think, suggesting automating around "user tries to do
the right thing on disjoint devices, and fails *because they're disjoint*";
that is, clearly, a problem automation can help with.

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 khelms at zcorum.com  Tue Aug  4 17:01:03 2015
From: khelms at zcorum.com (Scott Helms)
Date: Tue, 4 Aug 2015 13:01:03 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
Message-ID: <CAMrdfRw4vJdBjqph3ziZDGrPXe69=7_hyqZzHB1uUQ90M-v9sQ@mail.gmail.com>

I don't disagree, but automation usually protects against typing errors, it
doesn't protect against incorrect configurations.  Using multiple vendors
or server software means that your people have to know all of the systems.
There are many cases where, for example, a Cisco like CLI will make a
network engineer think that a command works exactly the same way on another
vendors system when in fact the under the hood implementation is very
different.

It's not always feasible to have the people with the needed skill levels
and automation does not help that at all.
On Aug 4, 2015 10:21 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
wrote:

> On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms <khelms at zcorum.com> wrote:
> > Automation just means your mistake goes many more places more quickly.
> >
>
> and letting people keep poking at things that computers should be
> doing is... much worse. people do not have reliability and
> repeat-ability over time.
>
>
> If you fear 'many more places' problems, improve your testing.
>
> > On Aug 4, 2015 9:38 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
> > wrote:
> >>
> >> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com> wrote:
> >> > With the (large) caveat that heterogenous networks are more subject to
> >> > human error in many cases.
> >>
> >> <cough>automate!</cough>
> >>
> >> > On Aug 4, 2015 9:25 AM, "Joe Greco" <jgreco at ns.sol.net> wrote:
> >> >
> >> >> > So, you guys recommend replace Bind for another option ?
> >> >>
> >> >> No.  Replacing one occasionally faulty product with another
> >> >> occasionally
> >> >> faulty product is foolish.  There's no particular reason to think
> that
> >> >> another product will be impervious to code bugs.  What I was
> suggesting
> >> >> was to use several different devices, much as some networks prefer to
> >> >> buy some Cisco gear and some Juniper gear and make them redundant, or
> >> >> as a well-built ZFS storage array consists of drives from different
> >> >> manufacturers.
> >> >>
> >> >> Heterogeneous environments tend to be more resilient because they are
> >> >> less likely to all suffer the same defect at once.  Problems still
> >> >> result
> >> >> in some pain and trouble, but it usually doesn't result in a service
> >> >> outage.
> >> >>
> >> >> This doesn't seem like a horribly catastrophic bug in any case.
> Anyone
> >> >> who is reliant on a critical bit like a DNS server probably has it
> set
> >> >> up to automatically restart if it doesn't exit cleanly.  If you
> don't,
> >> >> you should!
> >> >>
> >> >> So if it matters to you, I suggest that you instead use a combination
> >> >> of different products, and you'll be more resilient.  If you have two
> >> >> recursers for your customers, one can be BIND and one can be Unbound.
> >> >> And when some critical vuln comes along and knocks out Unbound,
> you'll
> >> >> still be resolving names.  Ditto BIND.  You're not likely to see both
> >> >> happen at the same time.
> >> >>
> >> >> However, at least here, we actually *use* TSIG updates, and other
> >> >> functionality that'd be hard to replace (BIND9 is pretty much THE
> only
> >> >> option for some functionality).
> >> >>
> >> >> ... JG
> >> >> --
> >> >> Joe Greco - sol.net Network Services - Milwaukee, WI -
> >> >> http://www.sol.net
> >> >> "We call it the 'one bite at the apple' rule. Give me one chance
> [and]
> >> >> then I
> >> >> won't contact you again." - Direct Marketing Ass'n position on e-mail
> >> >> spam(CNN)
> >> >> With 24 million small businesses in the US alone, that's way too many
> >> >> apples.
> >> >>
>

From carey at ar-ballbat.org  Tue Aug  4 17:01:47 2015
From: carey at ar-ballbat.org (Andrew Carey)
Date: Tue, 4 Aug 2015 10:01:47 -0700
Subject: [BULK] Verizon exiting California
Message-ID: <5285745E-EACD-41BC-BFCA-2C7B3CF2354A@ar-ballbat.org>


> On Aug 3, 2015, at 10:09, Matthew Black <Matthew.Black at csulb.edu> wrote:
> 
> I ran a few Google searches and came across a trove of complaints against Frontier. Seems they are far worse than GTE/Verizon. On the few occasions I have called for FIOS support, always reached someone knowledgeable and helpful. Not looking forward to the changeover, as the new owners have to pay off debts from their acquisition. That can only be accomplished through rate increases. I see a Verizon tech outside my kitchen window every two to three days as he replaces two nitrogen tanks keeping copper trunks pressurized against water intrusion.

Cutting expenses is another (well, and selling more too). Properly engineered/maintained cable should not require that level of constant attention. 

From rdobbins at arbor.net  Tue Aug  4 17:06:58 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 05 Aug 2015 00:06:58 +0700
Subject: Exploits start against flaw that could hamstring huge swaths of
In-Reply-To: <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
Message-ID: <6417F93A-8FEF-4D1C-93E8-F6AEC568C18C@arbor.net>

On 4 Aug 2015, at 23:21, Christopher Morrow wrote:

> and letting people keep poking at things that computers should be 
> doing is... much worse. people do not have reliability and 
> repeat-ability over time.

I've personally never come across an accidental route hijack (of the 
subset of which I learned the actual details of what happened) that 
wasn't the result of someone manually typing at the enable prompt.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From morrowc.lists at gmail.com  Tue Aug  4 17:18:11 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 4 Aug 2015 13:18:11 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
In-Reply-To: <CAPkb-7A3cBw2LrNh=m0W+qV0RuUnx=77HEi+KhRYe4w4YUNxPA@mail.gmail.com>
References: <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <201508041648.t74GmAhP097198@aurora.sol.net>
 <CAPkb-7A3cBw2LrNh=m0W+qV0RuUnx=77HEi+KhRYe4w4YUNxPA@mail.gmail.com>
Message-ID: <CAL9jLabFsaExto7QQ9CtuhPkwJjeAHjsYA3SHOBZ96Oo_M_6pg@mail.gmail.com>

On Tue, Aug 4, 2015 at 12:51 PM, Baldur Norddahl
<baldur.norddahl at gmail.com> wrote:
> On 4 August 2015 at 18:48, Joe Greco <jgreco at ns.sol.net> wrote:
>
>> However, the original point was that switching from BIND to Unbound
>> or other options is silly, because you're just trading one codebase
>> for another, and they all have bugs.
>
>
> It is equally silly to assume that all codebase are the same quality and
> have equally many bugs. Maybe we should be looking at the track record of
> those two products and maybe we should let someone do a code review. And
> then choose based on that.

because:
  1) historical results matter here? (who looked at which products
over what period of time, with what attention to detail(s) and which
sets of goals?)
  2) the single person doing a code review is likely to see all of the
problems in each of the products selected?


nothing against any of the software in question here, but really this
is all quite a crapshoot and past transgression research doesn't make
for a great tool to plan for the future.

Joe's right: "all software has bugs, find the software and strategy
that makes sense for your organization"  that MIGHT mean 2 platforms
(seems sensible to me!) and it might mean automation for management of
configs (from an abstraction so you can generate the right data to
each target implementation) or it might mean more monkeys on keyboards
if you don't believe in automation.

-chris

From nanogml at Mail.DDoS-Mitigator.net  Tue Aug  4 17:27:15 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Tue, 4 Aug 2015 10:27:15 -0700
Subject: RES: Exploits start against flaw that could hamstring huge
 swaths of
In-Reply-To: <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
Message-ID: <20150804172715.GA25471@Mail.DDoS-Mitigator.net>


hi ya

> >> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com> wrote:
> >> > With the (large) caveat that heterogenous networks are more subject to
> >> > human error in many cases.
> >>
> >> <cough>automate!</cough>
> >>
...

On 08/04/15 at 12:21pm, Christopher Morrow wrote:
> On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms <khelms at zcorum.com> wrote:
> > Automation just means your mistake goes many more places more quickly.
> >
> 
> and letting people keep poking at things that computers should be
> doing is... much worse. people do not have reliability and
> repeat-ability over time.

ditto ...
computers are experts at listening and repeatatively doing what it's 
told to do ..

> If you fear 'many more places' problems, improve your testing.

i prefer automation .. even if it's wrong, you can look at the script
and see what bad things it did and you should know what to do to fix
the problem and fix the script to prevent it from spreading that mistake 
again

<person's standard excuse>
if you ask a person(s), what did you do to create this mess, "duh... i donno"
btw, it's my kids birthday, i needed to be home an hr ago with the cake :-)

hummm... :-)
</standard>

-----

<fwiw>
for automation to work:
- folks updating the scripts should be required to know all platforms being 
  used and how its different from each other 

- folks testing the scripts/updates process/proceedures should be paid
  bonuses, even free pizza/beer for finding bugs before release to the 
  your internal world of automated-machines

- always have 3 co-developments boxes for the script develpment and
  to backup each other 

- always have 2 or more test bed boxes for initial releases of new scripts
  where those boxes can also be downgraded back to the previous release
  before the new patches was applied

- if nothing went wrong, there should be minimal issue with release a 
  patch where it doesn't propagate "problems automatically to everywhere"

  the trick is "how good are the eyes/brains" that is looking for 
  potential problems of the new releases/patches/updates/etc

- i also say always let clients pull down patches vs pushing it to
  systems that seems un-responsive to avoid having to wait for dead boxes

-----
all appps, not just bind, has occasional problems .. changing to something
else doesn't necessarily solve the original "bug" problem

pixie dust
alvin
# ddos-mitigator.net

From jabley at hopcount.ca  Tue Aug  4 17:48:56 2015
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 04 Aug 2015 13:48:56 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
Message-ID: <44B956AC-D03C-4638-B762-72CEF9595C32@hopcount.ca>

Hi Jared,

On 4 Aug 2015, at 12:00, Jared Mauch wrote:

> I recommend using DNSDIST to balance traffic at a protocol level as 
> you can have implementation diversity on the backside.
>
> I can send an example config out later for people. You can balance to 
> bind NSD and others all at the same time :-) just move your SPoF

As someone who once hosted TLD zones in a way that a query to a 
particular nameserver could be answered by either NSD or BIND9, my 
advice would be "don't do that". You're setting yourself up for 
troubleshooting hell.

You can include different nameservers in the set for a single zone. 
Using different software for different nameservers can be sensible. 
Using different software for the same nameserver can be a nightmare.


Joe

From jared at puck.Nether.net  Tue Aug  4 18:57:10 2015
From: jared at puck.Nether.net (Jared Mauch)
Date: Tue, 4 Aug 2015 14:57:10 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <20150804163918.338973422640@rock.dv.isc.org>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
 <20150804163918.338973422640@rock.dv.isc.org>
Message-ID: <20150804185710.GA25530@puck.nether.net>

On Wed, Aug 05, 2015 at 02:39:18AM +1000, Mark Andrews wrote:
> 
> In message <9C2ACA5A-755D-4FCF-8491-745A1F9111BA at puck.nether.net>, Jared Mauch writes:
> > I recommend using DNSDIST to balance traffic at a protocol level as you can h=
> > ave implementation diversity on the backside.=20
> > 
> > I can send an example config out later for people. You can balance to bind N=
> > SD and others all at the same time :-) just move your SPoF
> > 
> > Jared Mauch
> 
> Unless the same client hits the same server all the time this is a
> bad idea.

	Software that can't handle the remote side having a
upgrade/downgrade/capability change is broken.

> Resolvers actually track capabilities of servers as it is the only
> way to get answers due to firewalls dropping legitimate packet and
> protocol misimplementations.  Add to that different vendors /
> versions supporting different extensions randomly flipping between
> vendors / versions is frought with danger unless you take extreme
> care.

	I've come to use DNSDist to workaround the problems
that BIND has with outstanding queries which don't get a response.

	You might be surprised how poorly BIND performs if you
use something else to take a look at it from the exterior.

	http://puck.nether.net/~jared/dnsdist.png

	The first two are BIND the 3rd is not and the 4th is BIND.

	The last 3 get the same types of queries, notice how BIND
drops lots of queries.  I don't have time to report all the DNS related
issues on bind-users/dev but you may find it helpful to use a tool
like this to at least identify what is going on.

	The last 3 servers get only domains like arpa and a few well
known domains, eg: gmail.

	- Jared

> > > On Aug 4, 2015, at 10:03 AM, Jay Ashworth <jra at baylink.com> wrote:
> > >
> > > Everyone got BIND updated?
> > >
> > >
> > http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-c
> > ould-hamstring-huge-swaths-of-internet/
> > > --
> > > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

-- 
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  Tue Aug  4 19:03:47 2015
From: jared at puck.Nether.net (Jared Mauch)
Date: Tue, 4 Aug 2015 15:03:47 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <44B956AC-D03C-4638-B762-72CEF9595C32@hopcount.ca>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
 <44B956AC-D03C-4638-B762-72CEF9595C32@hopcount.ca>
Message-ID: <20150804190347.GB25530@puck.nether.net>

On Tue, Aug 04, 2015 at 01:48:56PM -0400, Joe Abley wrote:
> Hi Jared,
> 
> On 4 Aug 2015, at 12:00, Jared Mauch wrote:
> 
> >I recommend using DNSDIST to balance traffic at a protocol level as you
> >can have implementation diversity on the backside.
> >
> >I can send an example config out later for people. You can balance to bind
> >NSD and others all at the same time :-) just move your SPoF
> 
> As someone who once hosted TLD zones in a way that a query to a particular
> nameserver could be answered by either NSD or BIND9, my advice would be
> "don't do that". You're setting yourself up for troubleshooting hell.

	I'm not suggesting you have an unpredictable set of
things you route queries to.  I have a very simple config I'll share
with you off-list.  One should route things in a predictable manner.  This
is why people want operators who can code and operate a service vs just
operate it, or just code.  Those are the people in the highest demand
in my narrow experience.

> You can include different nameservers in the set for a single zone. Using
> different software for different nameservers can be sensible. Using
> different software for the same nameserver can be a nightmare.

	Proper logging and instrumentation is essential.  DNSDIST
can be configured to fail over to something else while one server
or daemon is offline and being serviced or restarted.  This can also
be done with other tools like "stupid routing tricks" aka anycast.

	For a resolver I want to "just work" for servers that need to
do e-mail etc this works well for me.  The fact I can have it point to a
BIND process on localhost on a different port, or nsd, etc.. provides
flexability that others don't do as easily.

	- Jared


-- 
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 bzs at world.std.com  Tue Aug  4 19:54:53 2015
From: bzs at world.std.com (Barry Shein)
Date: Tue, 4 Aug 2015 15:54:53 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
Message-ID: <21953.6285.849795.860519@world.std.com>


Wow this thread went off-track in nanoseconds.

So which bind versions are ok?

  -b

From Valdis.Kletnieks at vt.edu  Tue Aug  4 20:06:02 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 04 Aug 2015 16:06:02 -0400
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: Your message of "Tue, 04 Aug 2015 15:54:53 -0400."
 <21953.6285.849795.860519@world.std.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
 <21953.6285.849795.860519@world.std.com>
Message-ID: <30790.1438718762@turing-police.cc.vt.edu>

On Tue, 04 Aug 2015 15:54:53 -0400, Barry Shein said:
>
> Wow this thread went off-track in nanoseconds.
>
> So which bind versions are ok?

This week's.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150804/a5978524/attachment.pgp>

From Patrick.Darden at p66.com  Tue Aug  4 20:08:38 2015
From: Patrick.Darden at p66.com (Darden, Patrick)
Date: Tue, 4 Aug 2015 20:08:38 +0000
Subject: multipath tcp now in production use for linux based mobile devices
In-Reply-To: <D95C3C08-8F67-4F6B-BA8B-A5D32C7E463B@gt86car.org.uk>
References: <D95C3C08-8F67-4F6B-BA8B-A5D32C7E463B@gt86car.org.uk>
Message-ID: <fc77f4f6f21f4e5391d258d9caf0e611@BRTEXMB02.phillips66.net>

So, obviously, MPTCP can cause problems with Stateful Firewalls (as in asymmetric routing, out of state packets, etc.).  Cisco's take on how to deal with MPTCP is just as interesting as MPTCP itself is.

http://www.cisco.com/c/en/us/support/docs/ip/transmission-control-protocol-tcp/116519-technote-mptcp-00.html

Yep, for regular ASAs they advise you to let everything with option 30 set in the header have a free pass to your network (turn off  NOOP replacement of option 30 in TCP headers via a tcp-map)... and btw, turn off packet inspection.

For ASA-X "next generation" firewalls with modern code levels, this behavior seems to be default, although it looks like you can have your packet inspection as well.


--p

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colin Johnston
Sent: Saturday, August 01, 2015 1:45 AM
To: nanog at nanog.org list
Subject: [EXTERNAL]multipath tcp now in production use for linux based mobile devices

http://blog.multipath-tcp.org/blog/html/2015/07/24/korea.html

From jabley at hopcount.ca  Tue Aug  4 20:23:40 2015
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 04 Aug 2015 16:23:40 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
In-Reply-To: <21953.6285.849795.860519@world.std.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
 <21953.6285.849795.860519@world.std.com>
Message-ID: <F8D87584-C6EF-47E9-A4F9-4F2D9B7C77E2@hopcount.ca>

On 4 Aug 2015, at 15:54, Barry Shein wrote:

> Wow this thread went off-track in nanoseconds.
>
> So which bind versions are ok?

9.10.2-P3 is marked "current stable", and 9.9.7-P2 is marked 
"current-stable ESV" at:

   https://www.isc.org/downloads/

The bind-users is probably a place where this kind of thread would at 
least go off-track in a different set of ways:

   https://lists.isc.org/mailman/listinfo/bind-users


Joe

From geoffk at geoffk.org  Tue Aug  4 21:16:26 2015
From: geoffk at geoffk.org (Geoffrey Keating)
Date: 04 Aug 2015 14:16:26 -0700
Subject: multipath tcp now in production use for linux based mobile devices
In-Reply-To: <fc77f4f6f21f4e5391d258d9caf0e611@BRTEXMB02.phillips66.net>
References: <D95C3C08-8F67-4F6B-BA8B-A5D32C7E463B@gt86car.org.uk>
 <fc77f4f6f21f4e5391d258d9caf0e611@BRTEXMB02.phillips66.net>
Message-ID: <m2lhdqah5h.fsf@localhost.localdomain>

"Darden, Patrick" <Patrick.Darden at p66.com> writes:

> So, obviously, MPTCP can cause problems with Stateful Firewalls (as
> in asymmetric routing, out of state packets, etc.).  Cisco's take on
> how to deal with MPTCP is just as interesting as MPTCP itself is.
...

It's not so much the statefulness of the firewall that's the problem,
it's that if the firewall wants to work at higher layers than TCP, in
particular at the TLS layer, it can't because it doesn't have all the
data.

Operators should probably consider that if they block or disable
MPTCP, the device using it might decide that network is broken or not
currently available to it for that service, and prefer its other
interface bypassing the firewall entirely.

From baldur.norddahl at gmail.com  Tue Aug  4 21:21:00 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Tue, 4 Aug 2015 23:21:00 +0200
Subject: RES: Exploits start against flaw that could hamstring huge swaths
In-Reply-To: <CAL9jLabFsaExto7QQ9CtuhPkwJjeAHjsYA3SHOBZ96Oo_M_6pg@mail.gmail.com>
References: <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <201508041648.t74GmAhP097198@aurora.sol.net>
 <CAPkb-7A3cBw2LrNh=m0W+qV0RuUnx=77HEi+KhRYe4w4YUNxPA@mail.gmail.com>
 <CAL9jLabFsaExto7QQ9CtuhPkwJjeAHjsYA3SHOBZ96Oo_M_6pg@mail.gmail.com>
Message-ID: <CAPkb-7CwGhgbrVG-kqOh8h3GPB0yQCukfWhAjaVKeJbkPdfLtQ@mail.gmail.com>

Den 04/08/2015 19.18 skrev "Christopher Morrow" <morrowc.lists at gmail.com>:
>
> On Tue, Aug 4, 2015 at 12:51 PM, Baldur Norddahl
> <baldur.norddahl at gmail.com> wrote:
> > On 4 August 2015 at 18:48, Joe Greco <jgreco at ns.sol.net> wrote:
> >
> >> However, the original point was that switching from BIND to Unbound
> >> or other options is silly, because you're just trading one codebase
> >> for another, and they all have bugs.
> >
> >
> > It is equally silly to assume that all codebase are the same quality and
> > have equally many bugs. Maybe we should be looking at the track record
of
> > those two products and maybe we should let someone do a code review. And
> > then choose based on that.
>
> because:
>   1) historical results matter here? (who looked at which products
> over what period of time, with what attention to detail(s) and which
> sets of goals?)
>   2) the single person doing a code review is likely to see all of the
> problems in each of the products selected?
>

Maybe not but a code review can tell what methods are used to safe guard
against security bugs, the general quality of the code, the level of
automated testing etc. History can give hints to the same. If it had a lot
of bugs discovered it is likely it is not good quality in a security
perspective and more bugs can be expected.

It is called due diligence. The aim is not to find the bugs but to evaluate
the product.

Regards

Baldur

From eric.rosenberry at iovation.com  Tue Aug  4 21:49:17 2015
From: eric.rosenberry at iovation.com (Eric Rosenberry)
Date: Tue, 4 Aug 2015 14:49:17 -0700
Subject: Mac compatible SFP+/XFP programmer
In-Reply-To: <208B1F28-0A94-4059-9DFE-42176F2812DD@netideainc.ca>
References: <D479383B-E903-48B3-9AAE-69CE5F6045BF@lixfeld.ca>
 <AA251339-0E42-4503-9D52-8676138BA098@720.fr>
 <208B1F28-0A94-4059-9DFE-42176F2812DD@netideainc.ca>
Message-ID: <CADfGf65b5TNGxwyDgPXGOj4fPJBMZUbARvjm+kUxZUNuzd0Zdg@mail.gmail.com>

I can attest to the quality of the Flexbox.  It is fantastic!  All of our
employees have Mac's and they work great.

Originally you had to use Java in FireFox to make it work, but they now
have a "Chrome app" that works in Chrome which is even easier (don't have
to get the right Java version loaded and click through a million security
warnings).

The workflow for how the box works is fantastic- You just go to their
website and plug in the box and the UI is fully web based.  The benefit
here is that they are constantly updating different programming profiles
for different manufacturer quirks.  As soon as they make a change, it is
available to you from the UI.  If you run into any issues with optic
compatibility, they can whip up a new profile and have it available
immediately (not that I have actually had any issues, but I did have them
add some XFP MRV profiles for me).  It will also show you the history of
any optic you have programmed which is nice I guess.

The down side is naturally that I think it only works with their branded
optics and also they are in control (i.e. if they decide to discontinue the
service, or if you have no net access you are out of luck, but come on, we
are all network engineers - finding Internet is not exactly hard).  ;-)

-Eric

On Fri, Jul 31, 2015 at 8:57 AM, Eriks Rugelis <eriks at netideainc.ca> wrote:

> A couple of months ago I purchased a Flexbox V3 and a pile of SFP and SFP+
> for $dayjob.   The parts arrived in less than a week and the Flexbox V3
> (and webapp) works well with our Macs.
>
> We are a satisfied customer.
>
> Eriks
> ---
> Eriks Rugelis
> Sr. Consultant
> Netidea Inc.
> T: +1.416.876.0740
>
> > On Jul 30, 2015, at 14:48, Youssef Bengelloun-Zahr <youssef at 720.fr>
> wrote:
> >
> > Hi,
> >
> > Flexoptics seems to do the trick but via a Web browser :
> >
> > https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html
> >
> > From what I've heard, this thing does the Job.
> >
> > Best regards.
> >
> >
> >
> >> Le 30 juil. 2015 ? 20:28, Jason Lixfeld <jason at lixfeld.ca> a ?crit :
> >>
> >> Does anyone know where I might find a SFP+/XFP programmer with a Mac
> compatible programmer application?
> >>
> >> Thanks!
> >
>



-- 
*Eric Rosenberry*
Principal Infrastructure Architect // Chief Bit Plumber

From bob at FiberInternetCenter.com  Tue Aug  4 21:54:30 2015
From: bob at FiberInternetCenter.com (Bob Evans)
Date: Tue, 4 Aug 2015 14:54:30 -0700
Subject: DropBox peering issue in SF bay area  ? Rare and Odd
Message-ID: <a313d82d3218c500725d57f527545ae2.squirrel@66.201.44.180>

Anyone from dropbox please contact
noc at fiberInternetCenter.com

Multiple peering session - peering sessions are up/established - prefixes
are received - but no website and customers complaining to us.

Thank You
Bob Evans
CTO







From Matthew.Black at csulb.edu  Tue Aug  4 21:57:09 2015
From: Matthew.Black at csulb.edu (Matthew Black)
Date: Tue, 4 Aug 2015 21:57:09 +0000
Subject: [BULK] Verizon exiting California
In-Reply-To: <5285745E-EACD-41BC-BFCA-2C7B3CF2354A@ar-ballbat.org>
References: <5285745E-EACD-41BC-BFCA-2C7B3CF2354A@ar-ballbat.org>
Message-ID: <ED78B1C68B84A14FA706D13A230D7B437820264E@ITS-MAIL02.campus.ad.csulb.edu>

I don't live in a new suburban community with modern utilities. Well, the 50 year-old water main on my street was replaced about 10 years ago. We haven't suffered major flooding like UCLA experienced last year. My house was built in 1930. Much of that telco copper is pushing 70 years old or more. Some is above ground and some is underground. Until recently, the underground vault would flood whenever it rained. The b-box uses screw-type terminals, not even 66 or BIX. Thank you GTE.

matthew black
california state university, long beach


-----Original Message-----
From: Andrew Carey [mailto:carey at ar-ballbat.org] 
Sent: Tuesday, August 04, 2015 10:02 AM
To: Matthew Black
Cc: nanog at nanog.org
Subject: Re: [BULK] Verizon exiting California


> On Aug 3, 2015, at 10:09, Matthew Black <Matthew.Black at csulb.edu> wrote:
> 
> I ran a few Google searches and came across a trove of complaints against Frontier. Seems they are far worse than GTE/Verizon. On the few occasions I have called for FIOS support, always reached someone knowledgeable and helpful. Not looking forward to the changeover, as the new owners have to pay off debts from their acquisition. That can only be accomplished through rate increases. I see a Verizon tech outside my kitchen window every two to three days as he replaces two nitrogen tanks keeping copper trunks pressurized against water intrusion.

Cutting expenses is another (well, and selling more too). Properly engineered/maintained cable should not require that level of constant attention. 

From jj at anexia.at  Tue Aug  4 22:01:41 2015
From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=)
Date: Tue, 4 Aug 2015 22:01:41 +0000
Subject: AW: Mac compatible SFP+/XFP programmer
In-Reply-To: <CADfGf65b5TNGxwyDgPXGOj4fPJBMZUbARvjm+kUxZUNuzd0Zdg@mail.gmail.com>
References: <D479383B-E903-48B3-9AAE-69CE5F6045BF@lixfeld.ca>
 <AA251339-0E42-4503-9D52-8676138BA098@720.fr>
 <208B1F28-0A94-4059-9DFE-42176F2812DD@netideainc.ca>
 <CADfGf65b5TNGxwyDgPXGOj4fPJBMZUbARvjm+kUxZUNuzd0Zdg@mail.gmail.com>
Message-ID: <e4945460f0ac49e985c4560820159348@anx-i-dag02.anx.local>

I can also suggest you the Multi-Fiber-Tool from Solid Optics:

http://www.solid-optics.com/tools/multi-fiber-tool/so-multi-fiber-tool-id1768.html

Works great but I've never tested it with an Mac ... MacOS is at least listed as supported.


Best regards

J?rgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj at anexia.at 
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
Gesch?ftsf?hrer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-----Urspr?ngliche Nachricht-----
Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Eric Rosenberry
Gesendet: Dienstag, 04. August 2015 23:49
An: Eriks Rugelis <eriks at netideainc.ca>
Cc: NANOG <nanog at nanog.org>
Betreff: Re: Mac compatible SFP+/XFP programmer

I can attest to the quality of the Flexbox.  It is fantastic!  All of our
employees have Mac's and they work great.

Originally you had to use Java in FireFox to make it work, but they now
have a "Chrome app" that works in Chrome which is even easier (don't have
to get the right Java version loaded and click through a million security
warnings).

The workflow for how the box works is fantastic- You just go to their
website and plug in the box and the UI is fully web based.  The benefit
here is that they are constantly updating different programming profiles
for different manufacturer quirks.  As soon as they make a change, it is
available to you from the UI.  If you run into any issues with optic
compatibility, they can whip up a new profile and have it available
immediately (not that I have actually had any issues, but I did have them
add some XFP MRV profiles for me).  It will also show you the history of
any optic you have programmed which is nice I guess.

The down side is naturally that I think it only works with their branded
optics and also they are in control (i.e. if they decide to discontinue the
service, or if you have no net access you are out of luck, but come on, we
are all network engineers - finding Internet is not exactly hard).  ;-)

-Eric

On Fri, Jul 31, 2015 at 8:57 AM, Eriks Rugelis <eriks at netideainc.ca> wrote:

> A couple of months ago I purchased a Flexbox V3 and a pile of SFP and SFP+
> for $dayjob.   The parts arrived in less than a week and the Flexbox V3
> (and webapp) works well with our Macs.
>
> We are a satisfied customer.
>
> Eriks
> ---
> Eriks Rugelis
> Sr. Consultant
> Netidea Inc.
> T: +1.416.876.0740
>
> > On Jul 30, 2015, at 14:48, Youssef Bengelloun-Zahr <youssef at 720.fr>
> wrote:
> >
> > Hi,
> >
> > Flexoptics seems to do the trick but via a Web browser :
> >
> > https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html
> >
> > From what I've heard, this thing does the Job.
> >
> > Best regards.
> >
> >
> >
> >> Le 30 juil. 2015 ? 20:28, Jason Lixfeld <jason at lixfeld.ca> a ?crit :
> >>
> >> Does anyone know where I might find a SFP+/XFP programmer with a Mac
> compatible programmer application?
> >>
> >> Thanks!
> >
>



-- 
*Eric Rosenberry*
Principal Infrastructure Architect // Chief Bit Plumber

From randy at psg.com  Tue Aug  4 22:50:15 2015
From: randy at psg.com (Randy Bush)
Date: Wed, 05 Aug 2015 07:50:15 +0900
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <44B956AC-D03C-4638-B762-72CEF9595C32@hopcount.ca>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
 <44B956AC-D03C-4638-B762-72CEF9595C32@hopcount.ca>
Message-ID: <m2d1z2zn14.wl%randy@psg.com>

> As someone who once hosted TLD zones in a way that a query to a 
> particular nameserver could be answered by either NSD or BIND9, my 
> advice would be "don't do that". You're setting yourself up for 
> troubleshooting hell.

for some folk, complexity is a career.  i worked for circuitzilla
for 15 months; it's embedded in their culture.

randy

From randy at psg.com  Tue Aug  4 22:53:17 2015
From: randy at psg.com (Randy Bush)
Date: Wed, 05 Aug 2015 07:53:17 +0900
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
Message-ID: <m2bnemzmw2.wl%randy@psg.com>

>> Automation just means your mistake goes many more places more
>> quickly.
> and letting people keep poking at things that computers should be
> doing is... much worse. people do not have reliability and
> repeat-ability over time.

i love the devops movement; operators discover that those computers can
be programmed.  wowzers!

maybe in a decade or two, we will discover mathematics.  nah.

randy

From jmaslak at antelope.net  Tue Aug  4 22:57:09 2015
From: jmaslak at antelope.net (Joel Maslak)
Date: Tue, 4 Aug 2015 16:57:09 -0600
Subject: RES: Exploits start against flaw that could hamstring huge swaths
 of
In-Reply-To: <m2bnemzmw2.wl%randy@psg.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
 <m2bnemzmw2.wl%randy@psg.com>
Message-ID: <CADb+6TCiFn3e5QKGp6ihksvazsmYXEg7QGgpeCAapSH7ubdKWA@mail.gmail.com>

On Tue, Aug 4, 2015 at 4:53 PM, Randy Bush <randy at psg.com> wrote:

> i love the devops movement; operators discover that those computers can
> be programmed.  wowzers!
>

Maybe we can give them a new title.  I'm thinking, "System Programmer."

From jared at puck.Nether.net  Tue Aug  4 23:34:51 2015
From: jared at puck.Nether.net (Jared Mauch)
Date: Tue, 4 Aug 2015 19:34:51 -0400
Subject: Exploits start against flaw that could hamstring huge swaths of
 Internet | Ars Technica
In-Reply-To: <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
References: <81AB64A1-8693-4054-ABF9-B65344D7AE7B@baylink.com>
 <9C2ACA5A-755D-4FCF-8491-745A1F9111BA@puck.nether.net>
Message-ID: <20150804233451.GA11415@puck.nether.net>

On Tue, Aug 04, 2015 at 12:00:32PM -0400, Jared Mauch wrote:
> I recommend using DNSDIST to balance traffic at a protocol level as you can have implementation diversity on the backside.
> 

Here's an example dnsdist config you might find helpful:

	This sends queries to the first two servers unless
they are for domains in the "nether" pool list.  They go to
other servers.

	You can restrict access based on the Acl.

newServer("x.x.223.10")
newServer("x.x.223.20")
;setServerPolicy(firstAvailable) -- first server within its QPS limit
setServerPolicy(leastOutstanding)
webserver("0.0.0.0:8083", "AskMe")
addACL("192.168.0.0/22")
addACL("10.0.0.0/16")
addACL("172.16.22.0/24")
setKey("AskMe")
controlSocket("127.0.0.1:1099")
newServer{address="129.250.35.250", pool="nether"}
newServer{address="129.250.35.251", pool="nether"}
newServer{address="8.8.8.8", pool="nether"}
addPoolRule({"ntt.net.", "nether.net."}, "nether")
addPoolRule({"arpa.", "google.", "gmail.com.", "google.com.", "googlemail.com."}, "nether")


-- 
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 florian.hibler at kaiaglobal.com  Wed Aug  5 08:21:45 2015
From: florian.hibler at kaiaglobal.com (Hibler, Florian)
Date: Wed, 5 Aug 2015 09:21:45 +0100
Subject: Mac compatible SFP+/XFP programmer
In-Reply-To: <e4945460f0ac49e985c4560820159348@anx-i-dag02.anx.local>
References: <D479383B-E903-48B3-9AAE-69CE5F6045BF@lixfeld.ca>
 <AA251339-0E42-4503-9D52-8676138BA098@720.fr>
 <208B1F28-0A94-4059-9DFE-42176F2812DD@netideainc.ca>
 <CADfGf65b5TNGxwyDgPXGOj4fPJBMZUbARvjm+kUxZUNuzd0Zdg@mail.gmail.com>
 <e4945460f0ac49e985c4560820159348@anx-i-dag02.anx.local>
Message-ID: <CAFMTo=sGHKO4W7NTxtxnkYexP3n+qqj1abppQNxhz=jAonTjfQ@mail.gmail.com>

+1 on the Flexoptix Flexbox.
https://www.flexoptix.net/en/produkte/transceiver-accessories/flexbox-v3-transceiver-programmer.html

Best regards,
Florian

-- 
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.

On Tue, Aug 4, 2015 at 11:01 PM, J?rgen Jaritsch <jj at anexia.at> wrote:

> I can also suggest you the Multi-Fiber-Tool from Solid Optics:
>
>
> http://www.solid-optics.com/tools/multi-fiber-tool/so-multi-fiber-tool-id1768.html
>
> Works great but I've never tested it with an Mac ... MacOS is at least
> listed as supported.
>
>
> Best regards
>
> J?rgen Jaritsch
> Head of Network & Infrastructure
>
> ANEXIA Internetdienstleistungs GmbH
>
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
>
> E-Mail: jj at anexia.at
> Web: http://www.anexia.at
>
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
> Gesch?ftsf?hrer: Alexander Windbichler
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT
> U63216601
>
> -----Urspr?ngliche Nachricht-----
> Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Eric Rosenberry
> Gesendet: Dienstag, 04. August 2015 23:49
> An: Eriks Rugelis <eriks at netideainc.ca>
> Cc: NANOG <nanog at nanog.org>
> Betreff: Re: Mac compatible SFP+/XFP programmer
>
> I can attest to the quality of the Flexbox.  It is fantastic!  All of our
> employees have Mac's and they work great.
>
> Originally you had to use Java in FireFox to make it work, but they now
> have a "Chrome app" that works in Chrome which is even easier (don't have
> to get the right Java version loaded and click through a million security
> warnings).
>
> The workflow for how the box works is fantastic- You just go to their
> website and plug in the box and the UI is fully web based.  The benefit
> here is that they are constantly updating different programming profiles
> for different manufacturer quirks.  As soon as they make a change, it is
> available to you from the UI.  If you run into any issues with optic
> compatibility, they can whip up a new profile and have it available
> immediately (not that I have actually had any issues, but I did have them
> add some XFP MRV profiles for me).  It will also show you the history of
> any optic you have programmed which is nice I guess.
>
> The down side is naturally that I think it only works with their branded
> optics and also they are in control (i.e. if they decide to discontinue the
> service, or if you have no net access you are out of luck, but come on, we
> are all network engineers - finding Internet is not exactly hard).  ;-)
>
> -Eric
>
> On Fri, Jul 31, 2015 at 8:57 AM, Eriks Rugelis <eriks at netideainc.ca>
> wrote:
>
> > A couple of months ago I purchased a Flexbox V3 and a pile of SFP and
> SFP+
> > for $dayjob.   The parts arrived in less than a week and the Flexbox V3
> > (and webapp) works well with our Macs.
> >
> > We are a satisfied customer.
> >
> > Eriks
> > ---
> > Eriks Rugelis
> > Sr. Consultant
> > Netidea Inc.
> > T: +1.416.876.0740
> >
> > > On Jul 30, 2015, at 14:48, Youssef Bengelloun-Zahr <youssef at 720.fr>
> > wrote:
> > >
> > > Hi,
> > >
> > > Flexoptics seems to do the trick but via a Web browser :
> > >
> > > https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html
> > >
> > > From what I've heard, this thing does the Job.
> > >
> > > Best regards.
> > >
> > >
> > >
> > >> Le 30 juil. 2015 ? 20:28, Jason Lixfeld <jason at lixfeld.ca> a ?crit :
> > >>
> > >> Does anyone know where I might find a SFP+/XFP programmer with a Mac
> > compatible programmer application?
> > >>
> > >> Thanks!
> > >
> >
>
>
>
> --
> *Eric Rosenberry*
> Principal Infrastructure Architect // Chief Bit Plumber
>

From rdrake at direcpath.com  Wed Aug  5 14:45:26 2015
From: rdrake at direcpath.com (Robert Drake)
Date: Wed, 5 Aug 2015 10:45:26 -0400
Subject: Bright House IMAP highwater warning real?
In-Reply-To: <548CC203-E345-45CF-9C3C-37A0786E94A8@baylink.com>
References: <4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>
 <BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>
 <000601d0cd5b$aa7f1e80$ff7d5b80$@iname.com>
 <548CC203-E345-45CF-9C3C-37A0786E94A8@baylink.com>
Message-ID: <55C22186.6020900@direcpath.com>



On 8/2/2015 3:53 PM, Jay Ashworth wrote:
> I think the body text of the message should identify it as coming from the Bright House email system? I think it should be written in standard USAdian English, which that is decidedly not.
>
> Or perhaps the problem is that that subject line was supposed to be parameterized, and the number of bytes is missing for some reason. But in any event that is a common message to spoof, and the more bits of identity that are in it the harder it is to do so. That message format has almost zero bit of provider-identifiable data.
That's not even mentioning that the term "High Water" and even "bytes" 
is just confusing to end users who probably don't know computer 
terminology.  At best, they can expect calls to support over these emails.

OTOH, 99% of their users probably have an inbox full of spam and don't 
use their ISP provided mailbox, having switched to a third-party email 
provider years ago.  So the "Please" in the message might be 
desperation.  Please come back and read me, then delete this message and 
the 5,000 other spam messages. :)

High Water Mark Notification, bytes in the mailbox!

A new action thriller series coming to you this fall on TV.  Please, 
please turn on the TV and don't watch it on Netflix..


From vwittkop at nanog.org  Wed Aug  5 14:50:30 2015
From: vwittkop at nanog.org (Valerie Wittkop)
Date: Wed, 5 Aug 2015 10:50:30 -0400
Subject: [NANOG-announce] UPDATE - 2015 NANOG Elections General Information
Message-ID: <D0CA5C69-D171-4290-9EFF-02EE87C4F9AA@nanog.org>

Hello NANOG Members,

It has come to my attention there was a bad link in the message sent last week announcing the opening of the 2015 Election Process.  I apologize for not catching the error before the message was sent and causing more noise to your inbox now.  Please note the corrected link (relating to completing the Online Process) below.

Why?

If you care about NANOG and think that you would like to take a turn at volunteering your time to help make it better please consider joining as a member and running for a position. If you know someone else that you believe would be interested, nominate them by completing the Online Process <https://www.bigpulse.com/112537/register>.  Any questions should be submitted to elections at nanog.org. <mailto:elections at nanog.org>

Cheers,

Valerie

Valerie Wittkop
NANOG Program Director
Tel: +1 866 902 1336, ext 103

-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

From sathish.kumar.ippani at gmail.com  Thu Aug  6 02:23:40 2015
From: sathish.kumar.ippani at gmail.com (sathish kumar Ippani)
Date: Wed, 5 Aug 2015 21:23:40 -0500
Subject: free Tools to monitor website performance
Message-ID: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>

Hi All,

Thanks to all for reviewing my topic, may it is slightly off topic.

We have almost 300 URL's (local and web) and we want to monitor few of them
which are very critical URL's for web access and local access.

I would like to know is there any free tool or software with I can use to
monitor url performance in terms of response time. Which gives more
information like how much time it taken to connect the server and time to
load the page and total response time.

Thanks in advance.



-- 
With Regards,

Sathish Ippani

From ops.lists at gmail.com  Thu Aug  6 02:27:31 2015
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 5 Aug 2015 19:27:31 -0700
Subject: free Tools to monitor website performance
In-Reply-To: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
Message-ID: <711EE106-1B8D-4F0F-9FBB-6C3682CE563C@gmail.com>

Nagios will do it at a pinch but only from one location.  But if you want professional URL monitoring from across multiple locations worldwide, you need Gomez, Neustar Webmetrics etc.  Not quite cheap.

> On 05-Aug-2015, at 7:23 PM, sathish kumar Ippani <sathish.kumar.ippani at gmail.com> wrote:
> 
> Hi All,
> 
> Thanks to all for reviewing my topic, may it is slightly off topic.
> 
> We have almost 300 URL's (local and web) and we want to monitor few of them
> which are very critical URL's for web access and local access.
> 
> I would like to know is there any free tool or software with I can use to
> monitor url performance in terms of response time. Which gives more
> information like how much time it taken to connect the server and time to
> load the page and total response time.
> 
> Thanks in advance.
> 
> 
> 
> -- 
> With Regards,
> 
> Sathish Ippani


From virtualsid at gmail.com  Thu Aug  6 02:34:05 2015
From: virtualsid at gmail.com (Siraj 'Sid' Rakhada)
Date: Thu, 06 Aug 2015 10:34:05 +0800
Subject: free Tools to monitor website performance
In-Reply-To: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
Message-ID: <045113E2-A357-4DB7-94F7-5E297040F92A@gmail.com>

Hi,

On 6 Aug 2015, at 10:23, sathish kumar Ippani wrote:

> I would like to know is there any free tool or software with I can use 
> to
> monitor url performance in terms of response time. Which gives more
> information like how much time it taken to connect the server and time 
> to
> load the page and total response time.

You can use smokeping with HTTP probes for some basic checks on this 
front. It can do distributed polling too, which is extra handy to ensure 
you don't have a localised problem from your monitoring host.

I'm sure you can do more fancy url checks with smokeping, but I've not 
delved too deep into it.

Thanks,

Sid

From plucena at coopergeneral.com  Thu Aug  6 02:38:30 2015
From: plucena at coopergeneral.com (Pablo Lucena)
Date: Wed, 5 Aug 2015 22:38:30 -0400
Subject: free Tools to monitor website performance
In-Reply-To: <711EE106-1B8D-4F0F-9FBB-6C3682CE563C@gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
 <711EE106-1B8D-4F0F-9FBB-6C3682CE563C@gmail.com>
Message-ID: <CAH+2GVKZ=jkp+TCwoNqsWUdqHDazvFv+BZMBVsa75aD2q4FmpQ@mail.gmail.com>

I've also heard good things about ThousandEyes.

On Wed, Aug 5, 2015 at 10:27 PM, Suresh Ramasubramanian <ops.lists at gmail.com
> wrote:

> Nagios will do it at a pinch but only from one location.  But if you want
> professional URL monitoring from across multiple locations worldwide, you
> need Gomez, Neustar Webmetrics etc.  Not quite cheap.
>
> > On 05-Aug-2015, at 7:23 PM, sathish kumar Ippani <
> sathish.kumar.ippani at gmail.com> wrote:
> >
> > Hi All,
> >
> > Thanks to all for reviewing my topic, may it is slightly off topic.
> >
> > We have almost 300 URL's (local and web) and we want to monitor few of
> them
> > which are very critical URL's for web access and local access.
> >
> > I would like to know is there any free tool or software with I can use to
> > monitor url performance in terms of response time. Which gives more
> > information like how much time it taken to connect the server and time to
> > load the page and total response time.
> >
> > Thanks in advance.
> >
> >
> >
> > --
> > With Regards,
> >
> > Sathish Ippani
>
>

From olushile at gmail.com  Thu Aug  6 03:05:12 2015
From: olushile at gmail.com (olushile akintade)
Date: Thu, 06 Aug 2015 03:05:12 +0000
Subject: free Tools to monitor website performance
In-Reply-To: <CAH+2GVKZ=jkp+TCwoNqsWUdqHDazvFv+BZMBVsa75aD2q4FmpQ@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
 <711EE106-1B8D-4F0F-9FBB-6C3682CE563C@gmail.com>
 <CAH+2GVKZ=jkp+TCwoNqsWUdqHDazvFv+BZMBVsa75aD2q4FmpQ@mail.gmail.com>
Message-ID: <CABqQ-OstfsK_eOQku0e_VT3v0uHKUm6cUg0edNAa3+PxwJhTaQ@mail.gmail.com>

I have used thousandEyes before and it's pretty good. I've also used
catchpoint and that is a lot better but not cheap.
On Wed, Aug 5, 2015 at 7:40 PM Pablo Lucena <plucena at coopergeneral.com>
wrote:

> I've also heard good things about ThousandEyes.
>
> On Wed, Aug 5, 2015 at 10:27 PM, Suresh Ramasubramanian <
> ops.lists at gmail.com
> > wrote:
>
> > Nagios will do it at a pinch but only from one location.  But if you want
> > professional URL monitoring from across multiple locations worldwide, you
> > need Gomez, Neustar Webmetrics etc.  Not quite cheap.
> >
> > > On 05-Aug-2015, at 7:23 PM, sathish kumar Ippani <
> > sathish.kumar.ippani at gmail.com> wrote:
> > >
> > > Hi All,
> > >
> > > Thanks to all for reviewing my topic, may it is slightly off topic.
> > >
> > > We have almost 300 URL's (local and web) and we want to monitor few of
> > them
> > > which are very critical URL's for web access and local access.
> > >
> > > I would like to know is there any free tool or software with I can use
> to
> > > monitor url performance in terms of response time. Which gives more
> > > information like how much time it taken to connect the server and time
> to
> > > load the page and total response time.
> > >
> > > Thanks in advance.
> > >
> > >
> > >
> > > --
> > > With Regards,
> > >
> > > Sathish Ippani
> >
> >
>

From james.braunegg at micron21.com  Thu Aug  6 03:34:51 2015
From: james.braunegg at micron21.com (James Braunegg)
Date: Thu, 6 Aug 2015 03:34:51 +0000
Subject: Management Network / Backup Network @ One Wilshire LA 
Message-ID: <aeebfabc5dc84126b32f9db20684094d@EX-01.m21.local>

Dear Nanog

I am looking for a cost effective 100mbit commit burst to 1gbit service with a /28 to be used as a management backup network within LA @ Core Site 624 Grand / One Wilshire

Also looking for the same service in Evo Switch Amsterdam and Equinix SG1 Singapore if anyone can provide this.

Happy to also trade for the same service (IE we provide you with a backup management Network in return for your service), please contact me if you can provide such a service cost

Kindest Regards

James Braunegg
P:  1300 769 972  |  M:  0488 997 207 |  D:  (03) 9751 7616
E:   james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>  |  ABN:  12 109 977 666
W:  www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection>   T: @micron21

Follow us on Twitter<http://www.twitter.com/micron21> for important service and system updates.

[M21.jpg]

This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.


From penxiao at cisco.com  Tue Aug  4 06:29:42 2015
From: penxiao at cisco.com (Peng Xiao (penxiao))
Date: Tue, 4 Aug 2015 06:29:42 +0000
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
Message-ID: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>

Hi experts

Cisco has open sourced one part of their BGP monitoring system - YABGP
And hosted source code on GitHub. https://github.com/smartbgp/yabgp
Documentation: http://yabgp.readthedocs.org/en/latest/


From mmorris at cavalluzzo.com  Tue Aug  4 17:21:09 2015
From: mmorris at cavalluzzo.com (Michael Morris)
Date: Tue, 04 Aug 2015 13:21:09 -0400
Subject: Someone from Bell Canada (Bell.net / Sympatico.ca) Offlist
 Request
Message-ID: <55C0BC45020000F90007C319@chsmcmail.chsmc.com>

Can someone from Bell (Bell.net / Sympatico.ca) contact me offlist.

We have many, several hundred clients on either of those services and
since the first week of July we have not been able to send email through
the primary MX (mxmta.owm.bell.net).  The secondary MX was accepting and
now is not, I have been told by the tech that this was by design and all
is now funnelling through the one point.

I have a ticket opened on two of our customer accounts and that ticket
information available, and the tech informs me that the issue has been
replicated, acknowledged and with the vendor for patching which was
supposed to be last week but that was delayed.

Just looking for an update as we are not a customer, but we do need to
communicate with our clients.

Thanks in advance,
Michael Morris
mmorris at cavalluzzo.com


From edwin.mallette at gmail.com  Wed Aug  5 15:04:37 2015
From: edwin.mallette at gmail.com (Edwin Mallette)
Date: Wed, 05 Aug 2015 09:04:37 -0600
Subject: Bright House IMAP highwater warning real?
In-Reply-To: <D1E7801F.85EDB%edwin.mallette@mybrighthouse.com>
References: <4678f236-8c90-4187-a49b-a6f2ec1994bc.maildroid@localhost>
 <BC6D8D5D-9F7C-4336-BFCE-FB520508873F@baylink.com>
 <000601d0cd5b$aa7f1e80$ff7d5b80$@iname.com>
 <548CC203-E345-45CF-9C3C-37A0786E94A8@baylink.com>
 <D1E7801F.85EDB%edwin.mallette@mybrighthouse.com>
Message-ID: <D1E781A5.85EF0%edwin.mallette@mybrighthouse.com>

Yeah, so not a Bright House Networks email administrator but I am
affiliated with Bright House Networks.  I have forwarded the thread to our
email administration team.

Cheers!

Ed

>On 8/2/15, 3:53 PM, "NANOG on behalf of Jay Ashworth"
><nanog-bounces at nanog.org on behalf of jra at baylink.com> wrote:
>
>>I think the body text of the message should identify it as coming from
>>the Bright House email system? I think it should be written in standard
>>USAdian English, which that is decidedly not.
>>
>>Or perhaps the problem is that that subject line was supposed to be
>>parameterized, and the number of bytes is missing for some reason. But in
>>any event that is a common message to spoof, and the more bits of
>>identity that are in it the harder it is to do so. That message format
>>has almost zero bit of provider-identifiable data.
>>
>>"""
>>Your Bright House Networks IMAP email storage for user at domain.com is at
>>490MB, approaching your quota of 500MB.
>>
>>IMAP email permits you to access all your mail folders by storing them on
>>the mail server, but because of this, all mail in your folders
>>contributes to your storage limit.
>>
>>You can delete messages to reduce your storage, or move them to your PC.
>>If you delete them, or have already deleted them, you usually must
>>'compact' each folder to reclaim the extra space.
>>
>>Alternatively, you can contact Customer Care to see about having your
>>quota increased.
>>"""
>>
>>Cheers,
>>-- jra
>>
>>On August 2, 2015 3:44:35 PM EDT, Frank Bulk <frnkblk at iname.com> wrote:
>>>What do you think their message should say?  We struggled over this,
>>>too, and settled on some soft language, included information on how to
>>>purchase more storage, and also provided our email address and phone
>>>numbers.
>>>
>>>Frank
>>>
>>>-----Original Message-----
>>>From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth
>>>Sent: Sunday, August 02, 2015 1:55 PM
>>>To: nanog at nanog.org
>>>Subject: Bright House IMAP highwater warning real?
>>>
>>>Any brighthouse email admins on the list? My sister got the following
>>>high water warning message, with the included headers which, since they
>>>appear to include no Received: headers, look like they actually came
>>>from brighthouse's email cluster.
>>>
>>>If this is a real Bright House warning message, somebody should be
>>>flogged. Teaching people which messages is to believe is hard enough...
>>>
>>>Cheers,
>>>-- jra
>>>
>>>
>>>-------- Original Message --------
>>>Subject: Re: Fwd: ATTENTION: High Water Mark Notification, bytes in the
>>>mailbox!
>>>
>>>I lied. The header to yours - which I finally found - is nice and long.
>>> the header on this one is
>>>
>>>Return-Path: <>
>>>From: admin
>>>Subject: ATTENTION: High Water Mark Notification, bytes in the mailbox!
>>>Date: Sun, 2 Aug 2015 06:22:44 +0000
>>>Message-ID: e31468ce-38de-11e5-b0a6-17507733086b
>>>
>>>>>-----Original Message-----
>>>>>From: admin
>>>>>Sent: Sun, 02 Aug 2015 2:22 AM
>>>>>Subject: ATTENTION: High Water Mark Notification, bytes in the
>>>>mailbox!
>>>>>
>>>>>Your mailbox is over the high water mark.
>>>>>Please delete some messages from your mailbox.
>>>-- 
>>>Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>>-- 
>>Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>



From david at mailplus.nl  Thu Aug  6 06:59:13 2015
From: david at mailplus.nl (David Hofstee)
Date: Thu, 6 Aug 2015 08:59:13 +0200
Subject: free Tools to monitor website performance
In-Reply-To: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
Message-ID: <78C35D6C1A82D243B830523B4193CF5F9F4474A1BA@SBS1.blinker.local>

We use Zabbix for local monitoring. Quite powerful (Nagios crapped out a lot on larger setups, although 300 is not large). There is a learning curve for Zabbix.

We have a few VPS'es outside our network for DNS reasons. They are configured as (pushing) monitoring nodes too. Bye,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

-----Oorspronkelijk bericht-----
Van: NANOG [mailto:nanog-bounces at nanog.org] Namens sathish kumar Ippani
Verzonden: Thursday, August 6, 2015 4:24 AM
Aan: nanog at nanog.org
Onderwerp: free Tools to monitor website performance

Hi All,

Thanks to all for reviewing my topic, may it is slightly off topic.

We have almost 300 URL's (local and web) and we want to monitor few of them which are very critical URL's for web access and local access.

I would like to know is there any free tool or software with I can use to monitor url performance in terms of response time. Which gives more information like how much time it taken to connect the server and time to load the page and total response time.

Thanks in advance.



--
With Regards,

Sathish Ippani

From contact at nullivex.com  Thu Aug  6 07:02:51 2015
From: contact at nullivex.com (Bryan Tong)
Date: Thu, 6 Aug 2015 01:02:51 -0600
Subject: free Tools to monitor website performance
In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F9F4474A1BA@SBS1.blinker.local>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
 <78C35D6C1A82D243B830523B4193CF5F9F4474A1BA@SBS1.blinker.local>
Message-ID: <CAAARkvJGyEjpSRiq2p8C_Meoyz=uTGCGSPbFV0qh5gmZgf+68g@mail.gmail.com>

Hello,

We have been using Zabbix with great success on 900 hosts. I would
recommend it, however I must agree the learning curve can be pretty steep.
I think of Zabbix more like a piece of networking equipment where it wont
do anything until everything is configured correctly. It is far from plug
and play, but very powerful and flexible.

Thanks

On Thu, Aug 6, 2015 at 12:59 AM, David Hofstee <david at mailplus.nl> wrote:

> We use Zabbix for local monitoring. Quite powerful (Nagios crapped out a
> lot on larger setups, although 300 is not large). There is a learning curve
> for Zabbix.
>
> We have a few VPS'es outside our network for DNS reasons. They are
> configured as (pushing) monitoring nodes too. Bye,
>
>
> David Hofstee
>
> Deliverability Management
> MailPlus B.V. Netherlands (ESP)
>
> -----Oorspronkelijk bericht-----
> Van: NANOG [mailto:nanog-bounces at nanog.org] Namens sathish kumar Ippani
> Verzonden: Thursday, August 6, 2015 4:24 AM
> Aan: nanog at nanog.org
> Onderwerp: free Tools to monitor website performance
>
> Hi All,
>
> Thanks to all for reviewing my topic, may it is slightly off topic.
>
> We have almost 300 URL's (local and web) and we want to monitor few of
> them which are very critical URL's for web access and local access.
>
> I would like to know is there any free tool or software with I can use to
> monitor url performance in terms of response time. Which gives more
> information like how much time it taken to connect the server and time to
> load the page and total response time.
>
> Thanks in advance.
>
>
>
> --
> With Regards,
>
> Sathish Ippani
>



-- 
eSited LLC
(701) 390-9638

From penxiao at cisco.com  Thu Aug  6 07:48:04 2015
From: penxiao at cisco.com (Peng Xiao (penxiao))
Date: Thu, 6 Aug 2015 07:48:04 +0000
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
Message-ID: <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>

Hi Jahangir

You mean the platform you try to run yabgp on , or the platform you want to connect with?
If you want to run yabgp, we recommend you use any Linux/Unix platform, if you want to establish BGP session with it, the platform can be any routers that support BGP.

Thanks.

Peng
From: Jahangir Hossain [mailto:jahangir at parween.net]
Sent: 2015?8?6? 15:27
To: Peng Xiao (penxiao)
Cc: nanog at nanog.org
Subject: Re: Yet Another BGP (Border Gateway Protocol) Python Implementation

Hi Xiao ,

This is seems to be interesting . Can i used this in other platform who does not support bflow ?


Thanks // Jahangir

On Tue, Aug 4, 2015 at 12:29 PM, Peng Xiao (penxiao) <penxiao at cisco.com<mailto:penxiao at cisco.com>> wrote:
Hi experts

Cisco has open sourced one part of their BGP monitoring system - YABGP
And hosted source code on GitHub. https://github.com/smartbgp/yabgp
Documentation: http://yabgp.readthedocs.org/en/latest/






From xxnog at ledeuns.net  Thu Aug  6 08:07:22 2015
From: xxnog at ledeuns.net (Denis Fondras)
Date: Thu, 6 Aug 2015 10:07:22 +0200
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
Message-ID: <20150806080721.GA1404@belenos>

> Hi experts
> 
> Cisco has open sourced one part of their BGP monitoring system - YABGP
> And hosted source code on GitHub. https://github.com/smartbgp/yabgp
> Documentation: http://yabgp.readthedocs.org/en/latest/
> 

I don't want to be mean but is it of any use in 2015 to release a tool that
doesn't support IPv6 ?

Denis

From jahangir at parween.net  Thu Aug  6 07:26:35 2015
From: jahangir at parween.net (Jahangir Hossain)
Date: Thu, 6 Aug 2015 13:26:35 +0600
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
Message-ID: <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>

Hi Xiao ,

This is seems to be interesting . Can i used this in other platform who
does not support bflow ?



Thanks // Jahangir

On Tue, Aug 4, 2015 at 12:29 PM, Peng Xiao (penxiao) <penxiao at cisco.com>
wrote:

> Hi experts
>
> Cisco has open sourced one part of their BGP monitoring system - YABGP
> And hosted source code on GitHub. https://github.com/smartbgp/yabgp
> Documentation: http://yabgp.readthedocs.org/en/latest/
>
>

From jahangir at parween.net  Thu Aug  6 09:25:57 2015
From: jahangir at parween.net (Jahangir Hossain)
Date: Thu, 6 Aug 2015 15:25:57 +0600
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
Message-ID: <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>

Xiao , actually i'm trying this into UNIX and juniper Platform.

Denis , are you confirm that 2015 release doesn't support IPv6 ? This is
because i haven't tried yet in YABGP.



Thanks // Jahangir

On Thu, Aug 6, 2015 at 1:48 PM, Peng Xiao (penxiao) <penxiao at cisco.com>
wrote:

> Hi Jahangir
>
>
>
> You mean the platform you try to run yabgp on , or the platform you want
> to connect with?
>
> If you want to run yabgp, we recommend you use any Linux/Unix platform, if
> you want to establish BGP session with it, the platform can be any routers
> that support BGP.
>
>
>
> Thanks.
>
>
>
> Peng
>
> *From:* Jahangir Hossain [mailto:jahangir at parween.net]
> *Sent:* 2015?8?6? 15:27
> *To:* Peng Xiao (penxiao)
> *Cc:* nanog at nanog.org
> *Subject:* Re: Yet Another BGP (Border Gateway Protocol) Python
> Implementation
>
>
>
> Hi Xiao ,
>
> This is seems to be interesting . Can i used this in other platform who
> does not support bflow ?
>
>
>
> Thanks // Jahangir
>
>
>
> On Tue, Aug 4, 2015 at 12:29 PM, Peng Xiao (penxiao) <penxiao at cisco.com>
> wrote:
>
> Hi experts
>
> Cisco has open sourced one part of their BGP monitoring system - YABGP
> And hosted source code on GitHub. https://github.com/smartbgp/yabgp
> Documentation: http://yabgp.readthedocs.org/en/latest/
>
>
>
>
>
>
>

From tom at ninjabadger.net  Thu Aug  6 10:09:13 2015
From: tom at ninjabadger.net (Tom Hill)
Date: Thu, 06 Aug 2015 11:09:13 +0100
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
Message-ID: <55C33249.2030804@ninjabadger.net>

On 04/08/15 07:29, Peng Xiao (penxiao) wrote:
> Cisco has open sourced one part of their BGP monitoring system - YABGP
> And hosted source code on GitHub. https://github.com/smartbgp/yabgp
> Documentation: http://yabgp.readthedocs.org/en/latest/

Out of curiosity, why did you write your own project, as opposed to
using - or potentially contributing to - one of the existing projects?
(ExaBGP comes to mind, I'm sure there are others).

-- 
Tom

From job at instituut.net  Thu Aug  6 10:15:39 2015
From: job at instituut.net (Job Snijders)
Date: Thu, 6 Aug 2015 12:15:39 +0200
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <55C33249.2030804@ninjabadger.net>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <55C33249.2030804@ninjabadger.net>
Message-ID: <20150806101539.GR30897@Vurt.local>

On Thu, Aug 06, 2015 at 11:09:13AM +0100, Tom Hill wrote:
> On 04/08/15 07:29, Peng Xiao (penxiao) wrote:
> > Cisco has open sourced one part of their BGP monitoring system - YABGP
> > And hosted source code on GitHub. https://github.com/smartbgp/yabgp
> > Documentation: http://yabgp.readthedocs.org/en/latest/
> 
> Out of curiosity, why did you write your own project, as opposed to
> using - or potentially contributing to - one of the existing projects?
> (ExaBGP comes to mind, I'm sure there are others).

Because it is fun? :-)

From leonardo.ortiz at marisolsa.com  Thu Aug  6 10:58:01 2015
From: leonardo.ortiz at marisolsa.com (Leonardo Oliveira Ortiz)
Date: Thu, 6 Aug 2015 10:58:01 +0000
Subject: RES: RES: Exploits start against flaw that could hamstring huge
 swaths of
In-Reply-To: <m2bnemzmw2.wl%randy@psg.com>
References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45>
 <201508041546.t74FkZlN096153@aurora.sol.net>
 <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com>
 <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com>
 <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
 <CAL9jLaYHkDCY-YtKU+RxFvrx8TjX0Ppa9Y0KT7FYgx6dtK5n4Q@mail.gmail.com>
 <m2bnemzmw2.wl%randy@psg.com>
Message-ID: <59E8C16E83D82B439E20698AAC790B5F01384D079A@ma45>

Guys, Red Hat have a release with the patch on CR repository. Should we update using the rpm on CR or using the source provide by ISC ?

The release on CR is: 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2


-----Mensagem original-----
De: NANOG [mailto:nanog-bounces at nanog.org] Em nome de Randy Bush
Enviada em: ter?a-feira, 4 de agosto de 2015 19:53
Para: Christopher Morrow
Cc: NANOG; Joe Greco
Assunto: Re: RES: Exploits start against flaw that could hamstring huge swaths of

>> Automation just means your mistake goes many more places more 
>> quickly.
> and letting people keep poking at things that computers should be 
> doing is... much worse. people do not have reliability and 
> repeat-ability over time.

i love the devops movement; operators discover that those computers can be programmed.  wowzers!

maybe in a decade or two, we will discover mathematics.  nah.

randy

From jlmcgraw at gmail.com  Thu Aug  6 12:59:24 2015
From: jlmcgraw at gmail.com (Jesse McGraw)
Date: Thu, 06 Aug 2015 08:59:24 -0400
Subject: A simple perl script to convert Cisco IOS configuration to HTML with
 internal links for easier comprehension
Message-ID: <55C35A2C.3080300@gmail.com>

All,

     (This is me scratching an itch of my own and hoping that it might 
be useful to others on this list.  Apologies if it isn't)

   When trying to comprehend a new or complicated Cisco router 
configuration an old pet-peeve of mine is how needlessly difficult it is 
to search for a list referenced by a command, figure out what it does, 
then find my way back to the original command (by which time I?ve 
forgotten the details of the list) and figure out what it's doing with 
that list.

So I?ve been working on a small perl script to add links within IOS 
configuration files, e.g. link to an access-list from the interface 
where it?s applied, making it easier to to follow the chain of logic 
with stuff like route maps or nested service policies via clicking links 
and using the forward and back buttons in your browser to go back and 
forth between command and referenced list.

I know there is a lot of stuff I could add in to this (e.g. more 
VRF-related commands, PIX/ASA, Juniper etc).  Let me know if you think 
of anything new or notice something I?ve done wrong , there's plenty of 
room for improvement and expansion to other configuration formats.



Notes:
     Anything referenced (or potentially referenced) by something else 
is in bold.  It makes it very easy to see where ACLs etc. start and end

     There's also an option in there to reformat some numbers that are 
hard to read (e.g. traffic shaping criteria) into more human-readable 
ones.  Pure fluff.

     Surely this has been done before but I couldn't find anything in a 
few brief moments of searching so here we are.



Files are here: https://github.com/jlmcgraw/networkUtilities

At the very least you'll need iosToHtml.pl, pointers.pl, pointees.pl, 
and human_readable.pl and several CPAN modules (see setup.sh for easy 
ways to install them under Debian-derived Linux. I haven't tested this 
at all under Windows or OS X)

-Jesse

From jcurran at arin.net  Thu Aug  6 13:13:37 2015
From: jcurran at arin.net (John Curran)
Date: Thu, 6 Aug 2015 13:13:37 +0000
Subject: Fellowship application deadline tomorrow! (was: Fwd:
 [arin-announce] Last Call for ARIN Fellowships in Montreal)
References: <55BF822F.5010206@arin.net>
Message-ID: <860464BC-28CB-4ACB-AF75-2B6622DBA65B@corp.arin.net>

Folks -

    If you are aware of someone who would benefit from attending the upcoming
    ARIN & NANOG meetings but requires financial support to do so, consider
    promptly bringing the ARIN Fellowship program to their attention.   The final
    deadline for applications is _tomorrow_ - please see the attached email for
    details.

Thanks!
/John

John Curran
President and CEO
ARIN


Begin forwarded message:

From: ARIN <info at arin.net<mailto:info at arin.net>>
Subject: [arin-announce] Last Call for ARIN Fellowships in Montreal
Date: August 3, 2015 at 11:01:03 AM EDT
To: <arin-announce at arin.net<mailto:arin-announce at arin.net>>

Time is running out!  Don?t miss your chance to submit an application for the ARIN Meeting Fellowship program and take advantage of this great opportunity to join us at ARIN 36 and NANOG 65 in Montreal from 5-9 October 2015. Three to five fellowships are available, for each area of the ARIN service region: Caribbean, Canada, and the United States.

We encourage you to come and learn more about ARIN services, meet industry peers and voice your opinions in policy discussions. Take a few minutes and submit your application before the deadline this Friday, 7 August at:

https://www.arin.net/participate/meetings/fellowship.html

Selected Fellows will receive free airfare, hotel, and a stipend. Fellows have the option of extending their ARIN fellowship to include participation in NANOG 65. Please read the selection criteria as it has recently changed to allow consideration of applicants who have attended past meetings and demonstrated strong participation or engagement with their local community, including past ARIN Fellowship recipients.

This program was developed to encourage new participants so please forward this information to a colleague in order to help ARIN cultivate new voices.

Please direct any questions you have to info at arin.net.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)
_______________________________________________
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (ARIN-announce at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-announce
Please contact info at arin.net if you experience any issues.


From jhellenthal at dataix.net  Thu Aug  6 13:20:30 2015
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Thu, 6 Aug 2015 08:20:30 -0500
Subject: A simple perl script to convert Cisco IOS configuration to HTML
 with internal links for easier comprehension
In-Reply-To: <55C35A2C.3080300@gmail.com>
References: <55C35A2C.3080300@gmail.com>
Message-ID: <609F96A8-5DBE-4785-8958-B9019C539C47@dataix.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jesse, thats awesome ! thanks for sharing especially when this alligns with what I am currently involved with in the network that I am refurbishing with some high end cisco equipment. Talk about great timing !

Thank you again.
s
On Aug 6, 2015, at 07:59, Jesse McGraw <jlmcgraw at gmail.com> wrote:

All,

   (This is me scratching an itch of my own and hoping that it might be useful to others on this list.  Apologies if it isn't)

 When trying to comprehend a new or complicated Cisco router configuration an old pet-peeve of mine is how needlessly difficult it is to search for a list referenced by a command, figure out what it does, then find my way back to the original command (by which time I?ve forgotten the details of the list) and figure out what it's doing with that list.

So I?ve been working on a small perl script to add links within IOS configuration files, e.g. link to an access-list from the interface where it?s applied, making it easier to to follow the chain of logic with stuff like route maps or nested service policies via clicking links and using the forward and back buttons in your browser to go back and forth between command and referenced list.

I know there is a lot of stuff I could add in to this (e.g. more VRF-related commands, PIX/ASA, Juniper etc).  Let me know if you think of anything new or notice something I?ve done wrong , there's plenty of room for improvement and expansion to other configuration formats.



Notes:
   Anything referenced (or potentially referenced) by something else is in bold.  It makes it very easy to see where ACLs etc. start and end

   There's also an option in there to reformat some numbers that are hard to read (e.g. traffic shaping criteria) into more human-readable ones.  Pure fluff.

   Surely this has been done before but I couldn't find anything in a few brief moments of searching so here we are.



Files are here: https://github.com/jlmcgraw/networkUtilities

At the very least you'll need iosToHtml.pl, pointers.pl, pointees.pl, and human_readable.pl and several CPAN modules (see setup.sh for easy ways to install them under Debian-derived Linux. I haven't tested this at all under Windows or OS X)

- -Jesse


- -- 
 Jason Hellenthal
 JJH48-ARIN




-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVw18eAAoJEDLu+wRc4KcIfxcIAKTRy92Uz2QbHOtfW0zaNb2F
J7xWFisDmGd4lhoXO6I09u3JLaQS59v48JXAuyawt0k0mEoQ708rIAN6mKaFKZ0i
OBGGfbVcP+IzCdbSgBlbkzMk3rnqpUGljmAulwGZQpgbfqzHaT8SoXouuoq06vqF
MtsxX0cdbedGCKqORmgJgqvhEFXlcmoOaejHj5wLIsS0yhjZhPyECM2P6Fo3I6jX
Iq8Oc1IgIRncNCuCZrUk7x58x5Dtr1GfJZTDmk+O5ixbtuhbUnLJs4rpmf0H4GeL
Rj0yrPe4EL3G1aAvInBS+dqiqTUMwt9WPssyGYlEnIUSPmR0Loa6y6bx8Fy1tCU=
=ANU6
-----END PGP SIGNATURE-----

From glen.kent at gmail.com  Thu Aug  6 13:28:44 2015
From: glen.kent at gmail.com (Glen Kent)
Date: Thu, 6 Aug 2015 18:58:44 +0530
Subject: Strange traceroute result to VM in EC2, Singapore
Message-ID: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>

Hi,

I have two internet connections and can reach the VM in EC2, Singapore over
either connection.

I am doing an experiment for which I traceroute to this VM from the two
different internet connections (to really get an idea of the number of hops
between my local machine and the VM over the 2 different connections)

I have attached the output of my two traceroute's.

While i am able to reach the exact VM when i am on one internet connection,
i am not able to do the same, when am over the other internet connection.

Both are broadband connections out of the same office premises.

Any idea what could be happening?

Thanks, Glen

From dovid at telecurve.com  Thu Aug  6 13:36:14 2015
From: dovid at telecurve.com (Dovid Bender)
Date: Thu, 6 Aug 2015 09:36:14 -0400
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
Message-ID: <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>

No trace attached.

On Thu, Aug 6, 2015 at 9:28 AM, Glen Kent <glen.kent at gmail.com> wrote:

> Hi,
>
> I have two internet connections and can reach the VM in EC2, Singapore over
> either connection.
>
> I am doing an experiment for which I traceroute to this VM from the two
> different internet connections (to really get an idea of the number of hops
> between my local machine and the VM over the 2 different connections)
>
> I have attached the output of my two traceroute's.
>
> While i am able to reach the exact VM when i am on one internet connection,
> i am not able to do the same, when am over the other internet connection.
>
> Both are broadband connections out of the same office premises.
>
> Any idea what could be happening?
>
> Thanks, Glen
>

From glen.kent at gmail.com  Thu Aug  6 13:43:51 2015
From: glen.kent at gmail.com (Glen Kent)
Date: Thu, 6 Aug 2015 19:13:51 +0530
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
Message-ID: <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>

Ooops. The attachment was dropped last time. This time its inline:

When my traceroute works:

[image: Inline image 1]

When it doesnt:

[image: Inline image 2]

Thanks, Glen
On Thu, Aug 6, 2015 at 7:06 PM, Dovid Bender <dovid at telecurve.com> wrote:

> No trace attached.
>
> On Thu, Aug 6, 2015 at 9:28 AM, Glen Kent <glen.kent at gmail.com> wrote:
>
>> Hi,
>>
>> I have two internet connections and can reach the VM in EC2, Singapore
>> over
>> either connection.
>>
>> I am doing an experiment for which I traceroute to this VM from the two
>> different internet connections (to really get an idea of the number of
>> hops
>> between my local machine and the VM over the 2 different connections)
>>
>> I have attached the output of my two traceroute's.
>>
>> While i am able to reach the exact VM when i am on one internet
>> connection,
>> i am not able to do the same, when am over the other internet connection.
>>
>> Both are broadband connections out of the same office premises.
>>
>> Any idea what could be happening?
>>
>> Thanks, Glen
>>
>
>

From Patrick.Darden at p66.com  Thu Aug  6 13:46:24 2015
From: Patrick.Darden at p66.com (Darden, Patrick)
Date: Thu, 6 Aug 2015 13:46:24 +0000
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
 <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
Message-ID: <a9e40c41ad9144838796d90c23e8d5cb@BRTEXMB02.phillips66.net>


Text or it never happened.

--p


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Glen Kent
Sent: Thursday, August 06, 2015 8:44 AM
To: nanog at nanog.org
Subject: [EXTERNAL]Re: Strange traceroute result to VM in EC2, Singapore

Ooops. The attachment was dropped last time. This time its inline:

When my traceroute works:

[image: Inline image 1]

When it doesnt:

[image: Inline image 2]

Thanks, Glen
On Thu, Aug 6, 2015 at 7:06 PM, Dovid Bender <dovid at telecurve.com> wrote:

> No trace attached.
>
> On Thu, Aug 6, 2015 at 9:28 AM, Glen Kent <glen.kent at gmail.com> wrote:
>
>> Hi,
>>
>> I have two internet connections and can reach the VM in EC2, 
>> Singapore over either connection.
>>
>> I am doing an experiment for which I traceroute to this VM from the 
>> two different internet connections (to really get an idea of the 
>> number of hops between my local machine and the VM over the 2 
>> different connections)
>>
>> I have attached the output of my two traceroute's.
>>
>> While i am able to reach the exact VM when i am on one internet 
>> connection, i am not able to do the same, when am over the other 
>> internet connection.
>>
>> Both are broadband connections out of the same office premises.
>>
>> Any idea what could be happening?
>>
>> Thanks, Glen
>>
>
>

From Valdis.Kletnieks at vt.edu  Thu Aug  6 13:56:48 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 06 Aug 2015 09:56:48 -0400
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: Your message of "Thu, 06 Aug 2015 13:46:24 -0000."
 <a9e40c41ad9144838796d90c23e8d5cb@BRTEXMB02.phillips66.net>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
 <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
 <a9e40c41ad9144838796d90c23e8d5cb@BRTEXMB02.phillips66.net>
Message-ID: <42996.1438869408@turing-police.cc.vt.edu>

On Thu, 06 Aug 2015 13:46:24 -0000, "Darden, Patrick" said:
>
> Text or it never happened.

You, sir, owe me some monitor cleaner. You also win the internets for today.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150806/63a45791/attachment.pgp>

From penxiao at cisco.com  Thu Aug  6 14:25:55 2015
From: penxiao at cisco.com (Peng Xiao (penxiao))
Date: Thu, 6 Aug 2015 14:25:55 +0000
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
Message-ID: <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>

Currently, yabgp does not support IPv6 address family. We only support IPv4 now.

Thanks and Regards,
Xiao peng

From: Jahangir Hossain [mailto:jahangir at parween.net]
Sent: 2015?8?6? 17:26
To: Peng Xiao (penxiao); xxnog at ledeuns.net
Cc: nanog at nanog.org
Subject: Re: Yet Another BGP (Border Gateway Protocol) Python Implementation

Xiao , actually i'm trying this into UNIX and juniper Platform.
Denis , are you confirm that 2015 release doesn't support IPv6 ? This is because i haven't tried yet in YABGP.



Thanks // Jahangir
On Thu, Aug 6, 2015 at 1:48 PM, Peng Xiao (penxiao) <penxiao at cisco.com<mailto:penxiao at cisco.com>> wrote:
Hi Jahangir

You mean the platform you try to run yabgp on , or the platform you want to connect with?
If you want to run yabgp, we recommend you use any Linux/Unix platform, if you want to establish BGP session with it, the platform can be any routers that support BGP.

Thanks.

Peng
From: Jahangir Hossain [mailto:jahangir at parween.net<mailto:jahangir at parween.net>]
Sent: 2015?8?6? 15:27
To: Peng Xiao (penxiao)
Cc: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: Re: Yet Another BGP (Border Gateway Protocol) Python Implementation

Hi Xiao ,

This is seems to be interesting . Can i used this in other platform who does not support bflow ?

Thanks // Jahangir

On Tue, Aug 4, 2015 at 12:29 PM, Peng Xiao (penxiao) <penxiao at cisco.com<mailto:penxiao at cisco.com>> wrote:
Hi experts

Cisco has open sourced one part of their BGP monitoring system - YABGP
And hosted source code on GitHub. https://github.com/smartbgp/yabgp
Documentation: http://yabgp.readthedocs.org/en/latest/







From A.L.M.Buxey at lboro.ac.uk  Thu Aug  6 14:38:17 2015
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Thu, 6 Aug 2015 14:38:17 +0000
Subject: A simple perl script to convert Cisco IOS configuration to HTML
 with internal links for easier comprehension
In-Reply-To: <55C35A2C.3080300@gmail.com>
References: <55C35A2C.3080300@gmail.com>
Message-ID: <20150806143817.GA25545@lboro.ac.uk>

Hi,

very nice.... but I now have an urge to getting this integrated with RANCID
and I just dont have the time, frustrating!  ;-)

alan

From glen.kent at gmail.com  Thu Aug  6 15:23:05 2015
From: glen.kent at gmail.com (Glen Kent)
Date: Thu, 6 Aug 2015 20:53:05 +0530
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
 <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
Message-ID: <CAPLq3UMVbrEosXqpkrNKkGw-1XhjNxZ5Buc3u_4oE0qh4uk1uQ@mail.gmail.com>

Really sorry. Didnt realize that this is a text-only forum.

When my traceroute to 52.74.124.136 works:

~$ traceroute 52.74.124.136
traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
1 xxxxxxx xxxxxxx 0.412 ms 0.472 ms 0.439 ms
2 xxxxxxx xxxxxxx 2.98 ms 2.971 ms 2.999 ms
3 xxxxxxx xxxxxxx 5.345 ms 5.546 ms 5.519 ms
4 xxxxxxx xxxxxxx 3.172 ms 3.051 ms 3.010 ms
5 if-6-2.tcore2.SVW-Singapore.as6543.net (180.87.37.14) 56.751 ms 56.285 ms
54.592 ms
6 180.87.15.206 (180.87.15.206) 73.468ms 66.993 ms 66.734 ms
7 203.83.223.58 (203.83.223.58) 43.737 ms 43.513 ms 44.029 ms
8 203.83.223.15 (203.83.223.15) 47.239 ms 46.382 ms 203.83.223.74
(203.83.223.74)  44.144 ms
9 203.83.223.231 (203.83.223.231) 44.431 ms 203.83.223.233 (203.83.223.233)
 45.699 ms 46.158 ms
10 ec2-52-74-124-136.ap-southeast-1.compute.amazon.com (52.74.124.136)
 44.067 ms 43.492 ms 43.499 ms

When it doesnt:

~$ traceroute 52.74.124.136
traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
1 xxxxxxx xxxxxxx 23.272 ms 25.011 ms 26.072 ms
2 xxxxxxx xxxxxxx 27.058 ms 28.971 ms 29.999 ms
3 xxxxxxx xxxxxxx 33.025 ms 33.996 ms 38.822 ms
4 p38895.sgw.equinix.com (202.79.197.87) 78.964 ms 60.051 ms 83.010 ms
5 203.83.223.4 (203.83.223.4) 63.682 ms 64.610 ms 65.837 ms
6 203.83.223.17 (203.83.223.17) 67.271 ms 203.83.223.23 (203.83.223.23)
68.521 ms 203.83.223.17 (203.83.223.17) 70.526 ms
7 203.83.223.233 (203.83.223.233) 71.624 ms 72.805 ms 74.471 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

From glen.kent at gmail.com  Thu Aug  6 16:05:46 2015
From: glen.kent at gmail.com (Glen Kent)
Date: Thu, 6 Aug 2015 21:35:46 +0530
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAPLq3UMVbrEosXqpkrNKkGw-1XhjNxZ5Buc3u_4oE0qh4uk1uQ@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
 <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
 <CAPLq3UMVbrEosXqpkrNKkGw-1XhjNxZ5Buc3u_4oE0qh4uk1uQ@mail.gmail.com>
Message-ID: <CAPLq3UP-dDPHH_O=ar3M_yvQjcXtHNK-tTbkXfJX7egtGgchRQ@mail.gmail.com>

I find this bizzare because even when the traceroute doesnt work, I am
actually able to ping and access the machine.

I know that the VM responds to traceroutes, since it did respond to my
traceroute when i was on the other broadband network.

So i really fail to understand why the traceroute on the other network
failed.

Any pointers on this would be very helpful.

Thanks, GLen

On Thu, Aug 6, 2015 at 8:53 PM, Glen Kent <glen.kent at gmail.com> wrote:

> Really sorry. Didnt realize that this is a text-only forum.
>
> When my traceroute to 52.74.124.136 works:
>
> ~$ traceroute 52.74.124.136
> traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
> 1 xxxxxxx xxxxxxx 0.412 ms 0.472 ms 0.439 ms
> 2 xxxxxxx xxxxxxx 2.98 ms 2.971 ms 2.999 ms
> 3 xxxxxxx xxxxxxx 5.345 ms 5.546 ms 5.519 ms
> 4 xxxxxxx xxxxxxx 3.172 ms 3.051 ms 3.010 ms
> 5 if-6-2.tcore2.SVW-Singapore.as6543.net (180.87.37.14) 56.751 ms 56.285
> ms 54.592 ms
> 6 180.87.15.206 (180.87.15.206) 73.468ms 66.993 ms 66.734 ms
> 7 203.83.223.58 (203.83.223.58) 43.737 ms 43.513 ms 44.029 ms
> 8 203.83.223.15 (203.83.223.15) 47.239 ms 46.382 ms 203.83.223.74
> (203.83.223.74)  44.144 ms
> 9 203.83.223.231 (203.83.223.231) 44.431 ms 203.83.223.233
> (203.83.223.233)  45.699 ms 46.158 ms
> 10 ec2-52-74-124-136.ap-southeast-1.compute.amazon.com (52.74.124.136)
>  44.067 ms 43.492 ms 43.499 ms
>
> When it doesnt:
>
> ~$ traceroute 52.74.124.136
> traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
> 1 xxxxxxx xxxxxxx 23.272 ms 25.011 ms 26.072 ms
> 2 xxxxxxx xxxxxxx 27.058 ms 28.971 ms 29.999 ms
> 3 xxxxxxx xxxxxxx 33.025 ms 33.996 ms 38.822 ms
> 4 p38895.sgw.equinix.com (202.79.197.87) 78.964 ms 60.051 ms 83.010 ms
> 5 203.83.223.4 (203.83.223.4) 63.682 ms 64.610 ms 65.837 ms
> 6 203.83.223.17 (203.83.223.17) 67.271 ms 203.83.223.23 (203.83.223.23)
> 68.521 ms 203.83.223.17 (203.83.223.17) 70.526 ms
> 7 203.83.223.233 (203.83.223.233) 71.624 ms 72.805 ms 74.471 ms
> 8 * * *
> 9 * * *
> 10 * * *
> 11 * * *
> 12 * * *
> 13 * * *
> 14 * * *
> 15 * * *
> 16 * * *
> 17 * * *
> 18 * * *
> 19 * * *
> 20 * * *
> 21 * * *
> 22 * * *
> 23 * * *
> 24 * * *
> 25 * * *
> 26 * * *
> 27 * * *
> 28 * * *
> 29 * * *
> 30 * * *
>
>

From morrowc.lists at gmail.com  Thu Aug  6 16:11:15 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 6 Aug 2015 12:11:15 -0400
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAPLq3UP-dDPHH_O=ar3M_yvQjcXtHNK-tTbkXfJX7egtGgchRQ@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
 <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
 <CAPLq3UMVbrEosXqpkrNKkGw-1XhjNxZ5Buc3u_4oE0qh4uk1uQ@mail.gmail.com>
 <CAPLq3UP-dDPHH_O=ar3M_yvQjcXtHNK-tTbkXfJX7egtGgchRQ@mail.gmail.com>
Message-ID: <CAL9jLaajJ2V3phbxTsrAHRBzW7Q+qazQi3eR44Bk=472Y_9PJg@mail.gmail.com>

On Thu, Aug 6, 2015 at 12:05 PM, Glen Kent <glen.kent at gmail.com> wrote:
> I find this bizzare because even when the traceroute doesnt work, I am
> actually able to ping and access the machine.
>
> I know that the VM responds to traceroutes, since it did respond to my
> traceroute when i was on the other broadband network.
>
> So i really fail to understand why the traceroute on the other network
> failed.
>
> Any pointers on this would be very helpful.

the las hop reported in the 'fails' traceroute is an amazon ip
address, I suspect some miscarriage of packet-justice inside AWS is
happening. You asked them already I guess?

From jtk at cymru.com  Thu Aug  6 16:12:45 2015
From: jtk at cymru.com (John Kristoff)
Date: Thu, 6 Aug 2015 11:12:45 -0500
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAPLq3UP-dDPHH_O=ar3M_yvQjcXtHNK-tTbkXfJX7egtGgchRQ@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
 <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
 <CAPLq3UMVbrEosXqpkrNKkGw-1XhjNxZ5Buc3u_4oE0qh4uk1uQ@mail.gmail.com>
 <CAPLq3UP-dDPHH_O=ar3M_yvQjcXtHNK-tTbkXfJX7egtGgchRQ@mail.gmail.com>
Message-ID: <20150806111245.09808adb@localhost>

On Thu, 6 Aug 2015 21:35:46 +0530
Glen Kent <glen.kent at gmail.com> wrote:

> Any pointers on this would be very helpful.

Presumably you're doing this from a Linux host.  You might try these
flags to see what you get:

       -T, --tcp
            Use TCP SYN for probes

       -e, --extensions
              Show  ICMP  extensions  (rfc4884).  The  general  form is CLASS/TYPE: followed by a hexadecimal dump.  The MPLS (rfc4950) is shown
              parsed, in a form: MPLS:L=label,E=exp_use,S=stack_bottom,T=TTL (more objects separated by / ).

and a good general reference for the netop:

  <http://cluepon.net/ras/traceroute.pdf>

John

From Valdis.Kletnieks at vt.edu  Thu Aug  6 16:16:07 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 06 Aug 2015 12:16:07 -0400
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: Your message of "Thu, 06 Aug 2015 14:25:55 -0000."
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
Message-ID: <54227.1438877767@turing-police.cc.vt.edu>

On Thu, 06 Aug 2015 14:25:55 -0000, "Peng Xiao (penxiao)" said:
> Currently, yabgp does not support IPv6 address family. We only support IPv4 now.

http://tnx.nl/legacy-ip-only.svg

Seriously guys.  It's 2015.  We really don't care what you hack for your
own use - but publicly announcing stuff that doesn't have IPv6 support is
getting kind of embarassing...

*especially* when it's a major vendor open-sourcing their code. (I'm still
willing to cut a *little* slack for "two guys and a stack of empty pizza
boxes" software....)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150806/1030f1da/attachment.pgp>

From morrowc.lists at gmail.com  Thu Aug  6 16:27:49 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 6 Aug 2015 12:27:49 -0400
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <54227.1438877767@turing-police.cc.vt.edu>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>
Message-ID: <CAL9jLab2+Poe2mCE7bk_26Kk1Xqjy3aeW-p+0w+0p31HYue10g@mail.gmail.com>

On Thu, Aug 6, 2015 at 12:16 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Thu, 06 Aug 2015 14:25:55 -0000, "Peng Xiao (penxiao)" said:
>> Currently, yabgp does not support IPv6 address family. We only support IPv4 now.
>
> http://tnx.nl/legacy-ip-only.svg
>
> Seriously guys.  It's 2015.  We really don't care what you hack for your
> own use - but publicly announcing stuff that doesn't have IPv6 support is
> getting kind of embarassing...
>
> *especially* when it's a major vendor open-sourcing their code. (I'm still
> willing to cut a *little* slack for "two guys and a stack of empty pizza
> boxes" software....)

note that the list of 'references' for yabgp includes:
RFC2545
RFC4798
RFC5701

and this interesting snippet:
 address-family ipv6 unicast


>
>

From jtk at cymru.com  Thu Aug  6 16:51:47 2015
From: jtk at cymru.com (John Kristoff)
Date: Thu, 6 Aug 2015 11:51:47 -0500
Subject: Did *bufferbloat* cause the 2010 flashcrash?
In-Reply-To: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
Message-ID: <20150806115147.4d9da0d4@localhost>

On Sun, 02 Aug 2015 23:19:02 -0400
Jay Ashworth <jra at baylink.com> wrote:

> This guy seems to think so, and his arguments seem pretty convincing
> to me, but I don't understand the financial system as well as I might.

Interesting Jay, thanks for forwarding that.

I'm not convinced, but I could be.  Interesting hypothesis that, at
least for me, raises more questions that I'm not qualified to answer
either. Perhaps most fundamentally, what and where exactly is the
"queue" in the transmission system that Nanex refers to?

It would seem surprising that delays in general due to long queues
would not have been noticed before, since or would have caused other
more far reaching problems.

If there is serious debate about the cause of the problem, then it
may be necessary to invite an independent, neutral party to fully
investigate.  One has to ask, wouldn't it be convenient for Nanex
if queueing delay from others into their systems were the cause?

John

From morrowc.lists at gmail.com  Thu Aug  6 16:58:50 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 6 Aug 2015 12:58:50 -0400
Subject: Did *bufferbloat* cause the 2010 flashcrash?
In-Reply-To: <20150806115147.4d9da0d4@localhost>
References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
 <20150806115147.4d9da0d4@localhost>
Message-ID: <CAL9jLaapgN7TRtTf4A3hs7vuJyXzwA+f6-O+gAND9Fc6bY47Nw@mail.gmail.com>

On Thu, Aug 6, 2015 at 12:51 PM, John Kristoff <jtk at cymru.com> wrote:
> It would seem surprising that delays in general due to long queues
> would not have been noticed before, since or would have caused other
> more far reaching problems.

bufferbloat is the boogieman... of late. I think that's foolish :(
I think this comment from jtk is really on point though! 'why only
then?' that sure seems convenient, eh?

From cboyd at gizmopartners.com  Thu Aug  6 17:01:46 2015
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Thu, 6 Aug 2015 12:01:46 -0500
Subject: Data Center operations mail list?
Message-ID: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>

Is there a mail list that?s analogous to NANOG, but focused on the data center infrastructure and operations?  The shorty.com hosted list is defunct.

Thanks, and apologies for the tangential topic.

?Chris


From sean at donelan.com  Thu Aug  6 17:28:19 2015
From: sean at donelan.com (Sean Donelan)
Date: Thu, 6 Aug 2015 13:28:19 -0400 (EDT)
Subject: Did *bufferbloat* cause the 2010 flashcrash?
In-Reply-To: <CAL9jLaapgN7TRtTf4A3hs7vuJyXzwA+f6-O+gAND9Fc6bY47Nw@mail.gmail.com>
References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
 <20150806115147.4d9da0d4@localhost>
 <CAL9jLaapgN7TRtTf4A3hs7vuJyXzwA+f6-O+gAND9Fc6bY47Nw@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1508061311270.47165@cnex.qbaryna.pbz>

On Thu, 6 Aug 2015, Christopher Morrow wrote:
> bufferbloat is the boogieman... of late. I think that's foolish :(
> I think this comment from jtk is really on point though! 'why only
> then?' that sure seems convenient, eh?

Failures almost never have a single cause.

Transport networks are never perfect, i.e. delays, dropped packets, data
corruption, etc. They may be contributing factors, or a combination of
rare events.  The hard question that SEC and the industry has been 
wrestling with is "Why?" not so much "How?"

The apparent condititions didn't change, but the system reacted 
differently during those seconds.  Why?  What was different?


From joelja at bogus.com  Thu Aug  6 17:31:18 2015
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 6 Aug 2015 10:31:18 -0700
Subject: Did *bufferbloat* cause the 2010 flashcrash?
In-Reply-To: <CAL9jLaapgN7TRtTf4A3hs7vuJyXzwA+f6-O+gAND9Fc6bY47Nw@mail.gmail.com>
References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
 <20150806115147.4d9da0d4@localhost>
 <CAL9jLaapgN7TRtTf4A3hs7vuJyXzwA+f6-O+gAND9Fc6bY47Nw@mail.gmail.com>
Message-ID: <55C399E6.7060904@bogus.com>

On 8/6/15 9:58 AM, Christopher Morrow wrote:
> On Thu, Aug 6, 2015 at 12:51 PM, John Kristoff <jtk at cymru.com> wrote:
>> It would seem surprising that delays in general due to long queues
>> would not have been noticed before, since or would have caused other
>> more far reaching problems.
> 
> bufferbloat is the boogieman... of late. I think that's foolish :(
> I think this comment from jtk is really on point though! 'why only
> then?' that sure seems convenient, eh?

The queuing like the RBC dudes were doing was in order transmission not
on the wire. given wires of various lengths having the request arrive on
different exchanges at different times based on  distance was considered
unedesirable (by people loooking to reduce the opportunity for arbitrage
on latency).

I have have minimal experience with trading platforms but what switch
vendors were selling us as a latency sensitive customer (and HFT shops
at time) were broadcom or fulcrum asics which by virtue of being
cut-through are essentially minimally buffered.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150806/d3b7cd24/attachment.pgp>

From bill at herrin.us  Thu Aug  6 17:44:34 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 6 Aug 2015 13:44:34 -0400
Subject: Did *bufferbloat* cause the 2010 flashcrash?
In-Reply-To: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
Message-ID: <CAP-guGWCZyr8tAVtdwC7a_r4cTFXkkBVSj+tm5f-kysvYXCgfQ@mail.gmail.com>

On Sun, Aug 2, 2015 at 11:19 PM, Jay Ashworth <jra at baylink.com> wrote:
> This guy seems to think so, and his arguments seem pretty
> convincing to me, but I don't understand the financial system
> as well as I might.

Hi Jay,

My read is that the author got it upside down.

The intermediate cause of the problem was propagation delay (including
buffer bloat) which induced an oscillating set of states in the
trading software.

The root cause was a flipping jassack trying to out-time his
competitors by assuming a degree of instantaneity which proved untrue.
Don't do that. Don't make assumptions about network timing. You can
count on being wrong. If timing matters to your application, find a
way to continuously measure.

Regards,
Bill Herrin

P.S. Recruiters: No, I do NOT want to move to New York City and
engineer another half millisecond out of your network. I would,
however, welcome a law which bans both buying and selling instruments
of the same stock or commodity within 24 hours.


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From stenn at nwtime.org  Thu Aug  6 17:55:24 2015
From: stenn at nwtime.org (Harlan Stenn)
Date: Thu, 6 Aug 2015 10:55:24 -0700
Subject: Did *bufferbloat* cause the 2010 flashcrash?
In-Reply-To: <CAP-guGWCZyr8tAVtdwC7a_r4cTFXkkBVSj+tm5f-kysvYXCgfQ@mail.gmail.com>
References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
 <CAP-guGWCZyr8tAVtdwC7a_r4cTFXkkBVSj+tm5f-kysvYXCgfQ@mail.gmail.com>
Message-ID: <55C39F8C.9040606@nwtime.org>

In 8/6/15 10:44 AM, William Herrin wrote:
> The intermediate cause of the problem was propagation delay (including
> buffer bloat) which induced an oscillating set of states in the
> trading software.
> 
> The root cause was a flipping jassack trying to out-time his
> competitors by assuming a degree of instantaneity which proved untrue.
> Don't do that. Don't make assumptions about network timing. You can
> count on being wrong. If timing matters to your application, find a
> way to continuously measure.

Similar things happen when folks decide they are going to twiddle the
knobs of NTP's behavior.  NTP works locally, and gets/provides
information globally.  More or less.  When folks decide to make a change
in its core behavior, the usually don't consider how those changes will
affect anybody else.

I know enough about this to know I don't know anywhere near enough about
it, so I leave the knobs alone.

-- 
Harlan Stenn <stenn at nwtime.org>
http://networktimefoundation.org - be a member!


From mhuff at ox.com  Thu Aug  6 17:55:38 2015
From: mhuff at ox.com (Matthew Huff)
Date: Thu, 6 Aug 2015 17:55:38 +0000
Subject: Did *bufferbloat* cause the 2010 flashcrash?
In-Reply-To: <55C399E6.7060904@bogus.com>
References: <4EDA85BE-CD86-4DA9-8ED5-78500E858F79@baylink.com>
 <20150806115147.4d9da0d4@localhost>
 <CAL9jLaapgN7TRtTf4A3hs7vuJyXzwA+f6-O+gAND9Fc6bY47Nw@mail.gmail.com>
 <55C399E6.7060904@bogus.com>
Message-ID: <deb687bd475841858ca51bf3d5a86b23@pur-vm-exch13n1.ox.com>

Various technical issues may have made things worse, but the central cause of the flash crash was due to lack of regulator and/or procedures for the now distributed markets (exchanges, ecns, dark-pools, etc...) on a market imbalance.

What started the whole thing was a selloff of a large quantity of e-mini futures, which caused a broad run on the market. This is a feature, not a bug. The thundering herd responded, as normal, by starting their own sell-off

Before the decentralized markets, when there was a market imbalance (all buyers or all sellers), the "specialist" or "market maker" would halt trading in a symbol, and work with the buyers/sellers to determine a new price and re-open with the new price. The problem is without coordination, when the NYSE/Nasdaq market makers halted trading, the distributed exchanges weren't halted. Since the market makers in those exchanges are required to always have quotes, they put out "stub" quotes of 0.01/$10000.00. Since there weren't valid quotes on the regular exchanges and because of RegNMS, those stub quotes got disseminated as BBO. This was a cosmetic issue and didn't effect trading.

Who really got screwed were people that had a stop order on their stocks and didn't realize there were no guarantees of trading through that price. For example, if you bought a stock at $100, and put a stop order to sell at $90, and there was a market imbalance, the price could trade discontinuously. For example the last valid quote could have been at $95.90, then halted, then re-opened at $82.50. The stop order would sell immediately at $82.50, not the $90 people thought. Then the stock could recover and be trading at $95.05 and you could really feel you were screwed. But that's how it is supposed to work.

----
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 jaeggli
Sent: Thursday, August 6, 2015 1:31 PM
To: Christopher Morrow <morrowc.lists at gmail.com>; John Kristoff <jtk at cymru.com>
Cc: nanog list <nanog at nanog.org>
Subject: Re: Did *bufferbloat* cause the 2010 flashcrash?

On 8/6/15 9:58 AM, Christopher Morrow wrote:
> On Thu, Aug 6, 2015 at 12:51 PM, John Kristoff <jtk at cymru.com> wrote:
>> It would seem surprising that delays in general due to long queues
>> would not have been noticed before, since or would have caused other
>> more far reaching problems.
> 
> bufferbloat is the boogieman... of late. I think that's foolish :(
> I think this comment from jtk is really on point though! 'why only
> then?' that sure seems convenient, eh?

The queuing like the RBC dudes were doing was in order transmission not
on the wire. given wires of various lengths having the request arrive on
different exchanges at different times based on  distance was considered
unedesirable (by people loooking to reduce the opportunity for arbitrage
on latency).

I have have minimal experience with trading platforms but what switch
vendors were selling us as a latency sensitive customer (and HFT shops
at time) were broadcom or fulcrum asics which by virtue of being
cut-through are essentially minimally buffered.




From jay at west.net  Thu Aug  6 19:42:00 2015
From: jay at west.net (Jay Hennigan)
Date: Thu, 06 Aug 2015 12:42:00 -0700
Subject: AW: Mac compatible SFP+/XFP programmer
In-Reply-To: <e4945460f0ac49e985c4560820159348@anx-i-dag02.anx.local>
References: <D479383B-E903-48B3-9AAE-69CE5F6045BF@lixfeld.ca>
 <AA251339-0E42-4503-9D52-8676138BA098@720.fr>
 <208B1F28-0A94-4059-9DFE-42176F2812DD@netideainc.ca>
 <CADfGf65b5TNGxwyDgPXGOj4fPJBMZUbARvjm+kUxZUNuzd0Zdg@mail.gmail.com>
 <e4945460f0ac49e985c4560820159348@anx-i-dag02.anx.local>
Message-ID: <55C3B888.4050808@west.net>

On 8/4/15 3:01 PM, J?rgen Jaritsch wrote:
> I can also suggest you the Multi-Fiber-Tool from Solid Optics:
>
> http://www.solid-optics.com/tools/multi-fiber-tool/so-multi-fiber-tool-id1768.html
>
> Works great but I've never tested it with an Mac ... MacOS is at least listed as supported.

This looked kind of promising, but very limited info on their website, 
especially pricing. I called and found that it ONLY works with Solid 
Optics transceivers, and once you buy it at pricing from $600 to $900, 
you then have to pay $300 per year or it becomes a (relatively small and 
ineffective for use with anything bigger than a skateboard) wheel chock.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From randy at psg.com  Thu Aug  6 22:40:01 2015
From: randy at psg.com (Randy Bush)
Date: Fri, 07 Aug 2015 07:40:01 +0900
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <54227.1438877767@turing-police.cc.vt.edu>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>
Message-ID: <m2vbcsrqgu.wl%randy@psg.com>

perhaps dissing someone for their free code is even ruder than not doing
ipv6 in 2015?  you don't have to use either.

randy

From jlmcgraw at gmail.com  Fri Aug  7 00:23:07 2015
From: jlmcgraw at gmail.com (Jesse McGraw)
Date: Thu, 06 Aug 2015 20:23:07 -0400
Subject: A simple perl script to convert Cisco IOS configuration to HTML
 with internal links for easier comprehension
In-Reply-To: <D1E90F14.1D76B%bora@pnnl.gov>
References: <55C35A2C.3080300@gmail.com> <D1E90F14.1D76B%bora@pnnl.gov>
Message-ID: <55C3FA6B.5010003@gmail.com>

I've now added some initial support for NXOS

On 08/06/2015 04:18 PM, Akyol, Bora A wrote:
> Jesse
>
> Does this also work for NXOS and IOS XR (thank you cisco?)
>
> Thanks
>
> Bora
> PNNL.GOV
>
> On 8/6/15, 5:59 AM, "Jesse McGraw" <jlmcgraw at gmail.com> wrote:
>
>> All,
>>
>>      (This is me scratching an itch of my own and hoping that it might
>> be useful to others on this list.  Apologies if it isn't)
>>
>>    When trying to comprehend a new or complicated Cisco router
>> configuration an old pet-peeve of mine is how needlessly difficult it is
>> to search for a list referenced by a command, figure out what it does,
>> then find my way back to the original command (by which time I?ve
>> forgotten the details of the list) and figure out what it's doing with
>> that list.
>>
>> So I?ve been working on a small perl script to add links within IOS
>> configuration files, e.g. link to an access-list from the interface
>> where it?s applied, making it easier to to follow the chain of logic
>> with stuff like route maps or nested service policies via clicking links
>> and using the forward and back buttons in your browser to go back and
>> forth between command and referenced list.
>>
>> I know there is a lot of stuff I could add in to this (e.g. more
>> VRF-related commands, PIX/ASA, Juniper etc).  Let me know if you think
>> of anything new or notice something I?ve done wrong , there's plenty of
>> room for improvement and expansion to other configuration formats.
>>
>>
>>
>> Notes:
>>      Anything referenced (or potentially referenced) by something else
>> is in bold.  It makes it very easy to see where ACLs etc. start and end
>>
>>      There's also an option in there to reformat some numbers that are
>> hard to read (e.g. traffic shaping criteria) into more human-readable
>> ones.  Pure fluff.
>>
>>      Surely this has been done before but I couldn't find anything in a
>> few brief moments of searching so here we are.
>>
>>
>>
>> Files are here: https://github.com/jlmcgraw/networkUtilities
>>
>> At the very least you'll need iosToHtml.pl, pointers.pl, pointees.pl,
>> and human_readable.pl and several CPAN modules (see setup.sh for easy
>> ways to install them under Debian-derived Linux. I haven't tested this
>> at all under Windows or OS X)
>>
>> -Jesse
>


From plucena at coopergeneral.com  Fri Aug  7 01:49:56 2015
From: plucena at coopergeneral.com (Pablo Lucena)
Date: Thu, 6 Aug 2015 21:49:56 -0400
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <m2vbcsrqgu.wl%randy@psg.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu> <m2vbcsrqgu.wl%randy@psg.com>
Message-ID: <CAH+2GVJs3RxeapJtD3ZK4JHLTDiWfUr-qy4JnpM9zwh=t_iV=g@mail.gmail.com>

This is a nice Python implementation. Thanks for open sourcing this!

On Thu, Aug 6, 2015 at 6:40 PM, Randy Bush <randy at psg.com> wrote:

> perhaps dissing someone for their free code is even ruder than not doing
> ipv6 in 2015?  you don't have to use either.
>
> randy
>

From penxiao at cisco.com  Fri Aug  7 02:41:16 2015
From: penxiao at cisco.com (Peng Xiao (penxiao))
Date: Fri, 7 Aug 2015 02:41:16 +0000
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <54227.1438877767@turing-police.cc.vt.edu>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>
Message-ID: <5A34F4AC18539E47A797E3916C0E55B13584A189@xmb-rcd-x10.cisco.com>

Hi guys,

Ipv6 and other address families are under development. We have already designed the data structures for them as you can see from the documentation, but it's just some testing code and not stable and we are not doing them after careful consideration.
But at last, they will come out.


-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: 2015?8?7? 0:16
To: Peng Xiao (penxiao)
Cc: Jahangir Hossain; xxnog at ledeuns.net; nanog at nanog.org
Subject: Re: Yet Another BGP (Border Gateway Protocol) Python Implementation

On Thu, 06 Aug 2015 14:25:55 -0000, "Peng Xiao (penxiao)" said:
> Currently, yabgp does not support IPv6 address family. We only support IPv4 now.

http://tnx.nl/legacy-ip-only.svg

Seriously guys.  It's 2015.  We really don't care what you hack for your own use - but publicly announcing stuff that doesn't have IPv6 support is getting kind of embarassing...

*especially* when it's a major vendor open-sourcing their code. (I'm still willing to cut a *little* slack for "two guys and a stack of empty pizza boxes" software....)



From jeff.tantsura at ericsson.com  Fri Aug  7 06:05:46 2015
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Fri, 7 Aug 2015 06:05:46 +0000
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <5A34F4AC18539E47A797E3916C0E55B13584A189@xmb-rcd-x10.cisco.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>,
 <5A34F4AC18539E47A797E3916C0E55B13584A189@xmb-rcd-x10.cisco.com>
Message-ID: <72286A8C-9E89-4F70-9808-2936CA85CDC9@ericsson.com>

Hi Peng,

Good stuff!

Any plans for multicast, RTC and EVPN AF's?

Regards,
Jeff

> On Aug 6, 2015, at 7:43 PM, Peng Xiao (penxiao) <penxiao at cisco.com> wrote:
> 
> Hi guys,
> 
> Ipv6 and other address families are under development. We have already designed the data structures for them as you can see from the documentation, but it's just some testing code and not stable and we are not doing them after careful consideration.
> But at last, they will come out.
> 
> 
> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
> Sent: 2015?8?7? 0:16
> To: Peng Xiao (penxiao)
> Cc: Jahangir Hossain; xxnog at ledeuns.net; nanog at nanog.org
> Subject: Re: Yet Another BGP (Border Gateway Protocol) Python Implementation
> 
> On Thu, 06 Aug 2015 14:25:55 -0000, "Peng Xiao (penxiao)" said:
>> Currently, yabgp does not support IPv6 address family. We only support IPv4 now.
> 
> http://tnx.nl/legacy-ip-only.svg
> 
> Seriously guys.  It's 2015.  We really don't care what you hack for your own use - but publicly announcing stuff that doesn't have IPv6 support is getting kind of embarassing...
> 
> *especially* when it's a major vendor open-sourcing their code. (I'm still willing to cut a *little* slack for "two guys and a stack of empty pizza boxes" software....)
> 
> 

From penxiao at cisco.com  Fri Aug  7 06:15:40 2015
From: penxiao at cisco.com (Peng Xiao (penxiao))
Date: Fri, 7 Aug 2015 06:15:40 +0000
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <72286A8C-9E89-4F70-9808-2936CA85CDC9@ericsson.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>,
 <5A34F4AC18539E47A797E3916C0E55B13584A189@xmb-rcd-x10.cisco.com>
 <72286A8C-9E89-4F70-9808-2936CA85CDC9@ericsson.com>
Message-ID: <5A34F4AC18539E47A797E3916C0E55B13584A2DE@xmb-rcd-x10.cisco.com>

Hi Jeff

As our priority, we will do MPLS VPN, IPv6, Flowspec firstly. In the future, we will consider multicast and EVPN.
Thanks.

-----Original Message-----
From: Jeff Tantsura [mailto:jeff.tantsura at ericsson.com] 
Sent: 2015?8?7? 14:06
To: Peng Xiao (penxiao)
Cc: Valdis.Kletnieks at vt.edu; nanog at nanog.org
Subject: Re: Yet Another BGP (Border Gateway Protocol) Python Implementation

Hi Peng,

Good stuff!

Any plans for multicast, RTC and EVPN AF's?

Regards,
Jeff

> On Aug 6, 2015, at 7:43 PM, Peng Xiao (penxiao) <penxiao at cisco.com> wrote:
> 
> Hi guys,
> 
> Ipv6 and other address families are under development. We have already designed the data structures for them as you can see from the documentation, but it's just some testing code and not stable and we are not doing them after careful consideration.
> But at last, they will come out.
> 
> 
> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
> Sent: 2015?8?7? 0:16
> To: Peng Xiao (penxiao)
> Cc: Jahangir Hossain; xxnog at ledeuns.net; nanog at nanog.org
> Subject: Re: Yet Another BGP (Border Gateway Protocol) Python Implementation
> 
> On Thu, 06 Aug 2015 14:25:55 -0000, "Peng Xiao (penxiao)" said:
>> Currently, yabgp does not support IPv6 address family. We only support IPv4 now.
> 
> http://tnx.nl/legacy-ip-only.svg
> 
> Seriously guys.  It's 2015.  We really don't care what you hack for your own use - but publicly announcing stuff that doesn't have IPv6 support is getting kind of embarassing...
> 
> *especially* when it's a major vendor open-sourcing their code. (I'm still willing to cut a *little* slack for "two guys and a stack of empty pizza boxes" software....)
> 
> 

From bjorn at mork.no  Fri Aug  7 07:10:50 2015
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Fri, 07 Aug 2015 09:10:50 +0200
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <m2vbcsrqgu.wl%randy@psg.com> (Randy Bush's message of "Fri, 07
 Aug 2015 07:40:01 +0900")
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>
 <m2vbcsrqgu.wl%randy@psg.com>
Message-ID: <87bneja805.fsf@nemi.mork.no>

Randy Bush <randy at psg.com> writes:

> perhaps dissing someone for their free code is even ruder than not doing
> ipv6 in 2015?  you don't have to use either.

Definitely.  In any case, one advantage of open sourcing stuff is that
you can always answer such comments with a simple

  "Patches welcome!"

which tends to silence critics :-)


Bj?rn

From pavel.odintsov at gmail.com  Fri Aug  7 09:05:32 2015
From: pavel.odintsov at gmail.com (Pavel Odintsov)
Date: Fri, 7 Aug 2015 12:05:32 +0300
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <87bneja805.fsf@nemi.mork.no>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>
 <m2vbcsrqgu.wl%randy@psg.com> <87bneja805.fsf@nemi.mork.no>
Message-ID: <CALgsdbdAaTFQP-_0YCo9fOM8cLHejJzcPFNeZseiO-6o5xtZ=Q@mail.gmail.com>

Hi!

Thanks for your code! I have used ExaBGP for one year and will try your
tool too!

Do you have any plans about BGP Flow Spec?

On Friday, August 7, 2015, Bj?rn Mork <bjorn at mork.no> wrote:

> Randy Bush <randy at psg.com <javascript:;>> writes:
>
> > perhaps dissing someone for their free code is even ruder than not doing
> > ipv6 in 2015?  you don't have to use either.
>
> Definitely.  In any case, one advantage of open sourcing stuff is that
> you can always answer such comments with a simple
>
>   "Patches welcome!"
>
> which tends to silence critics :-)
>
>
> Bj?rn
>


-- 
Sincerely yours, Pavel Odintsov

From magicsata at gmail.com  Fri Aug  7 09:09:07 2015
From: magicsata at gmail.com (Alistair Mackenzie)
Date: Fri, 7 Aug 2015 10:09:07 +0100
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <CALgsdbdAaTFQP-_0YCo9fOM8cLHejJzcPFNeZseiO-6o5xtZ=Q@mail.gmail.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>
 <m2vbcsrqgu.wl%randy@psg.com> <87bneja805.fsf@nemi.mork.no>
 <CALgsdbdAaTFQP-_0YCo9fOM8cLHejJzcPFNeZseiO-6o5xtZ=Q@mail.gmail.com>
Message-ID: <CA+bbMks8CtTa5oVZxzQsGQc8XYLUHY-zTWevjsoU9v4mWjHFXg@mail.gmail.com>

"As our priority, we will do MPLS VPN, IPv6, *Flowspec* firstly. In the
future, we will consider multicast and EVPN.
Thanks."

On 7 August 2015 at 10:05, Pavel Odintsov <pavel.odintsov at gmail.com> wrote:

> Hi!
>
> Thanks for your code! I have used ExaBGP for one year and will try your
> tool too!
>
> Do you have any plans about BGP Flow Spec?
>
> On Friday, August 7, 2015, Bj?rn Mork <bjorn at mork.no> wrote:
>
> > Randy Bush <randy at psg.com <javascript:;>> writes:
> >
> > > perhaps dissing someone for their free code is even ruder than not
> doing
> > > ipv6 in 2015?  you don't have to use either.
> >
> > Definitely.  In any case, one advantage of open sourcing stuff is that
> > you can always answer such comments with a simple
> >
> >   "Patches welcome!"
> >
> > which tends to silence critics :-)
> >
> >
> > Bj?rn
> >
>
>
> --
> Sincerely yours, Pavel Odintsov
>

From pavel.odintsov at gmail.com  Fri Aug  7 09:14:40 2015
From: pavel.odintsov at gmail.com (Pavel Odintsov)
Date: Fri, 7 Aug 2015 12:14:40 +0300
Subject: Yet Another BGP (Border Gateway Protocol) Python Implementation
In-Reply-To: <CA+bbMks8CtTa5oVZxzQsGQc8XYLUHY-zTWevjsoU9v4mWjHFXg@mail.gmail.com>
References: <5A34F4AC18539E47A797E3916C0E55B13583B631@xmb-rcd-x10.cisco.com>
 <CAB8BFP6rNw-87Wv8KeaFMCoRUMpR0aUrNVZ4vUzNL+2VtO9vEg@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B135842EDD@xmb-rcd-x10.cisco.com>
 <CAB8BFP78NKmsYGSt=RFdLOST5z1g16U82iD+Gi5s_yLknsGSSA@mail.gmail.com>
 <5A34F4AC18539E47A797E3916C0E55B1358453C5@xmb-rcd-x10.cisco.com>
 <54227.1438877767@turing-police.cc.vt.edu>
 <m2vbcsrqgu.wl%randy@psg.com> <87bneja805.fsf@nemi.mork.no>
 <CALgsdbdAaTFQP-_0YCo9fOM8cLHejJzcPFNeZseiO-6o5xtZ=Q@mail.gmail.com>
 <CA+bbMks8CtTa5oVZxzQsGQc8XYLUHY-zTWevjsoU9v4mWjHFXg@mail.gmail.com>
Message-ID: <CALgsdbcKK8t2dvLFG43UR3=pCtzkqRXXwwoLPKfjyMV2uFK3Ng@mail.gmail.com>

Nice!

On Friday, August 7, 2015, Alistair Mackenzie <magicsata at gmail.com> wrote:

> "As our priority, we will do MPLS VPN, IPv6, *Flowspec* firstly. In the
> future, we will consider multicast and EVPN.
> Thanks."
>
> On 7 August 2015 at 10:05, Pavel Odintsov <pavel.odintsov at gmail.com
> <javascript:_e(%7B%7D,'cvml','pavel.odintsov at gmail.com');>> wrote:
>
>> Hi!
>>
>> Thanks for your code! I have used ExaBGP for one year and will try your
>> tool too!
>>
>> Do you have any plans about BGP Flow Spec?
>>
>> On Friday, August 7, 2015, Bj?rn Mork <bjorn at mork.no
>> <javascript:_e(%7B%7D,'cvml','bjorn at mork.no');>> wrote:
>>
>> > Randy Bush <randy at psg.com
>> <javascript:_e(%7B%7D,'cvml','randy at psg.com');> <javascript:;>> writes:
>> >
>> > > perhaps dissing someone for their free code is even ruder than not
>> doing
>> > > ipv6 in 2015?  you don't have to use either.
>> >
>> > Definitely.  In any case, one advantage of open sourcing stuff is that
>> > you can always answer such comments with a simple
>> >
>> >   "Patches welcome!"
>> >
>> > which tends to silence critics :-)
>> >
>> >
>> > Bj?rn
>> >
>>
>>
>> --
>> Sincerely yours, Pavel Odintsov
>>
>
>

-- 
Sincerely yours, Pavel Odintsov

From rdrake at direcpath.com  Fri Aug  7 16:15:24 2015
From: rdrake at direcpath.com (Robert Drake)
Date: Fri, 7 Aug 2015 12:15:24 -0400
Subject: A simple perl script to convert Cisco IOS configuration to HTML
 with internal links for easier comprehension
In-Reply-To: <55C35A2C.3080300@gmail.com>
References: <55C35A2C.3080300@gmail.com>
Message-ID: <55C4D99C.3000504@direcpath.com>

I was going to look at this because it sounded interesting.  Maybe some 
extra things it could do would be to set div/classes in some parts of 
the config to denote what it is so that the user could apply css to 
style it.  That would allow user-defined color syntax highlighting of a 
sort.

Another nice thing would be collapsible sections so if you're only 
interested in BGP you can skip interfaces, or if you want to look at 
route-maps, access-lists, etc.

The project looks a bit disorganized, but I only took a quick glance at 
it so perhaps it does everything exactly as you intend.  Are you 
thinking of making any of it into modules, or defining tests?  I like 
the idea of running this as part of a post-rancid process, but it might 
also be nice if it was a module that could be run in real-time on a 
config.  Then I could have a mojo wrapper daemon that called it when 
users accessed /configs/*-confg, or whatever and returned the parsed 
version.

Anyway, I don't want to create any more work for you, I just wanted to 
kick out some ideas.  If I have time I will contribute what I can, but 
I'm already neck deep in some random projects.  I don't mind starting 
another one, but I don't want to say I'm doing something and then never 
deliver.  :)



From cscora at apnic.net  Fri Aug  7 18:13:45 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 8 Aug 2015 04:13:45 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201508071813.t77IDjKZ027017@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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 08 Aug, 2015

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

Analysis Summary
----------------

BGP routing table entries examined:                              554366
    Prefixes after maximum aggregation (per Origin AS):          209671
    Deaggregation factor:                                          2.64
    Unique aggregates announced (without unneeded subnets):      270945
Total ASes present in the Internet Routing Table:                 51105
    Prefixes per ASN:                                             10.85
Origin-only ASes present in the Internet Routing Table:           36680
Origin ASes announcing only one prefix:                           16160
Transit ASes present in the Internet Routing Table:                6359
Transit-only ASes present in the Internet Routing Table:            173
Average AS path length visible in the Internet Routing Table:       4.5
    Max AS path length visible:                                      45
    Max AS path prepend of ASN ( 55644)                              41
Prefixes from unregistered ASNs in the Routing Table:              1200
    Unregistered ASNs in the Routing Table:                         434
Number of 32-bit ASNs allocated by the RIRs:                      10499
Number of 32-bit ASNs visible in the Routing Table:                8066
Prefixes from 32-bit ASNs in the Routing Table:                   29903
Number of bogon 32-bit ASNs visible in the Routing Table:            16
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            417
Number of addresses announced to Internet:                   2791482880
    Equivalent to 166 /8s, 98 /16s and 166 /24s
    Percentage of available address space announced:               75.4
    Percentage of allocated address space announced:               75.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.6
Total number of prefixes smaller than registry allocations:      185457

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   137012
    Total APNIC prefixes after maximum aggregation:               39879
    APNIC Deaggregation factor:                                    3.44
Prefixes being announced from the APNIC address blocks:          144078
    Unique aggregates announced from the APNIC address blocks:    58813
APNIC Region origin ASes present in the Internet Routing Table:    5080
    APNIC Prefixes per ASN:                                       28.36
APNIC Region origin ASes announcing only one prefix:               1192
APNIC Region transit ASes present in the Internet Routing Table:    883
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         45
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1583
Number of APNIC addresses announced to Internet:              750929984
    Equivalent to 44 /8s, 194 /16s and 72 /24s
    Percentage of available APNIC address space announced:         87.8

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:                    179763
    Total ARIN prefixes after maximum aggregation:                88015
    ARIN Deaggregation factor:                                     2.04
Prefixes being announced from the ARIN address blocks:           182518
    Unique aggregates announced from the ARIN address blocks:     85471
ARIN Region origin ASes present in the Internet Routing Table:    16589
    ARIN Prefixes per ASN:                                        11.00
ARIN Region origin ASes announcing only one prefix:                6080
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:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:     592
Number of ARIN addresses announced to Internet:              1103491328
    Equivalent to 65 /8s, 197 /16s and 241 /24s
    Percentage of available ARIN address space announced:          58.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, 64198-64296, 393216-395164
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:                    134392
    Total RIPE prefixes after maximum aggregation:                67097
    RIPE Deaggregation factor:                                     2.00
Prefixes being announced from the RIPE address blocks:           141073
    Unique aggregates announced from the RIPE address blocks:     87683
RIPE Region origin ASes present in the Internet Routing Table:    17959
    RIPE Prefixes per ASN:                                         7.86
RIPE Region origin ASes announcing only one prefix:                8066
RIPE Region transit ASes present in the Internet Routing Table:    2981
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          34
Number of RIPE region 32-bit ASNs visible in the Routing Table:    3919
Number of RIPE addresses announced to Internet:               698956928
    Equivalent to 41 /8s, 169 /16s and 60 /24s
    Percentage of available RIPE address space announced:         101.6

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-204287
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:                   60822
    Total LACNIC prefixes after maximum aggregation:              11540
    LACNIC Deaggregation factor:                                   5.27
Prefixes being announced from the LACNIC address blocks:          72105
    Unique aggregates announced from the LACNIC address blocks:   33337
LACNIC Region origin ASes present in the Internet Routing Table:   2463
    LACNIC Prefixes per ASN:                                      29.28
LACNIC Region origin ASes announcing only one prefix:               622
LACNIC Region transit ASes present in the Internet Routing Table:   515
Average LACNIC Region AS path length visible:                       5.0
    Max LACNIC Region AS path length visible:                        28
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1833
Number of LACNIC addresses announced to Internet:             168796736
    Equivalent to 10 /8s, 15 /16s and 162 /24s
    Percentage of available LACNIC address space announced:       100.6

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:                  12284
    Total AfriNIC prefixes after maximum aggregation:              3091
    AfriNIC Deaggregation factor:                                  3.97
Prefixes being announced from the AfriNIC address blocks:         14175
    Unique aggregates announced from the AfriNIC address blocks:   5256
AfriNIC Region origin ASes present in the Internet Routing Table:   742
    AfriNIC Prefixes per ASN:                                     19.10
AfriNIC Region origin ASes announcing only one prefix:              200
AfriNIC Region transit ASes present in the Internet Routing Table:  167
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       26
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  139
Number of AfriNIC addresses announced to Internet:             68660224
    Equivalent to 4 /8s, 23 /16s and 172 /24s
    Percentage of available AfriNIC address space announced:       68.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     2991      11300         979   Korea Telecom
17974     2705        904          80   PT Telekomunikasi Indonesia
 7545     2619        339         134   TPG Telecom Limited
 4755     2028        426         225   TATA Communications formerly 
 4538     1949       4190          71   China Education and Research 
 9829     1852       1369         187   National Internet Backbone
 9808     1587       8717          29   Guangdong Mobile Communicatio
 9583     1517        119         570   Sify Limited
 4808     1483       2248         469   CNCGROUP IP network China169 
 9498     1370        335         105   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     3180       2961         138   Cox Communications Inc.
 6389     2734       3688          51   BellSouth.net Inc.
 3356     2557      10710         511   Level 3 Communications, Inc.
18566     2067        381         208   MegaPath Corporation
20115     1873       1847         406   Charter Communications
 6983     1753        851         245   EarthLink, Inc.
 4323     1596       1006         414   tw telecom holdings, inc.
30036     1552        313         480   Mediacom Communications Corp
  701     1406      11376         684   MCI Communications Services, 
22561     1374        415         256   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
20940     2062        814        1492   Akamai International B.V.
34984     2031        305         379   TELLCOM ILETISIM HIZMETLERI A
 6849     1209        355          21   JSC "Ukrtelecom"
 8551     1099        376          52   Bezeq International-Ltd
13188     1068         97          77   TOV "Bank-Inform"
31148     1054         46          24   Freenet Ltd.
12479      976        933          76   France Telecom Espana SA
 8402      936        544          15   OJSC "Vimpelcom"
 6830      921       2696         471   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     3338        538         145   Telmex Colombia S.A.
28573     2300       2173         111   NET Servi?os de Comunica??o S
 8151     1683       3261         486   Uninet S.A. de C.V.
 7303     1601        974         243   Telecom Argentina S.A.
 6147     1388        374          30   Telefonica del Peru S.A.A.
 6503     1247        421          55   Axtel, S.A.B. de C.V.
26615     1105       2325          35   Tim Celular S.A.
 7738      995       1882          41   Telemar Norte Leste S.A.
 3816      947        430         162   COLOMBIA TELECOMUNICACIONES S
11830      924        364          15   Instituto Costarricense de El

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      886        280          26   Link Egypt (Link.NET)
 8452      864       1470          14   TE-AS
36903      512        258          99   Office National des Postes et
36992      442       1229          32   ETISALAT MISR
37492      312        175          71   Orange Tunisie
24835      308        146          12   Vodafone Data
 3741      252        857         208   Internet Solutions
29571      249         21          13   Cote d'Ivoire Telecom
37054      189         20           7   Data Telecom Service
36947      182        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     3338        538         145   Telmex Colombia S.A.
22773     3180       2961         138   Cox Communications Inc.
 4766     2991      11300         979   Korea Telecom
 6389     2734       3688          51   BellSouth.net Inc.
17974     2705        904          80   PT Telekomunikasi Indonesia
 7545     2619        339         134   TPG Telecom Limited
 3356     2557      10710         511   Level 3 Communications, Inc.
39891     2472        128           6   SaudiNet, Saudi Telecom Compa
28573     2300       2173         111   NET Servi?os de Comunica??o S
18566     2067        381         208   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      3180        3042      Cox Communications Inc.
 6389      2734        2683      BellSouth.net Inc.
17974      2705        2625      PT Telekomunikasi Indonesia
 7545      2619        2485      TPG Telecom Limited
39891      2472        2466      SaudiNet, Saudi Telecom Compa
28573      2300        2189      NET Servi?os de Comunica??o S
 3356      2557        2046      Level 3 Communications, Inc.
 4766      2991        2012      Korea Telecom
 4538      1949        1878      China Education and Research 
18566      2067        1859      MegaPath Corporation

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
47092   UNALLOCATED  8.8.204.0/24         16410       The Reynolds and Rey
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
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
55060   UNALLOCATED  8.35.9.0/24           3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          6461       Abovenet Communicati
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.1.0/24        9730     Bharti Telesonic Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.56.0/22       23456     32bit Transition AS
23.226.112.0/20      62788     >>UNKNOWN<<
27.54.116.0/22       23456     32bit Transition AS
27.96.88.0/22        23456     32bit Transition AS
27.100.7.0/24        56096     >>UNKNOWN<<
27.100.24.0/22       23456     32bit Transition AS
27.109.124.0/22      23456     32bit Transition AS
27.111.72.0/22       23456     32bit Transition AS
27.112.120.0/22      23456     32bit Transition AS
27.116.40.0/22       23456     32bit Transition AS

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:17       /9:13      /10:36      /11:96      /12:263     
/13:506     /14:1001    /15:1729    /16:12890   /17:7257    /18:12358   
/19:25551   /20:36046   /21:38803   /22:60636   /23:53091   /24:301015  
/25:1135    /26:1157    /27:712     /28:14      /29:14      /30:9       
/31:0       /32:17      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2432          2472      SaudiNet, Saudi Telecom Compa
22773     2374          3180      Cox Communications Inc.
18566     2009          2067      MegaPath Corporation
 6389     1619          2734      BellSouth.net Inc.
 6983     1399          1753      EarthLink, Inc.
30036     1375          1552      Mediacom Communications Corp
34984     1340          2031      TELLCOM ILETISIM HIZMETLERI A
10620     1208          3338      Telmex Colombia S.A.
11492     1111          1195      CABLE ONE, INC.
22561     1047          1374      CenturyTel Internet Holdings,

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1537      2:698       4:96        5:1857      6:25        8:1383   
  12:1808     13:14       14:1333     15:17       16:2        17:41     
  18:22       20:48       23:1262     24:1758     27:1996     31:1573   
  32:37       33:2        34:4        35:3        36:158      37:2018   
  38:1040     39:14       40:69       41:2800     42:302      43:1401   
  44:30       45:922      46:2346     47:51       49:928      50:784    
  52:15       54:86       55:3        56:6        57:43       58:1350   
  59:716      60:481      61:1754     62:1380     63:1905     64:4433   
  65:2253     66:4030     67:2063     68:1065     69:3242     70:1026   
  71:449      72:1966     74:2588     75:355      76:385      77:1305   
  78:1108     79:811      80:1360     81:1317     82:855      83:719    
  84:794      85:1364     86:447      87:1040     88:531      89:1935   
  90:148      91:5942     92:844      93:2279     94:2060     95:2191   
  96:413      97:347      98:996      99:55      100:75      101:850    
 103:7964    104:2018    105:69      106:341     107:1044    108:625    
 109:2120    110:1157    111:1465    112:821     113:1105    114:844    
 115:1283    116:1457    117:1073    118:1883    119:1463    120:451    
 121:1142    122:2158    123:1848    124:1520    125:1615    128:643    
 129:392     130:419     131:1256    132:526     133:171     134:409    
 135:101     136:334     137:328     138:1073    139:149     140:241    
 141:495     142:663     143:537     144:545     145:126     146:798    
 147:563     148:1237    149:427     150:565     151:674     152:522    
 153:256     154:470     155:880     156:427     157:421     158:358    
 159:1030    160:406     161:665     162:2002    163:444     164:700    
 165:707     166:299     167:853     168:1241    169:190     170:1470   
 171:253     172:284     173:1530    174:720     175:700     176:1432   
 177:3851    178:2161    179:960     180:1940    181:1645    182:1810   
 183:629     184:761     185:4022    186:2914    187:1824    188:2076   
 189:1568    190:7758    191:1123    192:8575    193:5648    194:4211   
 195:3643    196:2015    197:1034    198:5563    199:5500    200:6654   
 201:3305    202:9512    203:9161    204:4681    205:2850    206:3014   
 207:2970    208:3985    209:3909    210:3582    211:1921    212:2551   
 213:2244    214:836     215:73      216:5733    217:1843    218:733    
 219:469     220:1505    221:815     222:473     223:808    

End of report

From jlmcgraw at gmail.com  Fri Aug  7 20:09:52 2015
From: jlmcgraw at gmail.com (Jesse McGraw)
Date: Fri, 07 Aug 2015 16:09:52 -0400
Subject: A simple perl script to convert Cisco IOS configuration to HTML
 with internal links for easier comprehension
In-Reply-To: <55C4D99C.3000504@direcpath.com>
References: <55C35A2C.3080300@gmail.com> <55C4D99C.3000504@direcpath.com>
Message-ID: <55C51090.7080606@gmail.com>

CSS? Tests? Ha ha ha ha ha

This is quick and dirty.

That being said, I'd love to see some tests for it, more advanced HTML 
output, and also make it a module suitable for using as the back-end of 
a web page.  I just wanted to get something basic working for my 
original purposes.

As for disorganized: what you're seeing in that repository is a bunch of 
separate small utilities, it's not all for this one script.  This 
particular script was split out into 4 separate files so the regexes are 
separate from the actual code, otherwise it was a bit too much.

Check it out on your configs and let me know what you think

-Jesse


On 08/07/2015 12:15 PM, Robert Drake wrote:
> I was going to look at this because it sounded interesting.  Maybe 
> some extra things it could do would be to set div/classes in some 
> parts of the config to denote what it is so that the user could apply 
> css to style it.  That would allow user-defined color syntax 
> highlighting of a sort.
>
> Another nice thing would be collapsible sections so if you're only 
> interested in BGP you can skip interfaces, or if you want to look at 
> route-maps, access-lists, etc.
>
> The project looks a bit disorganized, but I only took a quick glance 
> at it so perhaps it does everything exactly as you intend. Are you 
> thinking of making any of it into modules, or defining tests?  I like 
> the idea of running this as part of a post-rancid process, but it 
> might also be nice if it was a module that could be run in real-time 
> on a config.  Then I could have a mojo wrapper daemon that called it 
> when users accessed /configs/*-confg, or whatever and returned the 
> parsed version.
>
> Anyway, I don't want to create any more work for you, I just wanted to 
> kick out some ideas.  If I have time I will contribute what I can, but 
> I'm already neck deep in some random projects.  I don't mind starting 
> another one, but I don't want to say I'm doing something and then 
> never deliver.  :)
>
>
>


From cidr-report at potaroo.net  Fri Aug  7 22:00:00 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 7 Aug 2015 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201508072200.t77M00n5076919@wattle.apnic.net>

This report has been generated at Fri Aug  7 21:14:53 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
        31-07-15    561435      308644
        01-08-15    561684      308740
        02-08-15    561746      308892
        03-08-15    562091      308517
        04-08-15    561867      308741
        05-08-15    562055      308891
        06-08-15    562130      308225
        07-08-15    560808      308901


AS Summary
         51374  Number of ASes in routing system
         20389  Number of ASes announcing only one prefix
          3347  Largest number of prefixes announced by an AS
                AS10620: Telmex Colombia S.A.,CO
      120757504  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').

 --- 07Aug15 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     563102   308981   254121    45.1%   All ASes

AS22773     3183      168     3015    94.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS17974     2705       80     2625    97.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS39891     2473       35     2438    98.6%   ALJAWWALSTC-AS Saudi Telecom
                                               Company JSC,SA
AS28573     2303      118     2185    94.9%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS6389      2734      709     2025    74.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS9394      2285      318     1967    86.1%   CTTNET China TieTong
                                               Telecommunications
                                               Corporation,CN
AS3356      2564      630     1934    75.4%   LEVEL3 - Level 3
                                               Communications, Inc.,US
AS7545      2730      995     1735    63.6%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS10620     3347     1691     1656    49.5%   Telmex Colombia S.A.,CO
AS4766      2991     1448     1543    51.6%   KIXS-AS-KR Korea Telecom,KR
AS9808      1587       65     1522    95.9%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS6983      1752      248     1504    85.8%   ITCDELTA - Earthlink, Inc.,US
AS20115     1873      419     1454    77.6%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS4755      2027      706     1321    65.2%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS9498      1370      114     1256    91.7%   BBIL-AP BHARTI Airtel Ltd.,IN
AS4323      1602      416     1186    74.0%   TWTC - tw telecom holdings,
                                               inc.,US
AS18566     2073      903     1170    56.4%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS6147      1388      281     1107    79.8%   Telefonica del Peru S.A.A.,PE
AS7303      1603      526     1077    67.2%   Telecom Argentina S.A.,AR
AS22561     1374      311     1063    77.4%   CENTURYLINK-LEGACY-LIGHTCORE -
                                               CenturyTel Internet Holdings,
                                               Inc.,US
AS4808      1537      509     1028    66.9%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network,CN
AS7552      1135      140      995    87.7%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS26615     1105      150      955    86.4%   Tim Celular S.A.,BR
AS8151      1686      732      954    56.6%   Uninet S.A. de C.V.,MX
AS7738       995       75      920    92.5%   Telemar Norte Leste S.A.,BR
AS8402       921       21      900    97.7%   CORBINA-AS OJSC "Vimpelcom",RU
AS6849      1206      318      888    73.6%   UKRTELNET JSC UKRTELECOM,UA
AS38285      977      130      847    86.7%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU
AS8551      1191      350      841    70.6%   BEZEQ-INTERNATIONAL-AS Bezeq
                                               International-Ltd,IL
AS55430      857       67      790    92.2%   STARHUBINTERNET-AS-NGNBN
                                               Starhub Internet Pte Ltd,SG

Total      55574    12673    42901    77.2%   Top 30 total


Possible Bogus Routes

        14.1.96.0/19         AS20421 LLC-ASPECT-AS LLC Aspect,RU
        14.102.176.0/20      AS20421 LLC-ASPECT-AS LLC Aspect,RU
        14.192.56.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        23.226.112.0/20      AS62788 -Reserved AS-,ZZ
        27.54.116.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.96.88.0/22        AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.100.7.0/24        AS56096 
        27.100.24.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.109.124.0/22      AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.111.72.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.112.120.0/22      AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.116.40.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.122.60.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        31.217.248.0/21      AS44902 COV-ASN COVAGE NETWORKS SASU,FR
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.3.0/24         AS37004 -Reserved AS-,ZZ
        41.73.4.0/24         AS37004 -Reserved AS-,ZZ
        41.73.5.0/24         AS37004 -Reserved AS-,ZZ
        41.73.6.0/24         AS37004 -Reserved AS-,ZZ
        41.73.7.0/24         AS37004 -Reserved AS-,ZZ
        41.73.8.0/24         AS37004 -Reserved AS-,ZZ
        41.73.9.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.14.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.17.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.126.0/24      AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        41.189.127.0/24      AS37000 -Reserved AS-,ZZ
        41.189.128.0/24      AS37000 -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
        43.246.112.0/20      AS20421 LLC-ASPECT-AS LLC Aspect,RU
        59.152.16.0/20       AS20421 LLC-ASPECT-AS LLC Aspect,RU
        59.152.64.0/20       AS20421 LLC-ASPECT-AS LLC Aspect,RU
        61.14.224.0/19       AS20043 STADIS-LLC-AS LLC Stadis,RU
        64.28.145.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.28.146.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.57.192.0/22       AS33321 -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
        66.11.224.0/21       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.234.0/24       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.236.0/22       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.59.192.0/19       AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.85.10.0/24        AS19381 SIMPLY-BITS-LLC - Simply Bits, LLC,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.228.160.0/20      AS7233  YAHOO-US - Yahoo,US
        66.228.176.0/21      AS17110 YAHOO-US2 - Yahoo,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
        69.24.96.0/20        AS26804 -Reserved AS-,ZZ
        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.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
        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
        100.64.8.0/24        AS10620 Telmex Colombia S.A.,CO
        100.64.11.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.12.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.22.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.23.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.24.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.25.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.26.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.27.0/24       AS10620 Telmex Colombia S.A.,CO
        100.100.1.0/24       AS9730  BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN
        103.1.220.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        103.5.79.0/24        AS20422 LLC-TEHNOKOM-AS LLC Tehnokom,RU
        103.10.222.0/24      AS13189 
        103.11.16.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.13.1.0/24        AS58609 
        103.14.24.0/24       AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.44.0/24       AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID
        103.18.45.0/24       AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID
        103.18.47.0/24       AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID
        103.19.219.0/24      AS58887 
        103.20.100.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.101.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.219.0/24      AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU
        103.22.212.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.23.148.0/23      AS13209 
        103.23.148.0/24      AS13209 
        103.23.149.0/24      AS13209 
        103.25.144.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.37.188.0/22      AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.225.116.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.228.8.0/22       AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.229.152.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.230.124.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.231.36.0/22      AS2519  VECTANT VECTANT Ltd.,JP
        103.231.192.0/22     AS4766  KIXS-AS-KR Korea Telecom,KR
        103.232.104.0/22     AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.232.142.0/23     AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG
        103.232.164.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.233.140.0/23     AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF
        103.234.8.0/22       AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.234.72.0/22      AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.244.112.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.52.0/22      AS2519  VECTANT VECTANT Ltd.,JP
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.196.0/22     AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.249.72.0/22      AS13282 GATEWAY-AS-AP GATEWAY INC,JP
        103.250.220.0/24     AS58973 
        103.250.221.0/24     AS58973 
        103.253.164.0/23     AS13317 
        106.0.32.0/19        AS20043 STADIS-LLC-AS LLC Stadis,RU
        116.12.32.0/21       AS38555 
        116.12.32.0/24       AS38555 
        116.199.200.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.201.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.202.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.203.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.204.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.205.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.206.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.207.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        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
        118.103.160.0/19     AS20043 STADIS-LLC-AS LLC Stadis,RU
        119.42.32.0/19       AS20043 STADIS-LLC-AS LLC Stadis,RU
        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
        163.127.0.0/16       AS20053 RELAX-LLC-AS LLC Relax,RU
        166.93.0.0/16        AS23537 CRITIGEN - Micro Source, Inc.,US
        170.95.0.0/16        AS20055 RUCLICK-AS RU-CLICK LLC,RU
        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
        179.60.128.0/20      AS26317 
        180.222.120.0/21     AS23818 JETINTERNET JETINTERNET Corporation,JP
        181.225.156.0/22     AS10834 Telefonica de Argentina,AR
        185.17.98.0/23       AS19798 HILF-AS Hilf Telecom B.V.,NL
        185.52.57.0/24       AS48039 KGT-AS KGT new media,DE
        185.52.58.0/24       AS48039 KGT-AS KGT new media,DE
        186.148.224.0/21     AS52302 Awknet International, S.A.,PA
        189.14.112.0/20      AS52720 WEBFOCO TELECOMUNICACOES LTDA,BR
        189.14.116.0/22      AS28282 -Reserved AS-,ZZ
        189.14.120.0/22      AS28282 -Reserved AS-,ZZ
        189.14.124.0/22      AS28282 -Reserved AS-,ZZ
        190.112.128.0/19     AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        190.115.64.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        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.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.46.0/23      AS17139 NETRANGE - Corporate Colocation 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.206.140.0/24     AS54926 -Reserved AS-,ZZ
        192.206.141.0/24     AS54926 -Reserved AS-,ZZ
        192.206.142.0/24     AS54926 -Reserved AS-,ZZ
        192.206.143.0/24     AS54926 -Reserved AS-,ZZ
        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.22.224.0/20      AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        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.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.56.203.0/24      AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR
        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.151.160.0/19     AS39906 COPROSYS CoProSys a.s.,CZ
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        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.130.0/24     AS21104 AM-NETSYS-AS Netsys JV LLC,AM
        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.8.0/21       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.9.9.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.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.126.152.0/23     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        194.126.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        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.110.2.0/23       AS25008 ESOO-AS OJSC Rostelecom,RU
        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.180.0/24       AS37004 -Reserved AS-,ZZ
        196.3.181.0/24       AS37004 -Reserved AS-,ZZ
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        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.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.103.89.0/24      AS19523 -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.50.192.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        200.58.248.0/21      AS27849 
        200.59.208.0/20      AS26317 
        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
        200.124.64.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        201.77.5.0/24        AS28650 Lojas Simonetti Ltda,BR
        201.77.7.0/24        AS28650 Lojas Simonetti Ltda,BR
        201.131.5.0/24       AS28389 -Reserved AS-,ZZ
        201.131.88.0/24      AS8151  Uninet S.A. de C.V.,MX
        201.182.0.0/16       AS20055 RUCLICK-AS RU-CLICK LLC,RU
        201.216.64.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        201.216.96.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        201.222.32.0/20      AS20421 LLC-ASPECT-AS LLC Aspect,RU
        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.133.208.0/20     AS17440 IDNIC-ID Indonesia Network Information Center,ID
        202.140.147.0/24     AS9583  SIFY-AS-IN Sify Limited,IN
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom,SG
        202.160.128.0/19     AS20043 STADIS-LLC-AS LLC Stadis,RU
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK
        203.78.130.0/24      AS18222 
        203.142.219.0/24     AS45149 
        203.160.48.0/21      AS38008 
        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.191.160.0/20     AS20421 LLC-ASPECT-AS LLC Aspect,RU
        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.74.12.0/23       AS209   CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.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.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 Aug  7 22:00:01 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 7 Aug 2015 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201508072200.t77M01nT076933@wattle.apnic.net>

BGP Update Report
Interval: 30-Jul-15 -to- 06-Aug-15 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS38197          288888  6.5%     251.0 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK
 2 - AS9829           286617  6.5%     210.4 -- BSNL-NIB National Internet Backbone,IN
 3 - AS16637          234574  5.3%    2039.8 -- MTNNS-AS,ZA
 4 - AS12091          131056  3.0%    2730.3 -- MTNNS-AS,ZA
 5 - AS22059          129571  2.9%   64785.5 -- -Reserved AS-,ZZ
 6 - AS21669          123297  2.8%   123297.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US
 7 - AS11056          119768  2.7%   119768.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US
 8 - AS36947           85482  1.9%    1055.3 -- ALGTEL-AS,DZ
 9 - AS22773           67145  1.5%     177.2 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
10 - AS54169           59907  1.4%   19969.0 -- MGH-ION-1 - Marin General Hospital,US
11 - AS3709            53471  1.2%    1980.4 -- NET-CITY-SA - City of San Antonio,US
12 - AS19429           38885  0.9%      31.6 -- ETB - Colombia,CO
13 - AS24560           38255  0.9%      33.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN
14 - AS7545            36399  0.8%      19.8 -- TPG-INTERNET-AP TPG Telecom Limited,AU
15 - AS25563           34264  0.8%   11421.3 -- WEBLAND-AS Webland AG,CH
16 - AS30295           32571  0.7%   10857.0 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
17 - AS8402            29385  0.7%      99.3 -- CORBINA-AS OJSC "Vimpelcom",RU
18 - AS7552            25573  0.6%      23.1 -- VIETEL-AS-AP Viettel Corporation,VN
19 - AS56636           24024  0.5%   24024.0 -- ASVEDARU VEDA Ltd.,RU
20 - AS131090           23575  0.5%    1178.8 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS21669          123297  2.8%   123297.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US
 2 - AS11056          119768  2.7%   119768.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US
 3 - AS22059          129571  2.9%   64785.5 -- -Reserved AS-,ZZ
 4 - AS56636           24024  0.5%   24024.0 -- ASVEDARU VEDA Ltd.,RU
 5 - AS54169           59907  1.4%   19969.0 -- MGH-ION-1 - Marin General Hospital,US
 6 - AS25563           34264  0.8%   11421.3 -- WEBLAND-AS Webland AG,CH
 7 - AS40493           10920  0.2%   10920.0 -- FACILITYSOURCEINC - FacilitySource,US
 8 - AS30295           32571  0.7%   10857.0 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
 9 - AS393588            9654  0.2%    9654.0 -- MUBEA-FLO - Mubea,US
10 - AS31357           13591  0.3%    6795.5 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
11 - AS47680            6667  0.1%    6667.0 -- NHCS EOBO Limited,IE
12 - AS37590            6061  0.1%    6061.0 -- BCA-ASN,AO
13 - AS59943           22734  0.5%    5683.5 -- RADAR-AS Radar LLC,RU
14 - AS197914            3652  0.1%    3652.0 -- STOCKHO-AS Stockho Hosting SARL,FR
15 - AS38000            6001  0.1%    3000.5 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN
16 - AS37121            8622  0.2%    2874.0 -- ARIVIAKOM,ZA
17 - AS65600           19751  0.5%    2821.6 -- 
18 - AS12091          131056  3.0%    2730.3 -- MTNNS-AS,ZA
19 - AS31668            2401  0.1%    2401.0 -- RAPPAPORT EDV-Dienstleistungen Rappaport GmbH & Co KG,AT
20 - AS196742            4288  0.1%    2144.0 -- EKRAN-AS CJSC "Ekran",RU


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 209.212.8.0/24   123297  2.6%   AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US
 2 - 50.202.59.0/24   119768  2.5%   AS11056 -- BERGERMONTAGUE - Berger & Montague, P.C,US
 3 - 105.96.0.0/22     84282  1.8%   AS36947 -- ALGTEL-AS,DZ
 4 - 64.34.125.0/24    65170  1.4%   AS22059 -- -Reserved AS-,ZZ
 5 - 76.191.107.0/24   64401  1.4%   AS22059 -- -Reserved AS-,ZZ
 6 - 204.80.242.0/24   59901  1.3%   AS54169 -- MGH-ION-1 - Marin General Hospital,US
 7 - 185.65.148.0/24   28066  0.6%   AS197068 -- QRATOR HLL LLC,RU
                                     AS59943 -- RADAR-AS Radar LLC,RU
 8 - 195.128.159.0/24  24024  0.5%   AS56636 -- ASVEDARU VEDA Ltd.,RU
 9 - 61.7.155.0/24     23422  0.5%   AS131090 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
10 - 78.140.0.0/18     13589  0.3%   AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
11 - 92.43.216.0/21    11894  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
12 - 178.174.96.0/19   11482  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
13 - 199.60.236.0/24   11286  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
14 - 130.44.210.0/24   11222  0.2%   AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
15 - 130.44.194.0/24   10985  0.2%   AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
16 - 130.44.10.0/24    10977  0.2%   AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
17 - 130.44.204.0/24   10965  0.2%   AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
18 - 130.44.192.0/24   10941  0.2%   AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
19 - 130.44.1.0/24     10928  0.2%   AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
20 - 8.17.26.0/24      10920  0.2%   AS40493 -- FACILITYSOURCEINC - FacilitySource,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 benc at overthewire.com.au  Fri Aug  7 02:10:14 2015
From: benc at overthewire.com.au (Ben Cornish)
Date: Fri, 7 Aug 2015 02:10:14 +0000
Subject: Super Core Hardware suggestions 
Message-ID: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>

Hey All

We are looking for suggestions for a device to act as a super Core Device / MPLS P router only.
There seems to be plenty of Chassis based solutions out there that also cater for a lot more.
We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only

*         Ideally 16 to 48 ports of 10Gig - SFP

*         Non-blocking line rate capable on all ports.

*         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.

*         Deep buffers on the ports would also be nice

*         With a possible option of 40Gig uplinks..

Thanks

From raphael.timothy at gmail.com  Sat Aug  8 01:46:59 2015
From: raphael.timothy at gmail.com (Tim Raphael)
Date: Sat, 8 Aug 2015 09:46:59 +0800
Subject: Super Core Hardware suggestions
In-Reply-To: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
Message-ID: <B4C05970-982C-4C20-A1F7-9DFDEDB0F496@gmail.com>

The Juniper PTX1000 is worth a look.

http://www.juniper.net/us/en/products-services/routing/ptx-series/ptx1000/

Regards,

Tim Raphael

> On 7 Aug 2015, at 10:10 am, Ben Cornish <benc at overthewire.com.au> wrote:
> 
> Hey All
> 
> We are looking for suggestions for a device to act as a super Core Device / MPLS P router only.
> There seems to be plenty of Chassis based solutions out there that also cater for a lot more.
> We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only
> 
> *         Ideally 16 to 48 ports of 10Gig - SFP
> 
> *         Non-blocking line rate capable on all ports.
> 
> *         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.
> 
> *         Deep buffers on the ports would also be nice
> 
> *         With a possible option of 40Gig uplinks..
> 
> Thanks

From bob at FiberInternetCenter.com  Sat Aug  8 01:52:29 2015
From: bob at FiberInternetCenter.com (Bob Evans)
Date: Fri, 7 Aug 2015 18:52:29 -0700
Subject: Super Core Hardware suggestions
In-Reply-To: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
Message-ID: <8d3a8f4be780765074e113bbefdfc616.squirrel@66.201.44.180>

Alcatel lucent 7750
Thank You
Bob Evans
CTO




> Hey All
>
> We are looking for suggestions for a device to act as a super Core Device
> / MPLS P router only.
> There seems to be plenty of Chassis based solutions out there that also
> cater for a lot more.
> We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only
>
> *         Ideally 16 to 48 ports of 10Gig - SFP
>
> *         Non-blocking line rate capable on all ports.
>
> *         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.
>
> *         Deep buffers on the ports would also be nice
>
> *         With a possible option of 40Gig uplinks..
>
> Thanks
>



From diosbejgli at gmail.com  Sat Aug  8 02:54:12 2015
From: diosbejgli at gmail.com (Andras Toth)
Date: Sat, 8 Aug 2015 12:54:12 +1000
Subject: Strange traceroute result to VM in EC2, Singapore
In-Reply-To: <CAPLq3UP-dDPHH_O=ar3M_yvQjcXtHNK-tTbkXfJX7egtGgchRQ@mail.gmail.com>
References: <CAPLq3UOMgp9qp9z-n-kART+xkE-5jYD27LyjrbxhTyS4uxMNPQ@mail.gmail.com>
 <CAM3TTh18m-6fsSxi_RGzGOOq=CbCu_3Nm=peowtyXWtYkVEw7g@mail.gmail.com>
 <CAPLq3UOOBwKttE8k2fTScd4XFZypVWvOxVKJfq7J7M3HAouoTQ@mail.gmail.com>
 <CAPLq3UMVbrEosXqpkrNKkGw-1XhjNxZ5Buc3u_4oE0qh4uk1uQ@mail.gmail.com>
 <CAPLq3UP-dDPHH_O=ar3M_yvQjcXtHNK-tTbkXfJX7egtGgchRQ@mail.gmail.com>
Message-ID: <CAAtZb4po_Fa37WJy_5Ze8_1rboWMpa4G=K0tVqhoxUfC3csxyw@mail.gmail.com>

Traceroute on Linux/Unix boxes is generally using UDP by default. Try
using ICMP, by adding the -I (capital i) option to traceroute:

traceroute -I 52.74.124.136


On Fri, Aug 7, 2015 at 2:05 AM, Glen Kent <glen.kent at gmail.com> wrote:
> I find this bizzare because even when the traceroute doesnt work, I am
> actually able to ping and access the machine.
>
> I know that the VM responds to traceroutes, since it did respond to my
> traceroute when i was on the other broadband network.
>
> So i really fail to understand why the traceroute on the other network
> failed.
>
> Any pointers on this would be very helpful.
>
> Thanks, GLen
>
> On Thu, Aug 6, 2015 at 8:53 PM, Glen Kent <glen.kent at gmail.com> wrote:
>
>> Really sorry. Didnt realize that this is a text-only forum.
>>
>> When my traceroute to 52.74.124.136 works:
>>
>> ~$ traceroute 52.74.124.136
>> traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
>> 1 xxxxxxx xxxxxxx 0.412 ms 0.472 ms 0.439 ms
>> 2 xxxxxxx xxxxxxx 2.98 ms 2.971 ms 2.999 ms
>> 3 xxxxxxx xxxxxxx 5.345 ms 5.546 ms 5.519 ms
>> 4 xxxxxxx xxxxxxx 3.172 ms 3.051 ms 3.010 ms
>> 5 if-6-2.tcore2.SVW-Singapore.as6543.net (180.87.37.14) 56.751 ms 56.285
>> ms 54.592 ms
>> 6 180.87.15.206 (180.87.15.206) 73.468ms 66.993 ms 66.734 ms
>> 7 203.83.223.58 (203.83.223.58) 43.737 ms 43.513 ms 44.029 ms
>> 8 203.83.223.15 (203.83.223.15) 47.239 ms 46.382 ms 203.83.223.74
>> (203.83.223.74)  44.144 ms
>> 9 203.83.223.231 (203.83.223.231) 44.431 ms 203.83.223.233
>> (203.83.223.233)  45.699 ms 46.158 ms
>> 10 ec2-52-74-124-136.ap-southeast-1.compute.amazon.com (52.74.124.136)
>>  44.067 ms 43.492 ms 43.499 ms
>>
>> When it doesnt:
>>
>> ~$ traceroute 52.74.124.136
>> traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
>> 1 xxxxxxx xxxxxxx 23.272 ms 25.011 ms 26.072 ms
>> 2 xxxxxxx xxxxxxx 27.058 ms 28.971 ms 29.999 ms
>> 3 xxxxxxx xxxxxxx 33.025 ms 33.996 ms 38.822 ms
>> 4 p38895.sgw.equinix.com (202.79.197.87) 78.964 ms 60.051 ms 83.010 ms
>> 5 203.83.223.4 (203.83.223.4) 63.682 ms 64.610 ms 65.837 ms
>> 6 203.83.223.17 (203.83.223.17) 67.271 ms 203.83.223.23 (203.83.223.23)
>> 68.521 ms 203.83.223.17 (203.83.223.17) 70.526 ms
>> 7 203.83.223.233 (203.83.223.233) 71.624 ms 72.805 ms 74.471 ms
>> 8 * * *
>> 9 * * *
>> 10 * * *
>> 11 * * *
>> 12 * * *
>> 13 * * *
>> 14 * * *
>> 15 * * *
>> 16 * * *
>> 17 * * *
>> 18 * * *
>> 19 * * *
>> 20 * * *
>> 21 * * *
>> 22 * * *
>> 23 * * *
>> 24 * * *
>> 25 * * *
>> 26 * * *
>> 27 * * *
>> 28 * * *
>> 29 * * *
>> 30 * * *
>>
>>

From mpetach at netflight.com  Sat Aug  8 08:12:04 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 8 Aug 2015 01:12:04 -0700
Subject: Super Core Hardware suggestions
In-Reply-To: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
Message-ID: <CAEmG1=paxEeTC_kEdaJbLBMsM83TFBNBTV21rOFjR+L+8qh7Mg@mail.gmail.com>

I suspect you might want to look at the QFX10002-36Q series:

http://www.juniper.net/assets/us/en/local/pdf/datasheets/1000531-en.pdf

Matt


On Thu, Aug 6, 2015 at 7:10 PM, Ben Cornish <benc at overthewire.com.au> wrote:
> Hey All
>
> We are looking for suggestions for a device to act as a super Core Device / MPLS P router only.
> There seems to be plenty of Chassis based solutions out there that also cater for a lot more.
> We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only
>
> *         Ideally 16 to 48 ports of 10Gig - SFP
>
> *         Non-blocking line rate capable on all ports.
>
> *         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.
>
> *         Deep buffers on the ports would also be nice
>
> *         With a possible option of 40Gig uplinks..
>
> Thanks
>

From tom at ninjabadger.net  Sat Aug  8 15:15:55 2015
From: tom at ninjabadger.net (Tom Hill)
Date: Sat, 08 Aug 2015 16:15:55 +0100
Subject: Super Core Hardware suggestions
In-Reply-To: <CAEmG1=paxEeTC_kEdaJbLBMsM83TFBNBTV21rOFjR+L+8qh7Mg@mail.gmail.com>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
 <CAEmG1=paxEeTC_kEdaJbLBMsM83TFBNBTV21rOFjR+L+8qh7Mg@mail.gmail.com>
Message-ID: <55C61D2B.4020007@ninjabadger.net>

On 08/08/15 09:12, Matthew Petach wrote:
> I suspect you might want to look at the QFX10002-36Q series:
> 
> http://www.juniper.net/assets/us/en/local/pdf/datasheets/1000531-en.pdf

Also the first thing I thought of - PTX1000 was the other Juniper
option, also mentioned.

Cisco don't have much of a box in this role - I suppose the 6840-X might
suit your requirements, but it's not really targeted at the P function.

-- 
Tom

From darrow at gmail.com  Sat Aug  8 18:38:35 2015
From: darrow at gmail.com (Daren Darrow)
Date: Sat, 8 Aug 2015 11:38:35 -0700
Subject: free Tools to monitor website performance
In-Reply-To: <CAAARkvJGyEjpSRiq2p8C_Meoyz=uTGCGSPbFV0qh5gmZgf+68g@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
 <78C35D6C1A82D243B830523B4193CF5F9F4474A1BA@SBS1.blinker.local>
 <CAAARkvJGyEjpSRiq2p8C_Meoyz=uTGCGSPbFV0qh5gmZgf+68g@mail.gmail.com>
Message-ID: <CAAb54+vLcmnEc5Wyh7npEKwCAtrpmpOnqsfzPgMt-csFj+XmmA@mail.gmail.com>

Pingdom is the most affordable one I've seen recently.  You can try it out
with one URL for free
https://www.pingdom.com/free

It also has some other nice free tools.
http://tools.pingdom.com/fpt/



--
Daren Darrow, darrow at gmail.com

On Thu, Aug 6, 2015 at 12:02 AM, Bryan Tong <contact at nullivex.com> wrote:

> Hello,
>
> We have been using Zabbix with great success on 900 hosts. I would
> recommend it, however I must agree the learning curve can be pretty steep.
> I think of Zabbix more like a piece of networking equipment where it wont
> do anything until everything is configured correctly. It is far from plug
> and play, but very powerful and flexible.
>
> Thanks
>
> On Thu, Aug 6, 2015 at 12:59 AM, David Hofstee <david at mailplus.nl> wrote:
>
> > We use Zabbix for local monitoring. Quite powerful (Nagios crapped out a
> > lot on larger setups, although 300 is not large). There is a learning
> curve
> > for Zabbix.
> >
> > We have a few VPS'es outside our network for DNS reasons. They are
> > configured as (pushing) monitoring nodes too. Bye,
> >
> >
> > David Hofstee
> >
> > Deliverability Management
> > MailPlus B.V. Netherlands (ESP)
> >
> > -----Oorspronkelijk bericht-----
> > Van: NANOG [mailto:nanog-bounces at nanog.org] Namens sathish kumar Ippani
> > Verzonden: Thursday, August 6, 2015 4:24 AM
> > Aan: nanog at nanog.org
> > Onderwerp: free Tools to monitor website performance
> >
> > Hi All,
> >
> > Thanks to all for reviewing my topic, may it is slightly off topic.
> >
> > We have almost 300 URL's (local and web) and we want to monitor few of
> > them which are very critical URL's for web access and local access.
> >
> > I would like to know is there any free tool or software with I can use to
> > monitor url performance in terms of response time. Which gives more
> > information like how much time it taken to connect the server and time to
> > load the page and total response time.
> >
> > Thanks in advance.
> >
> >
> >
> > --
> > With Regards,
> >
> > Sathish Ippani
> >
>
>
>
> --
> eSited LLC
> (701) 390-9638
>

From alejandroacostaalamo at gmail.com  Sat Aug  8 20:24:57 2015
From: alejandroacostaalamo at gmail.com (Alejandro Acosta)
Date: Sat, 8 Aug 2015 15:54:57 -0430
Subject: Measuring DNS Performance & Graphing Logs
In-Reply-To: <CAAgG=jv75ZmnC_ORke-H7G3es0=boReToo7hYBq0v3R9ps5zAQ@mail.gmail.com>
References: <CAAgG=jv75ZmnC_ORke-H7G3es0=boReToo7hYBq0v3R9ps5zAQ@mail.gmail.com>
Message-ID: <55C66599.5050206@gmail.com>

Hello Zayed,
  I noticed you have already received some answers regarding how to
integrate it to Cacti.
  Regarding the tools to measure DNS performance I usually use two:
resperf and dnsperf, both are from Nominum and can be found here:
https://nominum.com/measurement-tools/
  Some years ago I posted this in Spanish: 
http://blog.acostasite.com/2010/02/realizar-estudios-de-performance-sobre.html,
probably it can help you:

Regards,

Alejandro,



El 5/19/2015 a las 1:04 PM, Zayed Mahmud escribi?:
> Hello!
> This is my first message to NANOG's mailing list. I hope someone can help
> me.
>
> I was wondering which tool(s) can I use to measure the performance of my 3
> DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I
> would like to know if my DNS server is serving as it should be or if any of
> it's options are set inappropriately and others alike.
>
> I looked for a while but could not find any. Any help would be highly
> appreciated. I am running bind9 on UNIX platform.
>
> Question 2) I would also like to know how can I graph my DNS logs? And how
> can I integrate it to my CACTI server as well? I couldn't find any suitable
> plugin. Any suggestion?
>


From chaim.rieger at gmail.com  Sun Aug  9 02:56:03 2015
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Sat, 08 Aug 2015 19:56:03 -0700
Subject: free Tools to monitor website performance
In-Reply-To: <CAAb54+vLcmnEc5Wyh7npEKwCAtrpmpOnqsfzPgMt-csFj+XmmA@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
 <78C35D6C1A82D243B830523B4193CF5F9F4474A1BA@SBS1.blinker.local>
 <CAAARkvJGyEjpSRiq2p8C_Meoyz=uTGCGSPbFV0qh5gmZgf+68g@mail.gmail.com>
 <CAAb54+vLcmnEc5Wyh7npEKwCAtrpmpOnqsfzPgMt-csFj+XmmA@mail.gmail.com>
Message-ID: <55C6C143.1080502@gmail.com>

I think that Apica might have a free option as well. (www.apicasystem.com)



On 08/08/2015 11:38 AM, Daren Darrow wrote:
> Pingdom is the most affordable one I've seen recently.  You can try it out
> with one URL for free
> https://www.pingdom.com/free
>
> It also has some other nice free tools.
> http://tools.pingdom.com/fpt/
>
>
>
> --
> Daren Darrow, darrow at gmail.com
>
> On Thu, Aug 6, 2015 at 12:02 AM, Bryan Tong <contact at nullivex.com> wrote:
>
>> Hello,
>>
>> We have been using Zabbix with great success on 900 hosts. I would
>> recommend it, however I must agree the learning curve can be pretty steep.
>> I think of Zabbix more like a piece of networking equipment where it wont
>> do anything until everything is configured correctly. It is far from plug
>> and play, but very powerful and flexible.
>>
>> Thanks
>>
>> On Thu, Aug 6, 2015 at 12:59 AM, David Hofstee <david at mailplus.nl> wrote:
>>
>>> We use Zabbix for local monitoring. Quite powerful (Nagios crapped out a
>>> lot on larger setups, although 300 is not large). There is a learning
>> curve
>>> for Zabbix.
>>>
>>> We have a few VPS'es outside our network for DNS reasons. They are
>>> configured as (pushing) monitoring nodes too. Bye,
>>>
>>>
>>> David Hofstee
>>>
>>> Deliverability Management
>>> MailPlus B.V. Netherlands (ESP)
>>>
>>> -----Oorspronkelijk bericht-----
>>> Van: NANOG [mailto:nanog-bounces at nanog.org] Namens sathish kumar Ippani
>>> Verzonden: Thursday, August 6, 2015 4:24 AM
>>> Aan: nanog at nanog.org
>>> Onderwerp: free Tools to monitor website performance
>>>
>>> Hi All,
>>>
>>> Thanks to all for reviewing my topic, may it is slightly off topic.
>>>
>>> We have almost 300 URL's (local and web) and we want to monitor few of
>>> them which are very critical URL's for web access and local access.
>>>
>>> I would like to know is there any free tool or software with I can use to
>>> monitor url performance in terms of response time. Which gives more
>>> information like how much time it taken to connect the server and time to
>>> load the page and total response time.
>>>
>>> Thanks in advance.
>>>
>>>
>>>
>>> --
>>> With Regards,
>>>
>>> Sathish Ippani
>>>
>>
>>
>> --
>> eSited LLC
>> (701) 390-9638
>>


From excelsio at gmx.com  Sun Aug  9 08:52:11 2015
From: excelsio at gmx.com (Michael)
Date: Sun, 09 Aug 2015 10:52:11 +0200
Subject: Super Core Hardware suggestions
In-Reply-To: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
Message-ID: <55C714BB.40005@gmx.com>

Hello,

we?re using H3C S5820v2 (== HP 5900AF) switches for our 10Gbe servers, 
as HP won the public tender:

- 1RU
- Broadcom Trident I ASIC
- 48x 10Gbe SFP+, 4x40GbE QSFP+
- NO deep buffer (on that specific switch)
- The switch itself is inexpensive, but
- NO HP lifetime warranty. We need hardware carepacks and also purchased 
software carepacks, but
- even with a software carepack, it?s unfortunately not possible to get 
bugs fixed for years (for some older H3C device).
- We?re running OSPF+BFD, OSPFv3+BFD. (According to the datasheet, they 
can do ISIS+ISISv6 + MPLS, too - Never tested on those)
- NO "In Service Software Upgrade? (ISSU), also not on HP?s bigger 
modular switches with redundant fabrics. As soon you have a software 
upgrade, you?re lost. If HP tells you something about "ISSU", that?s 
only for some hot patches, but I have seen only 1 within the last year 
for all of our HP/H3C devices.
- HP optics are quite expensive. But you could actually put every other 
vendor coded SFP module in it (for now) and it works. (Yes it will warn 
you within logging)
- If you need higher quantities talk to your HP representative. Cisco is 
not the only vendor that can give 70% off price list...

Btw, if I were allowed to buy something else, I?d go for Juniper...

Regards
Michael



Am 07.08.2015 um 04:10 schrieb Ben Cornish:
> Hey All
>
> We are looking for suggestions for a device to act as a super Core Device / MPLS P router only.
> There seems to be plenty of Chassis based solutions out there that also cater for a lot more.
> We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only
>
> *         Ideally 16 to 48 ports of 10Gig - SFP
>
> *         Non-blocking line rate capable on all ports.
>
> *         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.
>
> *         Deep buffers on the ports would also be nice
>
> *         With a possible option of 40Gig uplinks..
>
> Thanks


From bedard.phil at gmail.com  Sun Aug  9 13:04:08 2015
From: bedard.phil at gmail.com (Phil Bedard)
Date: Sun, 9 Aug 2015 09:04:08 -0400
Subject: Super Core Hardware suggestions
In-Reply-To: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
Message-ID: <55c74fec.d432810a.fb587.ffffe904@mx.google.com>

Do you need redundant control plane cards?  That's usually what pushes a device beyond the 2RU point.  If you do you could look at the ASR9004 or MX240,those are above your 2RU limit though.  

The PTX1000 or QFX10K or even the QFX5100 might work fine.  You aren't going to find deep buffers in those boxes though.  Brocade may also be an option.  

Phil

-----Original Message-----
From: "Ben Cornish" <benc at overthewire.com.au>
Sent: ?8/?7/?2015 9:13 PM
To: "North American Network Operators' Group" <nanog at nanog.org>
Subject: Super Core Hardware suggestions

Hey All

We are looking for suggestions for a device to act as a super Core Device / MPLS P router only.
There seems to be plenty of Chassis based solutions out there that also cater for a lot more.
We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only

*         Ideally 16 to 48 ports of 10Gig - SFP

*         Non-blocking line rate capable on all ports.

*         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.

*         Deep buffers on the ports would also be nice

*         With a possible option of 40Gig uplinks..

Thanks

From dustin at rseng.net  Mon Aug 10 00:32:41 2015
From: dustin at rseng.net (Dustin Jurman)
Date: Mon, 10 Aug 2015 00:32:41 +0000
Subject: Measuring DNS Performance & Graphing Logs
In-Reply-To: <55C66599.5050206@gmail.com>
References: <CAAgG=jv75ZmnC_ORke-H7G3es0=boReToo7hYBq0v3R9ps5zAQ@mail.gmail.com>
 <55C66599.5050206@gmail.com>
Message-ID: <D512B70CB42ED047A05A7AC11DF0C9C8B814391A@Westshore-EX1.rseng.net>

There is also a windows utility from Steve Gibson. 

https://www.grc.com/dns/benchmark.htm

Dustin 

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alejandro Acosta
Sent: Saturday, August 8, 2015 4:25 PM
To: nanog at nanog.org
Subject: Re: Measuring DNS Performance & Graphing Logs

Hello Zayed,
  I noticed you have already received some answers regarding how to integrate it to Cacti.
  Regarding the tools to measure DNS performance I usually use two:
resperf and dnsperf, both are from Nominum and can be found here:
https://nominum.com/measurement-tools/
  Some years ago I posted this in Spanish: 
http://blog.acostasite.com/2010/02/realizar-estudios-de-performance-sobre.html,
probably it can help you:

Regards,

Alejandro,



El 5/19/2015 a las 1:04 PM, Zayed Mahmud escribi?:
> Hello!
> This is my first message to NANOG's mailing list. I hope someone can 
> help me.
>
> I was wondering which tool(s) can I use to measure the performance of 
> my 3 DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the 
> stats I would like to know if my DNS server is serving as it should be 
> or if any of it's options are set inappropriately and others alike.
>
> I looked for a while but could not find any. Any help would be highly 
> appreciated. I am running bind9 on UNIX platform.
>
> Question 2) I would also like to know how can I graph my DNS logs? And 
> how can I integrate it to my CACTI server as well? I couldn't find any 
> suitable plugin. Any suggestion?
>



From fakrulalam at gmail.com  Mon Aug 10 11:09:03 2015
From: fakrulalam at gmail.com (Fakrul Alam Pappu)
Date: Mon, 10 Aug 2015 16:39:03 +0530
Subject: Measuring DNS Performance & Graphing Logs
In-Reply-To: <D512B70CB42ED047A05A7AC11DF0C9C8B814391A@Westshore-EX1.rseng.net>
References: <CAAgG=jv75ZmnC_ORke-H7G3es0=boReToo7hYBq0v3R9ps5zAQ@mail.gmail.com>
 <55C66599.5050206@gmail.com>
 <D512B70CB42ED047A05A7AC11DF0C9C8B814391A@Westshore-EX1.rseng.net>
Message-ID: <CAARHE5GuHdqvV9oTh+W1SgeqHbY2pdgMaFLfckVm+jd8=f26Ww@mail.gmail.com>

You can also try librenms (http://www.librenms.org/) which has associated
agent to monitor bind (
http://librenms.readthedocs.org/Extensions/Agent-Setup/index.html?highlight=bind
)

On Mon, Aug 10, 2015 at 6:02 AM, Dustin Jurman <dustin at rseng.net> wrote:

> There is also a windows utility from Steve Gibson.
>
> https://www.grc.com/dns/benchmark.htm
>
> Dustin
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alejandro Acosta
> Sent: Saturday, August 8, 2015 4:25 PM
> To: nanog at nanog.org
> Subject: Re: Measuring DNS Performance & Graphing Logs
>
> Hello Zayed,
>   I noticed you have already received some answers regarding how to
> integrate it to Cacti.
>   Regarding the tools to measure DNS performance I usually use two:
> resperf and dnsperf, both are from Nominum and can be found here:
> https://nominum.com/measurement-tools/
>   Some years ago I posted this in Spanish:
>
> http://blog.acostasite.com/2010/02/realizar-estudios-de-performance-sobre.html
> ,
> probably it can help you:
>
> Regards,
>
> Alejandro,
>
>
>
> El 5/19/2015 a las 1:04 PM, Zayed Mahmud escribi?:
> > Hello!
> > This is my first message to NANOG's mailing list. I hope someone can
> > help me.
> >
> > I was wondering which tool(s) can I use to measure the performance of
> > my 3 DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the
> > stats I would like to know if my DNS server is serving as it should be
> > or if any of it's options are set inappropriately and others alike.
> >
> > I looked for a while but could not find any. Any help would be highly
> > appreciated. I am running bind9 on UNIX platform.
> >
> > Question 2) I would also like to know how can I graph my DNS logs? And
> > how can I integrate it to my CACTI server as well? I couldn't find any
> > suitable plugin. Any suggestion?
> >
>
>
>

From marcel.duregards at yahoo.fr  Mon Aug 10 06:58:05 2015
From: marcel.duregards at yahoo.fr (Marcel Duregards)
Date: Mon, 10 Aug 2015 06:58:05 +0000 (UTC)
Subject: Experience on Wanguard for 'anti' DDOS solutions
Message-ID: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>

Dear Nogers,
We are currently evaluating some DDOS detection/mitigation solutions.
Do you have any inputs/experiences on Wanguard from Andrisoft, please ?https://www.andrisoft.com/software/wanguard
Currently we are just interested on the packets/flows sensors with the console for detection and RTBH trigger. Maybe the packet filtering (for scrubbing) will come later.
Best Regards,-Marcel Duregards




From pavel.odintsov at gmail.com  Mon Aug 10 13:38:40 2015
From: pavel.odintsov at gmail.com (Pavel Odintsov)
Date: Mon, 10 Aug 2015 16:38:40 +0300
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>

Hello!

We have some open source software for this task
https://github.com/FastVPSEestiOu/fastnetmon :) Feel free to ask me
any questions off list.

On Mon, Aug 10, 2015 at 9:58 AM, Marcel Duregards
<marcel.duregards at yahoo.fr> wrote:
> Dear Nogers,
> We are currently evaluating some DDOS detection/mitigation solutions.
> Do you have any inputs/experiences on Wanguard from Andrisoft, please ?https://www.andrisoft.com/software/wanguard
> Currently we are just interested on the packets/flows sensors with the console for detection and RTBH trigger. Maybe the packet filtering (for scrubbing) will come later.
> Best Regards,-Marcel Duregards
>
>
>



-- 
Sincerely yours, Pavel Odintsov

From blair.trosper at gmail.com  Mon Aug 10 13:45:11 2015
From: blair.trosper at gmail.com (Blair Trosper)
Date: Mon, 10 Aug 2015 08:45:11 -0500
Subject: Zayo/AboveNet
Message-ID: <CAA5Ek4c2LbD4tfZ_WL5kqT8an6mEzPgh7pO=KzMc3xDVY7ebBA@mail.gmail.com>

Anyone know why Zayo still hasn't renamed the BGP AS network names for all
the AboveNet ASNs?

Not to poke fun at Global Crossing, but they changed Level 3's AS name in
less time (which, if I recall, took over a year to happen...)

I don't see Zayo using the Above.net brand anywhere lately...honest
question.  I know small details like the name of your AS can slip through
the cracks in an acquisition THREE YEARS AGO <http://www.zayo.com/abovenet>,
but still...it's been a while...

http://bgp.he.net/AS6461

From woody at pch.net  Mon Aug 10 13:57:21 2015
From: woody at pch.net (Bill Woodcock)
Date: Mon, 10 Aug 2015 08:57:21 -0500
Subject: Zayo/AboveNet
In-Reply-To: <CAA5Ek4c2LbD4tfZ_WL5kqT8an6mEzPgh7pO=KzMc3xDVY7ebBA@mail.gmail.com>
References: <CAA5Ek4c2LbD4tfZ_WL5kqT8an6mEzPgh7pO=KzMc3xDVY7ebBA@mail.gmail.com>
Message-ID: <5AE1536B-934D-4D3F-9047-4E7A2BD4953E@pch.net>


> On Aug 10, 2015, at 8:45 AM, Blair Trosper <blair.trosper at gmail.com> wrote:
> 
> Anyone know why Zayo still hasn't renamed the BGP AS network names for all
> the AboveNet ASNs?

They don?t want to disrupt their Alternet peering sessions.

                                -Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150810/58b4a2c9/attachment.pgp>

From blair.trosper at gmail.com  Mon Aug 10 14:08:16 2015
From: blair.trosper at gmail.com (Blair Trosper)
Date: Mon, 10 Aug 2015 09:08:16 -0500
Subject: Zayo/AboveNet
In-Reply-To: <5AE1536B-934D-4D3F-9047-4E7A2BD4953E@pch.net>
References: <CAA5Ek4c2LbD4tfZ_WL5kqT8an6mEzPgh7pO=KzMc3xDVY7ebBA@mail.gmail.com>
 <5AE1536B-934D-4D3F-9047-4E7A2BD4953E@pch.net>
Message-ID: <CAA5Ek4fu+t_dbnHMDS88R7zb=mFGYu+AUcreyKBUOrYse87aYw@mail.gmail.com>

UUNet would have been 40% funnier.  (I rounded up from 39.975%)

On Mon, Aug 10, 2015 at 8:57 AM, Bill Woodcock <woody at pch.net> wrote:

>
> > On Aug 10, 2015, at 8:45 AM, Blair Trosper <blair.trosper at gmail.com>
> wrote:
> >
> > Anyone know why Zayo still hasn't renamed the BGP AS network names for
> all
> > the AboveNet ASNs?
>
> They don?t want to disrupt their Alternet peering sessions.
>
>                                 -Bill
>
>
>
>
>

From job at instituut.net  Mon Aug 10 14:10:14 2015
From: job at instituut.net (Job Snijders)
Date: Mon, 10 Aug 2015 16:10:14 +0200
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
Message-ID: <20150810141014.GP30897@Vurt.local>

On Mon, Aug 10, 2015 at 04:38:40PM +0300, Pavel Odintsov wrote:
> We have some open source software for this task
> https://github.com/FastVPSEestiOu/fastnetmon :) Feel free to ask me
> any questions off list.

I can attest that fastnetmon is a great tool for dealing with high pps
or high bandwidth attacks. Pavel thank you so much for sharing this!

Yesterday I deployed fastnetmon at a small non-profit ISP in Amsterdam
(AS8283). From the start of the attack to actually dealing with it by
announcing blackhole route plus /24 wrapper (to draw traffic via that
upstream), only takes four seconds.

Kind regards,

Job

From jlmcgraw at gmail.com  Mon Aug 10 15:55:18 2015
From: jlmcgraw at gmail.com (Jesse McGraw)
Date: Mon, 10 Aug 2015 11:55:18 -0400
Subject: A simple perl script to convert Cisco IOS configuration to HTML
 with internal links for easier comprehension
In-Reply-To: <55C35A2C.3080300@gmail.com>
References: <55C35A2C.3080300@gmail.com>
Message-ID: <55C8C966.8090103@gmail.com>

All,
   I've started adding the ability to link between files (e.g. BGP 
neighbor statements, assuming you have both configuration files)

I'd be very interested to hear anyone's feedback if they've gotten the 
script to work or have some ideas for improvements like Robert suggested

Thanks,
   -Jesse

On 08/06/2015 08:59 AM, Jesse McGraw wrote:
> All,
>
>     (This is me scratching an itch of my own and hoping that it might 
> be useful to others on this list.  Apologies if it isn't)
>
>   When trying to comprehend a new or complicated Cisco router 
> configuration an old pet-peeve of mine is how needlessly difficult it 
> is to search for a list referenced by a command, figure out what it 
> does, then find my way back to the original command (by which time 
> I?ve forgotten the details of the list) and figure out what it's doing 
> with that list.
>
> So I?ve been working on a small perl script to add links within IOS 
> configuration files, e.g. link to an access-list from the interface 
> where it?s applied, making it easier to to follow the chain of logic 
> with stuff like route maps or nested service policies via clicking 
> links and using the forward and back buttons in your browser to go 
> back and forth between command and referenced list.
>
> I know there is a lot of stuff I could add in to this (e.g. more 
> VRF-related commands, PIX/ASA, Juniper etc).  Let me know if you think 
> of anything new or notice something I?ve done wrong , there's plenty 
> of room for improvement and expansion to other configuration formats.
>
>
>
> Notes:
>     Anything referenced (or potentially referenced) by something else 
> is in bold.  It makes it very easy to see where ACLs etc. start and end
>
>     There's also an option in there to reformat some numbers that are 
> hard to read (e.g. traffic shaping criteria) into more human-readable 
> ones.  Pure fluff.
>
>     Surely this has been done before but I couldn't find anything in a 
> few brief moments of searching so here we are.
>
>
>
> Files are here: https://github.com/jlmcgraw/networkUtilities
>
> At the very least you'll need iosToHtml.pl, pointers.pl, pointees.pl, 
> and human_readable.pl and several CPAN modules (see setup.sh for easy 
> ways to install them under Debian-derived Linux. I haven't tested this 
> at all under Windows or OS X)
>
> -Jesse


From math at sizone.org  Mon Aug 10 17:43:21 2015
From: math at sizone.org (Ken Chase)
Date: Mon, 10 Aug 2015 13:43:21 -0400
Subject: AT&T att.net postmaster contact needed
Message-ID: <20150810174321.GB6648@sizone.org>


please reply offlist, mutual customer issue.

/kc
-- 
Ken Chase - math at sizone.org Toronto Canada

From holbor at sonss.net  Mon Aug 10 17:58:48 2015
From: holbor at sonss.net (Richard Holbo)
Date: Mon, 10 Aug 2015 10:58:48 -0700
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAFiN6ro3XY+CD4V2HG5eSxTNKKLPKktgxKdHbwY7n5UeiRkBCA@mail.gmail.com>

We are currently using Wanguard.  Have had it in place for about 6months.
Have not setup BGP peering with my edges to blackhole inbound traffic yet
simply because I haven't had time, but the product itself seems to be
pretty full featured and has lots of options and a pretty reasonable
interface.  I've got two netflow sensors running against Huawei NE40
routers with full routes.  For now (I get two or three 2G+ DDOS a month)
it's been enough to see the alert and manually blackhole it .

Getting ahold of support can be a bit of a chore, but they do respond, and
the manual is good.

Have you setup the Demo yet?

/rh

On Sun, Aug 9, 2015 at 11:58 PM, Marcel Duregards <marcel.duregards at yahoo.fr
> wrote:

> Dear Nogers,
> We are currently evaluating some DDOS detection/mitigation solutions.
> Do you have any inputs/experiences on Wanguard from Andrisoft, please ?
> https://www.andrisoft.com/software/wanguard
> Currently we are just interested on the packets/flows sensors with the
> console for detection and RTBH trigger. Maybe the packet filtering (for
> scrubbing) will come later.
> Best Regards,-Marcel Duregards
>
>
>
>

From stl at wiredrive.com  Mon Aug 10 21:05:14 2015
From: stl at wiredrive.com (Scott Larson)
Date: Mon, 10 Aug 2015 14:05:14 -0700
Subject: Super Core Hardware suggestions
In-Reply-To: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
Message-ID: <CAFt8naHXk=8Rwj8zu0RbAJ7CUUKH=X33gMZRsYoL-ujMtD+skg@mail.gmail.com>

     I'm in the same boat myself. One thing I can share is Juniper really
doesn't want to talk about the PTX1000 at all right now as it's not due to
be available until November. They're going to suggest you look at the
MX240/480 instead.


*[image: userimage]Scott Larson[image: los angeles]
<https://www.google.com/maps/place/4216+Glencoe+Ave,+Marina+Del+Rey,+CA+90292/@33.9892151,-118.4421334,17z/data=!3m1!4b1!4m2!3m1!1s0x80c2ba88ffae914d:0x14e1d00084d4d09c>Lead
Systems Administrator[image: wdlogo] <https://www.wiredrive.com/> [image:
linkedin] <https://www.linkedin.com/company/wiredrive> [image: facebook]
<https://www.twitter.com/wiredrive> [image: twitter]
<https://www.facebook.com/wiredrive> [image: instagram]
<https://www.instagram.com/wiredrive>T 310 823 8238 x1106
<310%20823%208238%20x1106>  |  M 310 904 8818 <310%20904%208818>*

On Thu, Aug 6, 2015 at 7:10 PM, Ben Cornish <benc at overthewire.com.au> wrote:

> Hey All
>
> We are looking for suggestions for a device to act as a super Core Device
> / MPLS P router only.
> There seems to be plenty of Chassis based solutions out there that also
> cater for a lot more.
> We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only
>
> *         Ideally 16 to 48 ports of 10Gig - SFP
>
> *         Non-blocking line rate capable on all ports.
>
> *         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.
>
> *         Deep buffers on the ports would also be nice
>
> *         With a possible option of 40Gig uplinks..
>
> Thanks
>

From matt at spectrum.com.au  Mon Aug 10 23:11:53 2015
From: matt at spectrum.com.au (Matt Perkins)
Date: Tue, 11 Aug 2015 09:11:53 +1000
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <20150810141014.GP30897@Vurt.local>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local>
Message-ID: <55C92FB9.10402@spectrum.com.au>

+1

On 11/08/2015 12:10 AM, Job Snijders wrote:
> On Mon, Aug 10, 2015 at 04:38:40PM +0300, Pavel Odintsov wrote:
>> We have some open source software for this task
>> https://github.com/FastVPSEestiOu/fastnetmon :) Feel free to ask me
>> any questions off list.
> I can attest that fastnetmon is a great tool for dealing with high pps
> or high bandwidth attacks. Pavel thank you so much for sharing this!
>
> Yesterday I deployed fastnetmon at a small non-profit ISP in Amsterdam
> (AS8283). From the start of the attack to actually dealing with it by
> announcing blackhole route plus /24 wrapper (to draw traffic via that
> upstream), only takes four seconds.
>
> Kind regards,
>
> Job


-- 
/* 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 web at typo.org  Mon Aug 10 23:29:44 2015
From: web at typo.org (Wayne E Bouchard)
Date: Mon, 10 Aug 2015 16:29:44 -0700
Subject: Zayo/AboveNet
In-Reply-To: <CAA5Ek4fu+t_dbnHMDS88R7zb=mFGYu+AUcreyKBUOrYse87aYw@mail.gmail.com>
References: <CAA5Ek4c2LbD4tfZ_WL5kqT8an6mEzPgh7pO=KzMc3xDVY7ebBA@mail.gmail.com>
 <5AE1536B-934D-4D3F-9047-4E7A2BD4953E@pch.net>
 <CAA5Ek4fu+t_dbnHMDS88R7zb=mFGYu+AUcreyKBUOrYse87aYw@mail.gmail.com>
Message-ID: <20150810232944.GA29120@wakko.typo.org>

ASNumber:       701 - 705
ASName:         UUNET
ASHandle:       AS701
RegDate:        1990-08-03
Updated:        2012-03-20
Ref:            http://whois.arin.net/rest/asn/AS701

Although not having been updated yet makes it one of the older
registry entries, having just passed 25 years..

On Mon, Aug 10, 2015 at 09:08:16AM -0500, Blair Trosper wrote:
> UUNet would have been 40% funnier.  (I rounded up from 39.975%)
> 
> On Mon, Aug 10, 2015 at 8:57 AM, Bill Woodcock <woody at pch.net> wrote:
> 
> >
> > > On Aug 10, 2015, at 8:45 AM, Blair Trosper <blair.trosper at gmail.com>
> > wrote:
> > >
> > > Anyone know why Zayo still hasn't renamed the BGP AS network names for
> > all
> > > the AboveNet ASNs?
> >
> > They don???t want to disrupt their Alternet peering sessions.
> >
> >                                 -Bill
> >
> >
> >
> >
> >

---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/

From woody at pch.net  Mon Aug 10 23:38:25 2015
From: woody at pch.net (Bill Woodcock)
Date: Mon, 10 Aug 2015 18:38:25 -0500
Subject: Zayo/AboveNet
In-Reply-To: <20150810232944.GA29120@wakko.typo.org>
References: <CAA5Ek4c2LbD4tfZ_WL5kqT8an6mEzPgh7pO=KzMc3xDVY7ebBA@mail.gmail.com>
 <5AE1536B-934D-4D3F-9047-4E7A2BD4953E@pch.net>
 <CAA5Ek4fu+t_dbnHMDS88R7zb=mFGYu+AUcreyKBUOrYse87aYw@mail.gmail.com>
 <20150810232944.GA29120@wakko.typo.org>
Message-ID: <8D636EEA-85FF-42DE-AA5B-6B3CA0E92619@pch.net>


> On Aug 10, 2015, at 6:29 PM, Wayne E Bouchard <web at typo.org> wrote:
> 
> ASNumber:       701 - 705
> ASName:         UUNET
> ASHandle:       AS701
> RegDate:        1990-08-03
> Updated:        2012-03-20
> Ref:            http://whois.arin.net/rest/asn/AS701
> 
> Although not having been updated yet makes it one of the older
> registry entries, having just passed 25 years..

Yes, alternet only appears in their in-addrs, last I knew.

                                -Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150810/28021c04/attachment.pgp>

From nick.pratley at serversaustralia.com.au  Mon Aug 10 23:36:07 2015
From: nick.pratley at serversaustralia.com.au (Nick Pratley)
Date: Tue, 11 Aug 2015 09:36:07 +1000
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <55C92FB9.10402@spectrum.com.au>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local>
 <55C92FB9.10402@spectrum.com.au>
Message-ID: <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>

+1 from me for WanGuard.

I have this running taking 2x 10G span ports of our network. We are able to
mitigate an attack within 7 seconds (local filtering where transit can
handle) and if it gets to the point that transit can not handle the attack
it moves the /24 related to the attack to a DDoS mitigation cloud.

Once setup correctly. very good product - it's been running for 8 months
now and hasn't had any issues. It's been very reliable.

Richard, I have always found their support team to be great. If I put a
ticket in it's always replied to by the time I wake up. Time Zone is the
killer here being over in .au.

Regards,
Nick

From mtaylor at mty.net.au  Mon Aug 10 23:55:40 2015
From: mtaylor at mty.net.au (Matt Taylor)
Date: Tue, 11 Aug 2015 09:55:40 +1000
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
Message-ID: <55C939FC.3090002@mty.net.au>

We (AS55803) have also been using WANGuard for well over a year, and as 
with the other comments.. it has been very reliable and integrates quite 
well with literally anything you want.

Regards,
Matt.

On 11/08/2015 09:36, Nick Pratley wrote:
> +1 from me for WanGuard.
>
> I have this running taking 2x 10G span ports of our network. We are able to
> mitigate an attack within 7 seconds (local filtering where transit can
> handle) and if it gets to the point that transit can not handle the attack
> it moves the /24 related to the attack to a DDoS mitigation cloud.
>
> Once setup correctly. very good product - it's been running for 8 months
> now and hasn't had any issues. It's been very reliable.
>
> Richard, I have always found their support team to be great. If I put a
> ticket in it's always replied to by the time I wake up. Time Zone is the
> killer here being over in .au.
>
> Regards,
> Nick
>

From Valdis.Kletnieks at vt.edu  Tue Aug 11 01:07:43 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 10 Aug 2015 21:07:43 -0400
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: Your message of "Tue, 11 Aug 2015 09:36:07 +1000."
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
Message-ID: <4695.1439255263@turing-police.cc.vt.edu>

On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said:

> Once setup correctly. very good product - it's been running for 8 months
> now and hasn't had any issues. It's been very reliable.

I'll bite - (roughly) how many times has it triggered and mitigated an actual
DDoS during those 8 months?  We probably draw different conclusions from "8
months and 1 DDoS" reliable and "8 months of 5-a-week" reliable...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150810/1dfe442a/attachment.pgp>

From ryan at finnesey.com  Tue Aug 11 01:11:07 2015
From: ryan at finnesey.com (Ryan Finnesey)
Date: Tue, 11 Aug 2015 01:11:07 +0000
Subject: Data Center operations mail list?
In-Reply-To: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
Message-ID: <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>

Did you come across one?

Sent from my Windows Phone
________________________________
From: Chris Boyd<mailto:cboyd at gizmopartners.com>
Sent: ?8/?6/?2015 1:04 PM
To: NANOG<mailto:nanog at nanog.org>
Subject: Data Center operations mail list?

Is there a mail list that?s analogous to NANOG, but focused on the data center infrastructure and operations?  The shorty.com hosted list is defunct.

Thanks, and apologies for the tangential topic.

?Chris


From fergdawgster at mykolab.com  Tue Aug 11 01:28:18 2015
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Mon, 10 Aug 2015 18:28:18 -0700
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <4695.1439255263@turing-police.cc.vt.edu>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
 <4695.1439255263@turing-police.cc.vt.edu>
Message-ID: <55C94FB2.6070900@mykolab.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 8/10/2015 6:07 PM, Valdis.Kletnieks at vt.edu wrote:

> On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said:
> 
>> Once setup correctly. very good product - it's been running for 8
>> months now and hasn't had any issues. It's been very reliable.
> 
> I'll bite - (roughly) how many times has it triggered and mitigated
> an actual DDoS during those 8 months?  We probably draw different
> conclusions from "8 months and 1 DDoS" reliable and "8 months of
> 5-a-week" reliable...
> 


I think that would definitely depend on how the network is base-lined.

That is sometimes more of an art than a science. :-)

- - ferg


- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe
70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP
=d7d1
-----END PGP SIGNATURE-----

From nick.pratley at serversaustralia.com.au  Tue Aug 11 01:48:48 2015
From: nick.pratley at serversaustralia.com.au (Nick Pratley)
Date: Tue, 11 Aug 2015 11:48:48 +1000
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <55C94FB2.6070900@mykolab.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local>
 <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
 <4695.1439255263@turing-police.cc.vt.edu>
 <55C94FB2.6070900@mykolab.com>
Message-ID: <CALf9hzABGGPfgdBM=A3tvNMQJQ5jvKdHAjXo6oOL-1GCqo_Sqw@mail.gmail.com>

Some base numbers as it stands now:

Total Anomalies: ~8000
Total Prefixes in BGP: ~400

We don't mitigate _everthing_ - if our transit can handle the inbound then
it doesn't do anything - just alert and take a pcap dump for further
tuning. If we see congestion, it moves prefixes around to a scrubbing
center to clean the traffic before returning back to us.

This is also just domestic AU, international traffic is on another system
that gets scrubbed 24x7.

We have close to 20 policys & threshold templates for all different
scenarios.

Though I was talking about the stability of the software, whilst dealing
with around 20Gbit raw data.

I've only seen one issue (thinking about it now, I need to raise a Feature
Request for this) - which is the ability to use the number of source IPs as
a metric to compliment pkt/s and bits/s thresholds. Would be nice to
trigger a rule if "total num src IPs" >= 100 + 600M of TCP then start
moving, but if only 600M TCP and 1 SRC IP, then leave it as it is.

Regards,
Nick

From larrysheldon at cox.net  Tue Aug 11 03:47:30 2015
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 10 Aug 2015 22:47:30 -0500
Subject: AT&T att.net postmaster contact needed
In-Reply-To: <35k11r00S1cZc56015k40B>
References: <35k11r00S1cZc56015k40B>
Message-ID: <55C97052.9060602@cox.net>

On 8/10/2015 12:43, Ken Chase wrote:
>
> please reply offlist, mutual customer issue.

Seems like this exact question comes up pretty frequently.

Maybe NANOG should consider a repository of frequent inquiries.......


-- 
sed quis custodiet ipsos custodes? (Juvenal)

From marcel.duregards at yahoo.fr  Tue Aug 11 06:14:54 2015
From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr)
Date: Tue, 11 Aug 2015 08:14:54 +0200
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <55C94FB2.6070900@mykolab.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
 <4695.1439255263@turing-police.cc.vt.edu> <55C94FB2.6070900@mykolab.com>
Message-ID: <55C992DE.3020906@yahoo.fr>

anybody from this impressive list ?:

https://www.andrisoft.com/company/customers

-- Marcel



On 11.08.2015 03:28, Paul Ferguson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 8/10/2015 6:07 PM, Valdis.Kletnieks at vt.edu wrote:
>
>> On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said:
>>
>>> Once setup correctly. very good product - it's been running for 8
>>> months now and hasn't had any issues. It's been very reliable.
>>
>> I'll bite - (roughly) how many times has it triggered and mitigated
>> an actual DDoS during those 8 months?  We probably draw different
>> conclusions from "8 months and 1 DDoS" reliable and "8 months of
>> 5-a-week" reliable...
>>
>
>
> I think that would definitely depend on how the network is base-lined.
>
> That is sometimes more of an art than a science. :-)
>
> - - ferg
>
>
> - --
> Paul Ferguson
> PGP Public Key ID: 0x54DC85B2
> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe
> 70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP
> =d7d1
> -----END PGP SIGNATURE-----
>

From rsk at gsp.org  Tue Aug 11 13:01:02 2015
From: rsk at gsp.org (Rich Kulawiec)
Date: Tue, 11 Aug 2015 09:01:02 -0400
Subject: AT&T att.net postmaster contact needed
In-Reply-To: <55C97052.9060602@cox.net>
References: <35k11r00S1cZc56015k40B>
 <55C97052.9060602@cox.net>
Message-ID: <20150811130102.GA11238@gsp.org>

On Mon, Aug 10, 2015 at 10:47:30PM -0500, Larry Sheldon wrote:
> Seems like this exact question comes up pretty frequently.
> 
> Maybe NANOG should consider a repository of frequent inquiries.......

Maybe AT&T and others should consider reading RFC 2142 and implementing
it properly, like every competent/professional operation on the planet
already does.  Doing so would render these questions unnecessary.

---rsk

From rafael at gav.ufsc.br  Tue Aug 11 13:01:59 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Tue, 11 Aug 2015 08:01:59 -0500
Subject: Data Center operations mail list?
In-Reply-To: <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
Message-ID: <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>

I am setting one up and invited Chris to moderate it with me. I've always
looked for a list that covers that topic as well. I followed the same name
style as nanog and registered the nadcog.org domain.

On Mon, Aug 10, 2015 at 8:11 PM, Ryan Finnesey <ryan at finnesey.com> wrote:

> Did you come across one?
>
> Sent from my Windows Phone
> ________________________________
> From: Chris Boyd<mailto:cboyd at gizmopartners.com>
> Sent: ?8/?6/?2015 1:04 PM
> To: NANOG<mailto:nanog at nanog.org>
> Subject: Data Center operations mail list?
>
> Is there a mail list that?s analogous to NANOG, but focused on the data
> center infrastructure and operations?  The shorty.com hosted list is
> defunct.
>
> Thanks, and apologies for the tangential topic.
>
> ?Chris
>
>

From mel at beckman.org  Tue Aug 11 13:32:52 2015
From: mel at beckman.org (Mel Beckman)
Date: Tue, 11 Aug 2015 13:32:52 +0000
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>,
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
Message-ID: <F70EECB6-6E6E-429D-B3C5-4BED126DC260@beckman.org>

A very good idea!

-mel via cell

> On Aug 11, 2015, at 6:06 AM, Rafael Possamai <rafael at gav.ufsc.br> wrote:
> 
> I am setting one up and invited Chris to moderate it with me. I've always
> looked for a list that covers that topic as well. I followed the same name
> style as nanog and registered the nadcog.org domain.
> 
>> On Mon, Aug 10, 2015 at 8:11 PM, Ryan Finnesey <ryan at finnesey.com> wrote:
>> 
>> Did you come across one?
>> 
>> Sent from my Windows Phone
>> ________________________________
>> From: Chris Boyd<mailto:cboyd at gizmopartners.com>
>> Sent: ?8/?6/?2015 1:04 PM
>> To: NANOG<mailto:nanog at nanog.org>
>> Subject: Data Center operations mail list?
>> 
>> Is there a mail list that?s analogous to NANOG, but focused on the data
>> center infrastructure and operations?  The shorty.com hosted list is
>> defunct.
>> 
>> Thanks, and apologies for the tangential topic.
>> 
>> ?Chris
>> 
>> 

From rwebb at ropeguru.com  Tue Aug 11 13:52:06 2015
From: rwebb at ropeguru.com (Robert Webb)
Date: Tue, 11 Aug 2015 09:52:06 -0400
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com><BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com><CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
Message-ID: <ximss-516026@mail.ropeguru.com>

Very nice.

Please let us know when you have it up and available.

Robert
On Tue, 11 Aug 2015 08:01:59 -0500
  Rafael Possamai <rafael at gav.ufsc.br> wrote:
> I am setting one up and invited Chris to moderate it with me. I've 
>always
> looked for a list that covers that topic as well. I followed the 
>same name
> style as nanog and registered the nadcog.org domain.
> 
> On Mon, Aug 10, 2015 at 8:11 PM, Ryan Finnesey <ryan at finnesey.com> 
>wrote:
> 
>> Did you come across one?
>>
>> Sent from my Windows Phone
>> ________________________________
>> From: Chris Boyd<mailto:cboyd at gizmopartners.com>
>> Sent: ?8/?6/?2015 1:04 PM
>> To: NANOG<mailto:nanog at nanog.org>
>> Subject: Data Center operations mail list?
>>
>> Is there a mail list that?s analogous to NANOG, but focused on the 
>>data
>> center infrastructure and operations?  The shorty.com hosted list is
>> defunct.
>>
>> Thanks, and apologies for the tangential topic.
>>
>> ?Chris
>>
>>



From maillist at webjogger.net  Tue Aug 11 14:00:21 2015
From: maillist at webjogger.net (Adam Greene)
Date: Tue, 11 Aug 2015 10:00:21 -0400
Subject: Cogent revisited
Message-ID: <01bb01d0d43e$0fd8c630$2f8a5290$@webjogger.net>

Hi all,

 

We are getting ready to renew our fiber contract with our incumbent provider
(Lightower, ASN 46887). We are happy with them, but are looking for
alternatives. At the location in question we need about 200M.

 

Cogent recently contacted us, and I shied away a bit, based on this
conversation a few years ago:

 

http://mailman.nanog.org/pipermail/nanog/2012-May/048181.html

 

Have opinions changed since then? Or is Cogent still the "budget alternative
to have in your mix, but better to stay away from if you need
high-performance, reliable, mostly standalone bandwidth" (which is how I
would summarize the consensus in 2012)?

 

Thanks,

Adam

 

 

 


From ryan at finnesey.com  Tue Aug 11 14:05:49 2015
From: ryan at finnesey.com (Ryan Finnesey)
Date: Tue, 11 Aug 2015 14:05:49 +0000
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>,
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
Message-ID: <BY1PR0501MB146269A66E673A97E9ECC7B4B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>

Thank you for getting this going.

Sent from my Windows Phone
________________________________
From: Rafael Possamai<mailto:rafael at gav.ufsc.br>
Sent: ?8/?11/?2015 9:02 AM
To: Ryan Finnesey<mailto:ryan at finnesey.com>
Cc: Chris Boyd<mailto:cboyd at gizmopartners.com>; NANOG<mailto:nanog at nanog.org>
Subject: Re: Data Center operations mail list?

I am setting one up and invited Chris to moderate it with me. I've always looked for a list that covers that topic as well. I followed the same name style as nanog and registered the nadcog.org<http://nadcog.org> domain.

On Mon, Aug 10, 2015 at 8:11 PM, Ryan Finnesey <ryan at finnesey.com<mailto:ryan at finnesey.com>> wrote:
Did you come across one?

Sent from my Windows Phone
________________________________
From: Chris Boyd<mailto:cboyd at gizmopartners.com<mailto:cboyd at gizmopartners.com>>
Sent: ?8/?6/?2015 1:04 PM
To: NANOG<mailto:nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Data Center operations mail list?

Is there a mail list that?s analogous to NANOG, but focused on the data center infrastructure and operations?  The shorty.com<http://shorty.com> hosted list is defunct.

Thanks, and apologies for the tangential topic.

?Chris



From nick.rose at enzu.com  Tue Aug 11 14:42:57 2015
From: nick.rose at enzu.com (Nick Rose)
Date: Tue, 11 Aug 2015 14:42:57 +0000
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <55C992DE.3020906@yahoo.fr>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
 <4695.1439255263@turing-police.cc.vt.edu> <55C94FB2.6070900@mykolab.com>
 <55C992DE.3020906@yahoo.fr>
Message-ID: <9889B2E9-FB43-4252-84F9-F633AEF4E588@enzu.com>

We have processed just under a million anomalies with this software, we use the Chelsio cards for filtering. We had some troubles with packet loss on the filter side until we started using those which were a new feature in the latest release.

If you have any questions I would be happy to answer them.

Regards,
Nick Rose | CTO 
Enzu Inc 
nick.rose at enzu.com 
www.enzu.com <http://www.enzu.com/>








On 8/11/15, 2:14 AM, "NANOG on behalf of marcel.duregards at yahoo.fr" <nanog-bounces at nanog.org on behalf of marcel.duregards at yahoo.fr> wrote:

>anybody from this impressive list ?:
>
>https://www.andrisoft.com/company/customers
>
>-- Marcel
>
>
>
>On 11.08.2015 03:28, Paul Ferguson wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 8/10/2015 6:07 PM, Valdis.Kletnieks at vt.edu wrote:
>>
>>> On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said:
>>>
>>>> Once setup correctly. very good product - it's been running for 8
>>>> months now and hasn't had any issues. It's been very reliable.
>>>
>>> I'll bite - (roughly) how many times has it triggered and mitigated
>>> an actual DDoS during those 8 months?  We probably draw different
>>> conclusions from "8 months and 1 DDoS" reliable and "8 months of
>>> 5-a-week" reliable...
>>>
>>
>>
>> I think that would definitely depend on how the network is base-lined.
>>
>> That is sometimes more of an art than a science. :-)
>>
>> - - ferg
>>
>>
>> - --
>> Paul Ferguson
>> PGP Public Key ID: 0x54DC85B2
>> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe
>> 70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP
>> =d7d1
>> -----END PGP SIGNATURE-----
>>

From egon at egon.cc  Tue Aug 11 14:59:41 2015
From: egon at egon.cc (James Downs)
Date: Tue, 11 Aug 2015 07:59:41 -0700
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
Message-ID: <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>


> On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> wrote:

> style as nanog and registered the nadcog.org domain.

Nad Cog?

From mikea at mikea.ath.cx  Tue Aug 11 15:07:17 2015
From: mikea at mikea.ath.cx (mikea)
Date: Tue, 11 Aug 2015 10:07:17 -0500
Subject: Data Center operations mail list?
In-Reply-To: <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
Message-ID: <20150811150717.GB57214@mikea.ath.cx>

On Tue, Aug 11, 2015 at 07:59:41AM -0700, James Downs wrote:
> 
> > On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> wrote:
> 
> > style as nanog and registered the nadcog.org domain.
> 
> Nad Cog?

North American Data Center Operations Group, perhaps? 

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin 

From saper at saper.info  Tue Aug 11 15:15:10 2015
From: saper at saper.info (Marcin Cieslak)
Date: Tue, 11 Aug 2015 15:15:10 +0000
Subject: Data Center operations mail list?
In-Reply-To: <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
Message-ID: <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>

On Tue, 11 Aug 2015, James Downs wrote:

> 
> > On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> wrote:
> 
> > style as nanog and registered the nadcog.org domain.
> 
> Nad Cog?


datacenterops.org is still available *hint*hint*

~Marcin


From mksmith at mac.com  Tue Aug 11 15:35:02 2015
From: mksmith at mac.com (Michael Smith)
Date: Tue, 11 Aug 2015 22:35:02 +0700
Subject: Data Center operations mail list?
In-Reply-To: <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
Message-ID: <C97741D6-D84E-462C-8B6A-79A1088925DB@mac.com>

dc-ops at puck.nether.net <mailto:dc-ops at puck.nether.net> has been around for at least 5 years and has, to date, 3 or 4 emails IIRC.  It?s still there if you want something already built and functional.

Mike

> On Aug 11, 2015, at 10:15 PM, Marcin Cieslak <saper at saper.info> wrote:
> 
> On Tue, 11 Aug 2015, James Downs wrote:
> 
>> 
>>> On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> wrote:
>> 
>>> style as nanog and registered the nadcog.org domain.
>> 
>> Nad Cog?
> 
> 
> datacenterops.org is still available *hint*hint*
> 
> ~Marcin
> 


From aaron at wholesaleinternet.net  Tue Aug 11 15:42:03 2015
From: aaron at wholesaleinternet.net (Aaron)
Date: Tue, 11 Aug 2015 10:42:03 -0500
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <9889B2E9-FB43-4252-84F9-F633AEF4E588@enzu.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
 <4695.1439255263@turing-police.cc.vt.edu> <55C94FB2.6070900@mykolab.com>
 <55C992DE.3020906@yahoo.fr> <9889B2E9-FB43-4252-84F9-F633AEF4E588@enzu.com>
Message-ID: <55CA17CB.6020308@wholesaleinternet.net>

We tested it a while back and found that it was fine for single source 
attacks but fell over with multiple sources.  Has that changed?



On 8/11/2015 9:42 AM, Nick Rose wrote:
> We have processed just under a million anomalies with this software, we use the Chelsio cards for filtering. We had some troubles with packet loss on the filter side until we started using those which were a new feature in the latest release.
>
> If you have any questions I would be happy to answer them.
>
> Regards,
> Nick Rose | CTO
> Enzu Inc
> nick.rose at enzu.com
> www.enzu.com <http://www.enzu.com/>
>
>
>
>
>
>
>
>
> On 8/11/15, 2:14 AM, "NANOG on behalf of marcel.duregards at yahoo.fr" <nanog-bounces at nanog.org on behalf of marcel.duregards at yahoo.fr> wrote:
>
>> anybody from this impressive list ?:
>>
>> https://www.andrisoft.com/company/customers
>>
>> -- Marcel
>>
>>
>>
>> On 11.08.2015 03:28, Paul Ferguson wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On 8/10/2015 6:07 PM, Valdis.Kletnieks at vt.edu wrote:
>>>
>>>> On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said:
>>>>
>>>>> Once setup correctly. very good product - it's been running for 8
>>>>> months now and hasn't had any issues. It's been very reliable.
>>>> I'll bite - (roughly) how many times has it triggered and mitigated
>>>> an actual DDoS during those 8 months?  We probably draw different
>>>> conclusions from "8 months and 1 DDoS" reliable and "8 months of
>>>> 5-a-week" reliable...
>>>>
>>>
>>> I think that would definitely depend on how the network is base-lined.
>>>
>>> That is sometimes more of an art than a science. :-)
>>>
>>> - - ferg
>>>
>>>
>>> - --
>>> Paul Ferguson
>>> PGP Public Key ID: 0x54DC85B2
>>> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2
>>>
>>> iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe
>>> 70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP
>>> =d7d1
>>> -----END PGP SIGNATURE-----
>>>

-- 
================================================================
Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
(816)550-9030
http://www.wholesaleinternet.com
================================================================


From jared at puck.nether.net  Tue Aug 11 15:46:45 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 11 Aug 2015 11:46:45 -0400
Subject: Data Center operations mail list?
In-Reply-To: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
Message-ID: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>

There is a DC-ops list hosted at puck I setup for people awhile ago. Feel free to use that. 

Jared Mauch

> On Aug 6, 2015, at 1:01 PM, Chris Boyd <cboyd at gizmopartners.com> wrote:
> 
> Is there a mail list that?s analogous to NANOG, but focused on the data center infrastructure and operations?  The shorty.com hosted list is defunct.
> 
> Thanks, and apologies for the tangential topic.
> 
> ?Chris

From askoorb+nanog at gmail.com  Tue Aug 11 15:46:38 2015
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Tue, 11 Aug 2015 16:46:38 +0100
Subject: Data Center operations mail list?
In-Reply-To: <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
Message-ID: <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>

Hi,

On Tue, Aug 11, 2015 at 4:15 PM, Marcin Cieslak <saper at saper.info> wrote:
> On Tue, 11 Aug 2015, James Downs wrote:
>
>>
>> > On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> wrote:
>>
>> > style as nanog and registered the nadcog.org domain.
>>
>> Nad Cog?
>
>
> datacenterops.org is still available *hint*hint*
>
> ~Marcin

With the lack of interest compared to NANOG (especially seeing how the
old list simply dried up) it might be best making the list global
rather than North America only to get the traffic levels up a bit.

Alex

From matias at telbrax.com.br  Tue Aug 11 10:27:25 2015
From: matias at telbrax.com.br (Matias Breunig)
Date: Tue, 11 Aug 2015 07:27:25 -0300
Subject: Super Core Hardware suggestions
In-Reply-To: <CAFt8naHXk=8Rwj8zu0RbAJ7CUUKH=X33gMZRsYoL-ujMtD+skg@mail.gmail.com>
References: <7a55f018fbdb4d68be25745badb0ba0d@OTW-BNE-EXC01.otw.internal>
 <CAFt8naHXk=8Rwj8zu0RbAJ7CUUKH=X33gMZRsYoL-ujMtD+skg@mail.gmail.com>
Message-ID: <CAOEOXVWyMAS3fY-bBH=0TnMxav3AG2d=+JV-0-84KR62_N1yBg@mail.gmail.com>

And what about Juniper ACX5000 (96x SFP + 10GbE and 40GbE QSFP + 8x), you
can consider it as P only?

http://www.juniper.net/us/en/products-services/routing/acx-series/acx5000/


Tks,

Matias

2015-08-10 18:05 GMT-03:00 Scott Larson <stl at wiredrive.com>:

>      I'm in the same boat myself. One thing I can share is Juniper really
> doesn't want to talk about the PTX1000 at all right now as it's not due to
> be available until November. They're going to suggest you look at the
> MX240/480 instead.
>
>
> *[image: userimage]Scott Larson[image: los angeles]
> <
> https://www.google.com/maps/place/4216+Glencoe+Ave,+Marina+Del+Rey,+CA+90292/@33.9892151,-118.4421334,17z/data=!3m1!4b1!4m2!3m1!1s0x80c2ba88ffae914d:0x14e1d00084d4d09c
> >Lead
> Systems Administrator[image: wdlogo] <https://www.wiredrive.com/> [image:
> linkedin] <https://www.linkedin.com/company/wiredrive> [image: facebook]
> <https://www.twitter.com/wiredrive> [image: twitter]
> <https://www.facebook.com/wiredrive> [image: instagram]
> <https://www.instagram.com/wiredrive>T 310 823 8238 x1106
> <310%20823%208238%20x1106>  |  M 310 904 8818 <310%20904%208818>*
>
> On Thu, Aug 6, 2015 at 7:10 PM, Ben Cornish <benc at overthewire.com.au>
> wrote:
>
> > Hey All
> >
> > We are looking for suggestions for a device to act as a super Core Device
> > / MPLS P router only.
> > There seems to be plenty of Chassis based solutions out there that also
> > cater for a lot more.
> > We ideally would like a 1RU or 2RU device - Handling MPLS / IGP only
> >
> > *         Ideally 16 to 48 ports of 10Gig - SFP
> >
> > *         Non-blocking line rate capable on all ports.
> >
> > *         MPLS / OSPF /BFD / ISIS / RSVP-TE capably.
> >
> > *         Deep buffers on the ports would also be nice
> >
> > *         With a possible option of 40Gig uplinks..
> >
> > Thanks
> >
>

From jsink at phone.com  Tue Aug 11 14:59:27 2015
From: jsink at phone.com (James Sink)
Date: Tue, 11 Aug 2015 07:59:27 -0700
Subject: free Tools to monitor website performance
In-Reply-To: <55C6C143.1080502@gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
 <78C35D6C1A82D243B830523B4193CF5F9F4474A1BA@SBS1.blinker.local>
 <CAAARkvJGyEjpSRiq2p8C_Meoyz=uTGCGSPbFV0qh5gmZgf+68g@mail.gmail.com>
 <CAAb54+vLcmnEc5Wyh7npEKwCAtrpmpOnqsfzPgMt-csFj+XmmA@mail.gmail.com>
 <55C6C143.1080502@gmail.com>
Message-ID: <CAO7CQnS2-8-9K8_Fvgvagh0KxNKi0LQEF1czD0EoECAVZ-iKzA@mail.gmail.com>

Monitis has a free option called monitor.us and you can set up several
different kinds of probes in many locations.


[image: Phone.com] <http://www.phone.com/>James SinkSenior Network Engineer
jsink at phone.com(800) 997-9179 x506Try Phone.com free!
<http://www.phone.com/?_tracking_id=10132>CONFIDENTIALITY NOTICE: This
e-mail and any attachments are for the exclusive and confidential use of
the intended recipient. If you received this in error, please do not read,
distribute, or take action in reliance upon this message. Instead, please
notify us immediately by return e-mail and promptly delete this message and
its attachments from your computer system.

On Sat, Aug 8, 2015 at 7:56 PM, Chaim Rieger <chaim.rieger at gmail.com> wrote:

> I think that Apica might have a free option as well. (www.apicasystem.com)
>
>
>
>
> On 08/08/2015 11:38 AM, Daren Darrow wrote:
>
>> Pingdom is the most affordable one I've seen recently.  You can try it out
>> with one URL for free
>> https://www.pingdom.com/free
>>
>> It also has some other nice free tools.
>> http://tools.pingdom.com/fpt/
>>
>>
>>
>> --
>> Daren Darrow, darrow at gmail.com
>>
>> On Thu, Aug 6, 2015 at 12:02 AM, Bryan Tong <contact at nullivex.com> wrote:
>>
>> Hello,
>>>
>>> We have been using Zabbix with great success on 900 hosts. I would
>>> recommend it, however I must agree the learning curve can be pretty
>>> steep.
>>> I think of Zabbix more like a piece of networking equipment where it wont
>>> do anything until everything is configured correctly. It is far from plug
>>> and play, but very powerful and flexible.
>>>
>>> Thanks
>>>
>>> On Thu, Aug 6, 2015 at 12:59 AM, David Hofstee <david at mailplus.nl>
>>> wrote:
>>>
>>> We use Zabbix for local monitoring. Quite powerful (Nagios crapped out a
>>>> lot on larger setups, although 300 is not large). There is a learning
>>>>
>>> curve
>>>
>>>> for Zabbix.
>>>>
>>>> We have a few VPS'es outside our network for DNS reasons. They are
>>>> configured as (pushing) monitoring nodes too. Bye,
>>>>
>>>>
>>>> David Hofstee
>>>>
>>>> Deliverability Management
>>>> MailPlus B.V. Netherlands (ESP)
>>>>
>>>> -----Oorspronkelijk bericht-----
>>>> Van: NANOG [mailto:nanog-bounces at nanog.org] Namens sathish kumar Ippani
>>>> Verzonden: Thursday, August 6, 2015 4:24 AM
>>>> Aan: nanog at nanog.org
>>>> Onderwerp: free Tools to monitor website performance
>>>>
>>>> Hi All,
>>>>
>>>> Thanks to all for reviewing my topic, may it is slightly off topic.
>>>>
>>>> We have almost 300 URL's (local and web) and we want to monitor few of
>>>> them which are very critical URL's for web access and local access.
>>>>
>>>> I would like to know is there any free tool or software with I can use
>>>> to
>>>> monitor url performance in terms of response time. Which gives more
>>>> information like how much time it taken to connect the server and time
>>>> to
>>>> load the page and total response time.
>>>>
>>>> Thanks in advance.
>>>>
>>>>
>>>>
>>>> --
>>>> With Regards,
>>>>
>>>> Sathish Ippani
>>>>
>>>>
>>>
>>> --
>>> eSited LLC
>>> (701) 390-9638
>>>
>>>
>

From jra at baylink.com  Tue Aug 11 17:35:28 2015
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 11 Aug 2015 13:35:28 -0400 (EDT)
Subject: Data Center operations mail list?
In-Reply-To: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
Message-ID: <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>

Absolutely feel free to use it; I haven't seen a single message on it in...
well, it was 3 years ago I was in datacenters regularly, so I'm goin with
"3 years".  :-)

Cheers,
-- jra

----- Original Message -----
> From: "Jared Mauch" <jared at puck.nether.net>
> To: "Chris Boyd" <cboyd at gizmopartners.com>
> Cc: "NANOG" <nanog at nanog.org>
> Sent: Tuesday, August 11, 2015 11:46:45 AM
> Subject: Re: Data Center operations mail list?
> There is a DC-ops list hosted at puck I setup for people awhile ago.
> Feel free to use that.
> 
> Jared Mauch
> 
> > On Aug 6, 2015, at 1:01 PM, Chris Boyd <cboyd at gizmopartners.com>
> > wrote:
> >
> > Is there a mail list that?s analogous to NANOG, but focused on the
> > data center infrastructure and operations? The shorty.com hosted
> > list is defunct.
> >
> > Thanks, and apologies for the tangential topic.
> >
> > ?Chris

-- 
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 yashodhan.barve at gmail.com  Tue Aug 11 17:36:45 2015
From: yashodhan.barve at gmail.com (Yashodhan Barve)
Date: Tue, 11 Aug 2015 13:36:45 -0400
Subject: free Tools to monitor website performance
In-Reply-To: <CAO7CQnS2-8-9K8_Fvgvagh0KxNKi0LQEF1czD0EoECAVZ-iKzA@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
 <78C35D6C1A82D243B830523B4193CF5F9F4474A1BA@SBS1.blinker.local>
 <CAAARkvJGyEjpSRiq2p8C_Meoyz=uTGCGSPbFV0qh5gmZgf+68g@mail.gmail.com>
 <CAAb54+vLcmnEc5Wyh7npEKwCAtrpmpOnqsfzPgMt-csFj+XmmA@mail.gmail.com>
 <55C6C143.1080502@gmail.com>
 <CAO7CQnS2-8-9K8_Fvgvagh0KxNKi0LQEF1czD0EoECAVZ-iKzA@mail.gmail.com>
Message-ID: <55CA32AD.2070901@gmail.com>

I have had a good experience with uptimerobot.com
50 monitors are free and at a 5 min interval. If you need more features 
then you can upgrade to the pro version.
They have multiple locations too. http://uptimerobot.com/locations

On 2015-08-11 10:59 AM, James Sink wrote:
> Monitis has a free option called monitor.us and you can set up several
> different kinds of probes in many locations.
>
>
> [image: Phone.com] <http://www.phone.com/>James SinkSenior Network Engineer
> jsink at phone.com(800) 997-9179 x506Try Phone.com free!
> <http://www.phone.com/?_tracking_id=10132>CONFIDENTIALITY NOTICE: This
> e-mail and any attachments are for the exclusive and confidential use of
> the intended recipient. If you received this in error, please do not read,
> distribute, or take action in reliance upon this message. Instead, please
> notify us immediately by return e-mail and promptly delete this message and
> its attachments from your computer system.
>
> On Sat, Aug 8, 2015 at 7:56 PM, Chaim Rieger <chaim.rieger at gmail.com> wrote:
>
>> I think that Apica might have a free option as well. (www.apicasystem.com)
>>
>>
>>
>>
>> On 08/08/2015 11:38 AM, Daren Darrow wrote:
>>
>>> Pingdom is the most affordable one I've seen recently.  You can try it out
>>> with one URL for free
>>> https://www.pingdom.com/free
>>>
>>> It also has some other nice free tools.
>>> http://tools.pingdom.com/fpt/
>>>
>>>
>>>
>>> --
>>> Daren Darrow, darrow at gmail.com
>>>
>>> On Thu, Aug 6, 2015 at 12:02 AM, Bryan Tong <contact at nullivex.com> wrote:
>>>
>>> Hello,
>>>> We have been using Zabbix with great success on 900 hosts. I would
>>>> recommend it, however I must agree the learning curve can be pretty
>>>> steep.
>>>> I think of Zabbix more like a piece of networking equipment where it wont
>>>> do anything until everything is configured correctly. It is far from plug
>>>> and play, but very powerful and flexible.
>>>>
>>>> Thanks
>>>>
>>>> On Thu, Aug 6, 2015 at 12:59 AM, David Hofstee <david at mailplus.nl>
>>>> wrote:
>>>>
>>>> We use Zabbix for local monitoring. Quite powerful (Nagios crapped out a
>>>>> lot on larger setups, although 300 is not large). There is a learning
>>>>>
>>>> curve
>>>>
>>>>> for Zabbix.
>>>>>
>>>>> We have a few VPS'es outside our network for DNS reasons. They are
>>>>> configured as (pushing) monitoring nodes too. Bye,
>>>>>
>>>>>
>>>>> David Hofstee
>>>>>
>>>>> Deliverability Management
>>>>> MailPlus B.V. Netherlands (ESP)
>>>>>
>>>>> -----Oorspronkelijk bericht-----
>>>>> Van: NANOG [mailto:nanog-bounces at nanog.org] Namens sathish kumar Ippani
>>>>> Verzonden: Thursday, August 6, 2015 4:24 AM
>>>>> Aan: nanog at nanog.org
>>>>> Onderwerp: free Tools to monitor website performance
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Thanks to all for reviewing my topic, may it is slightly off topic.
>>>>>
>>>>> We have almost 300 URL's (local and web) and we want to monitor few of
>>>>> them which are very critical URL's for web access and local access.
>>>>>
>>>>> I would like to know is there any free tool or software with I can use
>>>>> to
>>>>> monitor url performance in terms of response time. Which gives more
>>>>> information like how much time it taken to connect the server and time
>>>>> to
>>>>> load the page and total response time.
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> With Regards,
>>>>>
>>>>> Sathish Ippani
>>>>>
>>>>>
>>>> --
>>>> eSited LLC
>>>> (701) 390-9638
>>>>
>>>>


From jungleboogie0 at gmail.com  Tue Aug 11 16:50:21 2015
From: jungleboogie0 at gmail.com (jungle Boogie)
Date: Tue, 11 Aug 2015 09:50:21 -0700
Subject: free Tools to monitor website performance
In-Reply-To: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
References: <CAAN7Uqvf1aJtjwTUd5UN_NAhi+JiORumbc7CN+2E1AJc_1Zb1w@mail.gmail.com>
Message-ID: <CAKE2PDt+n4YrHz8Hhy-h1mMeJgRoOcsNgCVEFzWr+doF7_YLSQ@mail.gmail.com>

On 5 August 2015 at 19:23, sathish kumar Ippani
<sathish.kumar.ippani at gmail.com> wrote:
> Hi All,
>
> Thanks to all for reviewing my topic, may it is slightly off topic.
>
> We have almost 300 URL's (local and web) and we want to monitor few of them
> which are very critical URL's for web access and local access.
>
> I would like to know is there any free tool or software with I can use to
> monitor url performance in terms of response time. Which gives more
> information like how much time it taken to connect the server and time to
> load the page and total response time.
>

I don't see how you'll be able to test local access externally;
however, check out https://uptimerobot.com/ for 50 free monitors and a
very inexpensive paid offering.

> Thanks in advance.
>
>
>
> --
> With Regards,
>
> Sathish Ippani



-- 
-------
inum: 883510009027723
sip: jungleboogie at sip2sip.info
xmpp: jungle-boogie at jit.si

From colton.conor at gmail.com  Tue Aug 11 18:21:09 2015
From: colton.conor at gmail.com (Colton Conor)
Date: Tue, 11 Aug 2015 13:21:09 -0500
Subject: Branch Location Over The Internet
Message-ID: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>

We have an enterprise that has a headquarter office with redundant fiber
connections, its own ASN, its own /22 IP block from ARIN, and a couple of
gigabit internet connections from multiple providers. The office is taking
full BGP routes from tier 1 providers using a Juniper MX80.

They are establishing their first branch location, and need the branch
location to be able to securely communicate back to headquarters, AND be
able to use a /24 of  headquarters public IP addresses. Ideally the device
at the HQ location would hand out public IP address using DHCP to the other
side of the tunnel at the branch location.

We know that in an ideal world it would be wise to get layer 2 transport
connections from HQ to the branch location, but lets assume that is not an
option. Please don't flood this thread about how it could be an option
because it's not at this time. This setup will be temporary and in service
for the next year until we get fiber to the branch site.

Let's assume at the branch location we can get a DOCSIS cable internet
connection from a incumbent cable provider such as Comcast, and that
provider will give us a couple static IP address. Assume as a backup, we
have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
dynamic IP address.

What solution could we put at the HQ site and the branch site to achieve
this? Ideally we would want the solution to load balance between the
connections based on the connections speeds, and failover if one is down.
The cable connection will be much faster speed (probably 150Mbps down and
10 Upload) compared to the DSL connection (10 download and 1 upload). If we
need more speed we can upgrade the cable modem to a higher package, but for
DSL that is the max speed so we might have to get multiple DSL lines. The
cable solution could always be used as the primary, and the DSL connection
could only be used as backup if that makes things easier.

If you were to do this with Juniper or Cisco gear what would you have at
each location? What technology would you use?

I know there is Pepewave and a couple of other software solutions that seem
to have a proprietary load balancing solutions developed, but I would
prefer to use a common Cisco or Juniper solution if one exists.

There will be 50 users at the branch office. There is only one branch
location at this time, but they might expand to a couple more but under 10.

From job at instituut.net  Tue Aug 11 18:30:23 2015
From: job at instituut.net (Job Snijders)
Date: Tue, 11 Aug 2015 20:30:23 +0200
Subject: Branch Location Over The Internet
In-Reply-To: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
Message-ID: <20150811183023.GC77961@Vurt.local>

Hi,

On Tue, Aug 11, 2015 at 01:21:09PM -0500, Colton Conor wrote:
> We have an enterprise that has a headquarter office with redundant fiber
> connections, its own ASN, its own /22 IP block from ARIN.
> [ ... ]
> 
> If you were to do this with Juniper or Cisco gear what would you have at
> each location? What technology would you use?

You could look into using the LISP protocol, i think it meets all your
requirements. http://lisp.cisco.com/index.html

Kind regards,

Job

From jj at anexia.at  Tue Aug 11 18:46:04 2015
From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=)
Date: Tue, 11 Aug 2015 18:46:04 +0000
Subject: Branch Location Over The Internet
In-Reply-To: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
Message-ID: <f6e861bd1e734077992dc840ae5024a4@anx-i-dag01.anx.local>

Hi,

Mikrotik Routerboard + (encrypted) Ethernet over IP (EoIP). If required: MPLS+OSPF+BGP in the EoIP for additional features.

Build the pseudo Layer2 with two dedicated boxes. In the HQ you can hand it over directly to the MX80 and at the new office you can work with small boxes like Cisco 7301 (also available with redundant PS) or if you need more ports: 19xx ...

#) cheap setup
#) can easily transport a few hundred Meg
#) you can use refurb parts if required
#) big community support for Mikrotik Routerboards
#) encrypted transport possible
#) works with dynamic IPs
#) MPLS in the EoIP allows you to transport VRFs with BGP signaling

Etc etc

Best regards


J?rgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj at anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
Gesch?ftsf?hrer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601


-----Original Message-----
From: Colton Conor [colton.conor at gmail.com]
Received: Dienstag, 11 Aug. 2015, 20:23
To: NANOG [nanog at nanog.org]
Subject: Branch Location Over The Internet

We have an enterprise that has a headquarter office with redundant fiber
connections, its own ASN, its own /22 IP block from ARIN, and a couple of
gigabit internet connections from multiple providers. The office is taking
full BGP routes from tier 1 providers using a Juniper MX80.

They are establishing their first branch location, and need the branch
location to be able to securely communicate back to headquarters, AND be
able to use a /24 of  headquarters public IP addresses. Ideally the device
at the HQ location would hand out public IP address using DHCP to the other
side of the tunnel at the branch location.

We know that in an ideal world it would be wise to get layer 2 transport
connections from HQ to the branch location, but lets assume that is not an
option. Please don't flood this thread about how it could be an option
because it's not at this time. This setup will be temporary and in service
for the next year until we get fiber to the branch site.

Let's assume at the branch location we can get a DOCSIS cable internet
connection from a incumbent cable provider such as Comcast, and that
provider will give us a couple static IP address. Assume as a backup, we
have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
dynamic IP address.

What solution could we put at the HQ site and the branch site to achieve
this? Ideally we would want the solution to load balance between the
connections based on the connections speeds, and failover if one is down.
The cable connection will be much faster speed (probably 150Mbps down and
10 Upload) compared to the DSL connection (10 download and 1 upload). If we
need more speed we can upgrade the cable modem to a higher package, but for
DSL that is the max speed so we might have to get multiple DSL lines. The
cable solution could always be used as the primary, and the DSL connection
could only be used as backup if that makes things easier.

If you were to do this with Juniper or Cisco gear what would you have at
each location? What technology would you use?

I know there is Pepewave and a couple of other software solutions that seem
to have a proprietary load balancing solutions developed, but I would
prefer to use a common Cisco or Juniper solution if one exists.

There will be 50 users at the branch office. There is only one branch
location at this time, but they might expand to a couple more but under 10.

From rafael at gav.ufsc.br  Tue Aug 11 18:48:51 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Tue, 11 Aug 2015 13:48:51 -0500
Subject: Data Center operations mail list?
In-Reply-To: <20150811150717.GB57214@mikea.ath.cx>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <20150811150717.GB57214@mikea.ath.cx>
Message-ID: <CAJB2g-HWGiyW5CSWJX0vY-FNaDLUfD23RyxvUiFGLWFJ9uT1vQ@mail.gmail.com>

Exactly. I figured if it can be organized with the help of the community
and provide other benefits aside from a mailing list, I wouldn't have a
problem with helping.

On Tue, Aug 11, 2015 at 10:07 AM, mikea <mikea at mikea.ath.cx> wrote:

> On Tue, Aug 11, 2015 at 07:59:41AM -0700, James Downs wrote:
> >
> > > On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> wrote:
> >
> > > style as nanog and registered the nadcog.org domain.
> >
> > Nad Cog?
>
> North American Data Center Operations Group, perhaps?
>
> --
> Mike Andrews, W5EGO
> mikea at mikea.ath.cx
> Tired old sysadmin
>

From rafael at gav.ufsc.br  Tue Aug 11 18:49:33 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Tue, 11 Aug 2015 13:49:33 -0500
Subject: Data Center operations mail list?
In-Reply-To: <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
Message-ID: <CAJB2g-FPeXVa0iZRqvG0Zyo=LwxT_6C7vugyQASC=BORTnsRfg@mail.gmail.com>

What is the mailman URL?

On Tue, Aug 11, 2015 at 10:15 AM, Marcin Cieslak <saper at saper.info> wrote:

> On Tue, 11 Aug 2015, James Downs wrote:
>
> >
> > > On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> wrote:
> >
> > > style as nanog and registered the nadcog.org domain.
> >
> > Nad Cog?
>
>
> datacenterops.org is still available *hint*hint*
>
> ~Marcin
>
>

From hvgeekwtrvl at gmail.com  Tue Aug 11 18:51:27 2015
From: hvgeekwtrvl at gmail.com (james machado)
Date: Tue, 11 Aug 2015 11:51:27 -0700
Subject: Branch Location Over The Internet
In-Reply-To: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
Message-ID: <CADVasu6f9rs7BM3TYmtT9u-zgk2p01qX3L-Q9KgMCiEn6VkrBw@mail.gmail.com>

On Aug 11, 2015 11:22 AM, "Colton Conor" <colton.conor at gmail.com> wrote:
>
> We have an enterprise that has a headquarter office with redundant fiber
> connections, its own ASN, its own /22 IP block from ARIN, and a couple of
> gigabit internet connections from multiple providers. The office is taking
> full BGP routes from tier 1 providers using a Juniper MX80.
>
> They are establishing their first branch location, and need the branch
> location to be able to securely communicate back to headquarters, AND be
> able to use a /24 of  headquarters public IP addresses. Ideally the device
> at the HQ location would hand out public IP address using DHCP to the
other
> side of the tunnel at the branch location.
>
> We know that in an ideal world it would be wise to get layer 2 transport
> connections from HQ to the branch location, but lets assume that is not an
> option. Please don't flood this thread about how it could be an option
> because it's not at this time. This setup will be temporary and in service
> for the next year until we get fiber to the branch site.
>
> Let's assume at the branch location we can get a DOCSIS cable internet
> connection from a incumbent cable provider such as Comcast, and that
> provider will give us a couple static IP address. Assume as a backup, we
> have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
> dynamic IP address.
>
> What solution could we put at the HQ site and the branch site to achieve
> this? Ideally we would want the solution to load balance between the
> connections based on the connections speeds, and failover if one is down.
> The cable connection will be much faster speed (probably 150Mbps down and
> 10 Upload) compared to the DSL connection (10 download and 1 upload). If
we
> need more speed we can upgrade the cable modem to a higher package, but
for
> DSL that is the max speed so we might have to get multiple DSL lines. The
> cable solution could always be used as the primary, and the DSL connection
> could only be used as backup if that makes things easier.
>
> If you were to do this with Juniper or Cisco gear what would you have at
> each location? What technology would you use?
>

Colton,

The Cisco solution for this would be Cisco Intelligent WAN (iWAN) utilizing
ASRs and ISRs. iWAN utilizes a combination of DMVPNs and pFR to make this
happen.

Another name I've heard but have no feedback on is Viptela

> I know there is Pepewave and a couple of other software solutions that
seem
> to have a proprietary load balancing solutions developed, but I would
> prefer to use a common Cisco or Juniper solution if one exists.
>
> There will be 50 users at the branch office. There is only one branch
> location at this time, but they might expand to a couple more but under
10.

James

From colinj at gt86car.org.uk  Tue Aug 11 19:01:17 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Tue, 11 Aug 2015 20:01:17 +0100
Subject: Branch Location Over The Internet
In-Reply-To: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
Message-ID: <190BBC5E-94FD-48AE-9933-591F0AD32ACB@gt86car.org.uk>

sophus utm is the ideal technology for this requirement and vmware image works well for virtual device

colin

Sent from my iPhone

> On 11 Aug 2015, at 19:21, Colton Conor <colton.conor at gmail.com> wrote:
> 
> We have an enterprise that has a headquarter office with redundant fiber
> connections, its own ASN, its own /22 IP block from ARIN, and a couple of
> gigabit internet connections from multiple providers. The office is taking
> full BGP routes from tier 1 providers using a Juniper MX80.
> 
> They are establishing their first branch location, and need the branch
> location to be able to securely communicate back to headquarters, AND be
> able to use a /24 of  headquarters public IP addresses. Ideally the device
> at the HQ location would hand out public IP address using DHCP to the other
> side of the tunnel at the branch location.
> 
> We know that in an ideal world it would be wise to get layer 2 transport
> connections from HQ to the branch location, but lets assume that is not an
> option. Please don't flood this thread about how it could be an option
> because it's not at this time. This setup will be temporary and in service
> for the next year until we get fiber to the branch site.
> 
> Let's assume at the branch location we can get a DOCSIS cable internet
> connection from a incumbent cable provider such as Comcast, and that
> provider will give us a couple static IP address. Assume as a backup, we
> have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
> dynamic IP address.
> 
> What solution could we put at the HQ site and the branch site to achieve
> this? Ideally we would want the solution to load balance between the
> connections based on the connections speeds, and failover if one is down.
> The cable connection will be much faster speed (probably 150Mbps down and
> 10 Upload) compared to the DSL connection (10 download and 1 upload). If we
> need more speed we can upgrade the cable modem to a higher package, but for
> DSL that is the max speed so we might have to get multiple DSL lines. The
> cable solution could always be used as the primary, and the DSL connection
> could only be used as backup if that makes things easier.
> 
> If you were to do this with Juniper or Cisco gear what would you have at
> each location? What technology would you use?
> 
> I know there is Pepewave and a couple of other software solutions that seem
> to have a proprietary load balancing solutions developed, but I would
> prefer to use a common Cisco or Juniper solution if one exists.
> 
> There will be 50 users at the branch office. There is only one branch
> location at this time, but they might expand to a couple more but under 10.

From simon at slimey.org  Tue Aug 11 19:27:15 2015
From: simon at slimey.org (Simon Lockhart)
Date: Tue, 11 Aug 2015 20:27:15 +0100
Subject: Data Center operations mail list?
In-Reply-To: <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
Message-ID: <20150811192715.GB2558@dilbert.slimey.org>

On Tue Aug 11, 2015 at 01:35:28pm -0400, Jay Ashworth wrote:
> Absolutely feel free to use it; I haven't seen a single message on it in...
> well, it was 3 years ago I was in datacenters regularly, so I'm goin with
> "3 years".  :-)

There's a message there now... :)

Rather than fragmenting further, I'd suggest building up demand first on
existing infrastructure. If it gets to the size of NANOG and needing a
support organisation around it, then it can split off then...

Simon

From rwebb at ropeguru.com  Tue Aug 11 19:42:01 2015
From: rwebb at ropeguru.com (Robert Webb)
Date: Tue, 11 Aug 2015 15:42:01 -0400
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-FPeXVa0iZRqvG0Zyo=LwxT_6C7vugyQASC=BORTnsRfg@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com><BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com><CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com><2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc><alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb><CAJB2g-FPeXVa0iZRqvG0Zyo=LwxT_6C7vugyQASC=BORTnsRfg@mail.gmail.com>
Message-ID: <ximss-516094@mail.ropeguru.com>

Nothing is currently running on that domain. It is just available if you 
make the right offer to purchase it.

Robert

On Tue, 11 Aug 2015 13:49:33 -0500
  Rafael Possamai <rafael at gav.ufsc.br> wrote:
> What is the mailman URL?
> 
> On Tue, Aug 11, 2015 at 10:15 AM, Marcin Cieslak <saper at saper.info> 
>wrote:
> 
>> On Tue, 11 Aug 2015, James Downs wrote:
>>
>> >
>> > > On Aug 11, 2015, at 06:01, Rafael Possamai <rafael at gav.ufsc.br> 
>>wrote:
>> >
>> > > style as nanog and registered the nadcog.org domain.
>> >
>> > Nad Cog?
>>
>>
>> datacenterops.org is still available *hint*hint*
>>
>> ~Marcin
>>
>>



From mfidelman at meetinghouse.net  Tue Aug 11 20:00:50 2015
From: mfidelman at meetinghouse.net (Miles Fidelman)
Date: Tue, 11 Aug 2015 16:00:50 -0400
Subject: Data Center operations mail list?
In-Reply-To: <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
Message-ID: <55CA5472.8020408@meetinghouse.net>

Marcin Cieslak wrote:
> O
>
> datacenterops.org is still available *hint*hint*
>
> ~Marcin

Doesn't look likes it's available any more.

In terms of building a critical mass, there do seem to be a goodly 
number of data center types on:
various forums at webhostingtalk.com
(probably) some of the support lists for various cloud stacks
the LISA and USENIX communities have some lists of sysadmin types

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra


From nanogml at Mail.DDoS-Mitigator.net  Tue Aug 11 20:25:32 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Tue, 11 Aug 2015 13:25:32 -0700
Subject: Data Center operations mail list?
In-Reply-To: <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
Message-ID: <20150811202532.GA23600@Mail.DDoS-Mitigator.net>


hi nanog

On 08/11/15 at 04:46pm, Alex Brooks wrote:
> With the lack of interest compared to NANOG (especially seeing how the
> old list simply dried up) it might be best making the list global
> rather than North America only to get the traffic levels up a bit.

there used to be an active "isp-xxx.com" decades ago
that was taken over by a commerical entity
- the "xxx" represented various topics
( security, infrastructure, colo, control panels, etc )

those domains are all dead .. i found these new url that may or 
may not be what you're looking for ... i didnt check it out
- https://lists.debian.org/debian-isp/
- http://lists.freebsd.org/mailman/listinfo/freebsd-isp
- http://www.reedmedia.net/lists/bsd-isp/

i'd like to see a NOC contact address for resolving
( DDoS ) issues coming from that ISP ... i'll help out if needed

the list of friendly co-operating NOC contracts probably need to be 
"member only protected" to protect it from being spam'd ?

pixie dust
alvin
# http://DDoS-Mitigator.net

From maillist at webjogger.net  Tue Aug 11 20:47:21 2015
From: maillist at webjogger.net (Adam Greene)
Date: Tue, 11 Aug 2015 16:47:21 -0400
Subject: Cogent revisited
In-Reply-To: <CAB2srOB6HQZGDrNx1xaM=x6b8OREu6x7yXadBcVwTwtCgmh_hA@mail.gmail.com>
References: <01bb01d0d43e$0fd8c630$2f8a5290$@webjogger.net>
 <CAB2srOB6HQZGDrNx1xaM=x6b8OREu6x7yXadBcVwTwtCgmh_hA@mail.gmail.com>
Message-ID: <011f01d0d476$eb8f4950$c2addbf0$@webjogger.net>

Thank you to those who replied off-list, for the helpful replies! 

 

The feedback basically ranged from neutral (maybe a little positive) to really negative. The main emphasis being on: use them only if you are redundant.

 

Seems like things haven?t changed much since 2012. 

 

Thanks!

 

On Aug 11, 2015 19:32, "Adam Greene" <maillist at webjogger.net <mailto:maillist at webjogger.net> > wrote:

Hi all,



We are getting ready to renew our fiber contract with our incumbent provider
(Lightower, ASN 46887). We are happy with them, but are looking for
alternatives. At the location in question we need about 200M.



Cogent recently contacted us, and I shied away a bit, based on this
conversation a few years ago:



http://mailman.nanog.org/pipermail/nanog/2012-May/048181.html



Have opinions changed since then? Or is Cogent still the "budget alternative
to have in your mix, but better to stay away from if you need
high-performance, reliable, mostly standalone bandwidth" (which is how I
would summarize the consensus in 2012)?



Thanks,

Adam









From colton.conor at gmail.com  Tue Aug 11 22:27:22 2015
From: colton.conor at gmail.com (Colton Conor)
Date: Tue, 11 Aug 2015 17:27:22 -0500
Subject: Branch Location Over The Internet
In-Reply-To: <f6e861bd1e734077992dc840ae5024a4@anx-i-dag01.anx.local>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
 <f6e861bd1e734077992dc840ae5024a4@anx-i-dag01.anx.local>
Message-ID: <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>

EoIP seems to be what I am looking for, however this recent Mikrotik
session says:

EoIP could be a solution for tunneling L2 over L3.
? EoIP disadvantages: ? Fragmentation of L2 frames over multiple L3 packets
? Performance issues ?
VPLS advantages: ? No fragmentation. ? 60% more performance then EoIP.

So it sounds like VPLS might be better than EoIP? I can't find much about
EoIP online, so is this a Mikrotik only protocol?

On Tue, Aug 11, 2015 at 1:46 PM, J?rgen Jaritsch <jj at anexia.at> wrote:

> Hi,
>
> Mikrotik Routerboard + (encrypted) Ethernet over IP (EoIP). If required:
> MPLS+OSPF+BGP in the EoIP for additional features.
>
> Build the pseudo Layer2 with two dedicated boxes. In the HQ you can hand
> it over directly to the MX80 and at the new office you can work with small
> boxes like Cisco 7301 (also available with redundant PS) or if you need
> more ports: 19xx ...
>
> #) cheap setup
> #) can easily transport a few hundred Meg
> #) you can use refurb parts if required
> #) big community support for Mikrotik Routerboards
> #) encrypted transport possible
> #) works with dynamic IPs
> #) MPLS in the EoIP allows you to transport VRFs with BGP signaling
>
> Etc etc
>
> Best regards
>
>
> J?rgen Jaritsch
> Head of Network & Infrastructure
>
> ANEXIA Internetdienstleistungs GmbH
>
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
>
> E-Mail: jj at anexia.at
> Web: http://www.anexia.at
>
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
> Gesch?ftsf?hrer: Alexander Windbichler
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT
> U63216601
>
>
>
> -----Original Message-----
> *From:* Colton Conor [colton.conor at gmail.com]
> *Received:* Dienstag, 11 Aug. 2015, 20:23
> *To:* NANOG [nanog at nanog.org]
> *Subject:* Branch Location Over The Internet
>
> We have an enterprise that has a headquarter office with redundant fiber
> connections, its own ASN, its own /22 IP block from ARIN, and a couple of
> gigabit internet connections from multiple providers. The office is taking
> full BGP routes from tier 1 providers using a Juniper MX80.
>
> They are establishing their first branch location, and need the branch
> location to be able to securely communicate back to headquarters, AND be
> able to use a /24 of  headquarters public IP addresses. Ideally the device
> at the HQ location would hand out public IP address using DHCP to the other
> side of the tunnel at the branch location.
>
> We know that in an ideal world it would be wise to get layer 2 transport
> connections from HQ to the branch location, but lets assume that is not an
> option. Please don't flood this thread about how it could be an option
> because it's not at this time. This setup will be temporary and in service
> for the next year until we get fiber to the branch site.
>
> Let's assume at the branch location we can get a DOCSIS cable internet
> connection from a incumbent cable provider such as Comcast, and that
> provider will give us a couple static IP address. Assume as a backup, we
> have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
> dynamic IP address.
>
> What solution could we put at the HQ site and the branch site to achieve
> this? Ideally we would want the solution to load balance between the
> connections based on the connections speeds, and failover if one is down.
> The cable connection will be much faster speed (probably 150Mbps down and
> 10 Upload) compared to the DSL connection (10 download and 1 upload). If we
> need more speed we can upgrade the cable modem to a higher package, but for
> DSL that is the max speed so we might have to get multiple DSL lines. The
> cable solution could always be used as the primary, and the DSL connection
> could only be used as backup if that makes things easier.
>
> If you were to do this with Juniper or Cisco gear what would you have at
> each location? What technology would you use?
>
> I know there is Pepewave and a couple of other software solutions that seem
> to have a proprietary load balancing solutions developed, but I would
> prefer to use a common Cisco or Juniper solution if one exists.
>
> There will be 50 users at the branch office. There is only one branch
> location at this time, but they might expand to a couple more but under 10.
>

From josh at imaginenetworksllc.com  Tue Aug 11 22:32:55 2015
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 11 Aug 2015 18:32:55 -0400
Subject: Branch Location Over The Internet
In-Reply-To: <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
 <f6e861bd1e734077992dc840ae5024a4@anx-i-dag01.anx.local>
 <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>
Message-ID: <CAN9qwJ_1VLsfaM1qOSqELN1Q0=3NgktQr8rip4pm+qzhJPWySQ@mail.gmail.com>

Eoip is Mikrotik only

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Aug 11, 2015 6:28 PM, "Colton Conor" <colton.conor at gmail.com> wrote:

> EoIP seems to be what I am looking for, however this recent Mikrotik
> session says:
>
> EoIP could be a solution for tunneling L2 over L3.
> ? EoIP disadvantages: ? Fragmentation of L2 frames over multiple L3 packets
> ? Performance issues ?
> VPLS advantages: ? No fragmentation. ? 60% more performance then EoIP.
>
> So it sounds like VPLS might be better than EoIP? I can't find much about
> EoIP online, so is this a Mikrotik only protocol?
>
> On Tue, Aug 11, 2015 at 1:46 PM, J?rgen Jaritsch <jj at anexia.at> wrote:
>
> > Hi,
> >
> > Mikrotik Routerboard + (encrypted) Ethernet over IP (EoIP). If required:
> > MPLS+OSPF+BGP in the EoIP for additional features.
> >
> > Build the pseudo Layer2 with two dedicated boxes. In the HQ you can hand
> > it over directly to the MX80 and at the new office you can work with
> small
> > boxes like Cisco 7301 (also available with redundant PS) or if you need
> > more ports: 19xx ...
> >
> > #) cheap setup
> > #) can easily transport a few hundred Meg
> > #) you can use refurb parts if required
> > #) big community support for Mikrotik Routerboards
> > #) encrypted transport possible
> > #) works with dynamic IPs
> > #) MPLS in the EoIP allows you to transport VRFs with BGP signaling
> >
> > Etc etc
> >
> > Best regards
> >
> >
> > J?rgen Jaritsch
> > Head of Network & Infrastructure
> >
> > ANEXIA Internetdienstleistungs GmbH
> >
> > Telefon: +43-5-0556-300
> > Telefax: +43-5-0556-500
> >
> > E-Mail: jj at anexia.at
> > Web: http://www.anexia.at
> >
> > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
> > Gesch?ftsf?hrer: Alexander Windbichler
> > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT
> > U63216601
> >
> >
> >
> > -----Original Message-----
> > *From:* Colton Conor [colton.conor at gmail.com]
> > *Received:* Dienstag, 11 Aug. 2015, 20:23
> > *To:* NANOG [nanog at nanog.org]
> > *Subject:* Branch Location Over The Internet
> >
> > We have an enterprise that has a headquarter office with redundant fiber
> > connections, its own ASN, its own /22 IP block from ARIN, and a couple of
> > gigabit internet connections from multiple providers. The office is
> taking
> > full BGP routes from tier 1 providers using a Juniper MX80.
> >
> > They are establishing their first branch location, and need the branch
> > location to be able to securely communicate back to headquarters, AND be
> > able to use a /24 of  headquarters public IP addresses. Ideally the
> device
> > at the HQ location would hand out public IP address using DHCP to the
> other
> > side of the tunnel at the branch location.
> >
> > We know that in an ideal world it would be wise to get layer 2 transport
> > connections from HQ to the branch location, but lets assume that is not
> an
> > option. Please don't flood this thread about how it could be an option
> > because it's not at this time. This setup will be temporary and in
> service
> > for the next year until we get fiber to the branch site.
> >
> > Let's assume at the branch location we can get a DOCSIS cable internet
> > connection from a incumbent cable provider such as Comcast, and that
> > provider will give us a couple static IP address. Assume as a backup, we
> > have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
> > dynamic IP address.
> >
> > What solution could we put at the HQ site and the branch site to achieve
> > this? Ideally we would want the solution to load balance between the
> > connections based on the connections speeds, and failover if one is down.
> > The cable connection will be much faster speed (probably 150Mbps down and
> > 10 Upload) compared to the DSL connection (10 download and 1 upload). If
> we
> > need more speed we can upgrade the cable modem to a higher package, but
> for
> > DSL that is the max speed so we might have to get multiple DSL lines. The
> > cable solution could always be used as the primary, and the DSL
> connection
> > could only be used as backup if that makes things easier.
> >
> > If you were to do this with Juniper or Cisco gear what would you have at
> > each location? What technology would you use?
> >
> > I know there is Pepewave and a couple of other software solutions that
> seem
> > to have a proprietary load balancing solutions developed, but I would
> > prefer to use a common Cisco or Juniper solution if one exists.
> >
> > There will be 50 users at the branch office. There is only one branch
> > location at this time, but they might expand to a couple more but under
> 10.
> >
>

From jj at anexia.at  Tue Aug 11 22:33:46 2015
From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=)
Date: Tue, 11 Aug 2015 22:33:46 +0000
Subject: AW: Branch Location Over The Internet
In-Reply-To: <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
 <f6e861bd1e734077992dc840ae5024a4@anx-i-dag01.anx.local>
 <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>
Message-ID: <52622d179cce4a00ad33018bb028a6b7@anx-i-dag01.anx.local>

Hi,

Some facts:

Dell R300, 1x Xeon CPU (Quadcore, 2,6GHz)
8GB Memory
Intel X520 10G NIC
RouterOS x86 installation (that?s the OS from the Mikrotik Routerboards)

Max transfer-rate via EoIP: ~5,7GBit/s

If you plan to use jumbo frames (everything with an payload >1500 byte): yes, packets will be split up, transferred and aggregated on the other end. So your end-to-end communication will transport ANY MTU size you want (splitted up to your max transportable MTU size on the WAN side ? eg MTU 1472, etc).



Best regards

J?rgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj at anexia.at<mailto:jj at anexia.at>
Web: http://www.anexia.at<http://www.anexia.at/>

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
Gesch?ftsf?hrer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Colton Conor [mailto:colton.conor at gmail.com]
Gesendet: Mittwoch, 12. August 2015 00:27
An: J?rgen Jaritsch <jj at anexia.at>
Cc: nanog at nanog.org
Betreff: Re: Branch Location Over The Internet

EoIP seems to be what I am looking for, however this recent Mikrotik session says:

EoIP could be a solution for tunneling L2 over L3.
? EoIP disadvantages: ? Fragmentation of L2 frames over multiple L3 packets ? Performance issues ?
VPLS advantages: ? No fragmentation. ? 60% more performance then EoIP.

So it sounds like VPLS might be better than EoIP? I can't find much about EoIP online, so is this a Mikrotik only protocol?

On Tue, Aug 11, 2015 at 1:46 PM, J?rgen Jaritsch <jj at anexia.at<mailto:jj at anexia.at>> wrote:
Hi,

Mikrotik Routerboard + (encrypted) Ethernet over IP (EoIP). If required: MPLS+OSPF+BGP in the EoIP for additional features.

Build the pseudo Layer2 with two dedicated boxes. In the HQ you can hand it over directly to the MX80 and at the new office you can work with small boxes like Cisco 7301 (also available with redundant PS) or if you need more ports: 19xx ...

#) cheap setup
#) can easily transport a few hundred Meg
#) you can use refurb parts if required
#) big community support for Mikrotik Routerboards
#) encrypted transport possible
#) works with dynamic IPs
#) MPLS in the EoIP allows you to transport VRFs with BGP signaling

Etc etc

Best regards


J?rgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj at anexia.at<mailto:jj at anexia.at>
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
Gesch?ftsf?hrer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601



-----Original Message-----
From: Colton Conor [colton.conor at gmail.com<mailto:colton.conor at gmail.com>]
Received: Dienstag, 11 Aug. 2015, 20:23
To: NANOG [nanog at nanog.org<mailto:nanog at nanog.org>]
Subject: Branch Location Over The Internet
We have an enterprise that has a headquarter office with redundant fiber
connections, its own ASN, its own /22 IP block from ARIN, and a couple of
gigabit internet connections from multiple providers. The office is taking
full BGP routes from tier 1 providers using a Juniper MX80.

They are establishing their first branch location, and need the branch
location to be able to securely communicate back to headquarters, AND be
able to use a /24 of  headquarters public IP addresses. Ideally the device
at the HQ location would hand out public IP address using DHCP to the other
side of the tunnel at the branch location.

We know that in an ideal world it would be wise to get layer 2 transport
connections from HQ to the branch location, but lets assume that is not an
option. Please don't flood this thread about how it could be an option
because it's not at this time. This setup will be temporary and in service
for the next year until we get fiber to the branch site.

Let's assume at the branch location we can get a DOCSIS cable internet
connection from a incumbent cable provider such as Comcast, and that
provider will give us a couple static IP address. Assume as a backup, we
have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
dynamic IP address.

What solution could we put at the HQ site and the branch site to achieve
this? Ideally we would want the solution to load balance between the
connections based on the connections speeds, and failover if one is down.
The cable connection will be much faster speed (probably 150Mbps down and
10 Upload) compared to the DSL connection (10 download and 1 upload). If we
need more speed we can upgrade the cable modem to a higher package, but for
DSL that is the max speed so we might have to get multiple DSL lines. The
cable solution could always be used as the primary, and the DSL connection
could only be used as backup if that makes things easier.

If you were to do this with Juniper or Cisco gear what would you have at
each location? What technology would you use?

I know there is Pepewave and a couple of other software solutions that seem
to have a proprietary load balancing solutions developed, but I would
prefer to use a common Cisco or Juniper solution if one exists.

There will be 50 users at the branch office. There is only one branch
location at this time, but they might expand to a couple more but under 10.


From plucena at coopergeneral.com  Wed Aug 12 00:01:16 2015
From: plucena at coopergeneral.com (Pablo Lucena)
Date: Tue, 11 Aug 2015 20:01:16 -0400
Subject: Branch Location Over The Internet
In-Reply-To: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
Message-ID: <CAH+2GVLnK=mcOYzj=xuipOf4wsnpmNtnW64uXFkvPvDyZPpifA@mail.gmail.com>

DMVPN is very flexible, and is designed for this type of scenario. Cisco
definitely supports it. Not sure about Juniper, but its essentially mGRE +
NHRP. You can use IPSec to encrypt the tunnels, and if you require
spoke-to-spoke connectivity, there are some optimizations in Phase-3 DMVPN
that make it scalable. I would recommend using BGP as the routing protocol
in this type of setup as well. Newer versions of Cisco code support
"next-hop-self all", which will allow you to use iBGP between HQ and the
branches without having to complicate the config too much.

LISP is also a great solution. Its supported across the Cisco product line,
and there are other open source implementations. This really simplifies
your routing, as you can just rely on static default routes into the
"internet" at each branch, and allow LISP to take care of the rest. You can
also use encryption ontop of it.

Not sure why you think it would be ideal to have a Layer-2 solution...I
would personally stay away from it for this type of setup.

Regards,

Pablo


On Tue, Aug 11, 2015 at 2:21 PM, Colton Conor <colton.conor at gmail.com>
wrote:

> We have an enterprise that has a headquarter office with redundant fiber
> connections, its own ASN, its own /22 IP block from ARIN, and a couple of
> gigabit internet connections from multiple providers. The office is taking
> full BGP routes from tier 1 providers using a Juniper MX80.
>
> They are establishing their first branch location, and need the branch
> location to be able to securely communicate back to headquarters, AND be
> able to use a /24 of  headquarters public IP addresses. Ideally the device
> at the HQ location would hand out public IP address using DHCP to the other
> side of the tunnel at the branch location.
>
> We know that in an ideal world it would be wise to get layer 2 transport
> connections from HQ to the branch location, but lets assume that is not an
> option. Please don't flood this thread about how it could be an option
> because it's not at this time. This setup will be temporary and in service
> for the next year until we get fiber to the branch site.
>
> Let's assume at the branch location we can get a DOCSIS cable internet
> connection from a incumbent cable provider such as Comcast, and that
> provider will give us a couple static IP address. Assume as a backup, we
> have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
> dynamic IP address.
>
> What solution could we put at the HQ site and the branch site to achieve
> this? Ideally we would want the solution to load balance between the
> connections based on the connections speeds, and failover if one is down.
> The cable connection will be much faster speed (probably 150Mbps down and
> 10 Upload) compared to the DSL connection (10 download and 1 upload). If we
> need more speed we can upgrade the cable modem to a higher package, but for
> DSL that is the max speed so we might have to get multiple DSL lines. The
> cable solution could always be used as the primary, and the DSL connection
> could only be used as backup if that makes things easier.
>
> If you were to do this with Juniper or Cisco gear what would you have at
> each location? What technology would you use?
>
> I know there is Pepewave and a couple of other software solutions that seem
> to have a proprietary load balancing solutions developed, but I would
> prefer to use a common Cisco or Juniper solution if one exists.
>
> There will be 50 users at the branch office. There is only one branch
> location at this time, but they might expand to a couple more but under 10.
>

From the.lists at mgm51.com  Wed Aug 12 00:10:27 2015
From: the.lists at mgm51.com (Mike)
Date: Tue, 11 Aug 2015 20:10:27 -0400
Subject: Data Center operations mail list?
In-Reply-To: <20150811192715.GB2558@dilbert.slimey.org>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
Message-ID: <55CA8EF3.6050408@mgm51.com>

On 8/11/2015 3:27 PM, Simon Lockhart wrote:
> On Tue Aug 11, 2015 at 01:35:28pm -0400, Jay Ashworth wrote:
>> Absolutely feel free to use it; I haven't seen a single message on it in...
>> well, it was 3 years ago I was in datacenters regularly, so I'm goin with
>> "3 years".  :-)
> 
> There's a message there now... :)
> 
> Rather than fragmenting further, I'd suggest building up demand first on
> existing infrastructure. If it gets to the size of NANOG and needing a
> support organisation around it, then it can split off then...
> 
> Simon
> 


At some point (hopefully sooner than later) the OP should just move
forward in some manner with the concept.

If I've learned anything about mailing lists in the past 35+ years,
things will be discussed and discussed and discussed and...


Parkinson's Law of Triviality comes to mind...
http://www.greatleadershipbydan.com/2012/12/parkinsons-law-of-triviality.html

From rafael at gav.ufsc.br  Wed Aug 12 00:15:52 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Tue, 11 Aug 2015 19:15:52 -0500
Subject: Data Center operations mail list?
In-Reply-To: <55CA8EF3.6050408@mgm51.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org> <55CA8EF3.6050408@mgm51.com>
Message-ID: <CAJB2g-HuLc_ENXXY+67hRQ5ubFzb0NXhte75C6NQCHYRjROmVw@mail.gmail.com>

The list just went live at "lists.nadcog.org". I am open to any
suggestions, just let me know. When you say move forward with the concept,
do you mean get the organization started as well, not just the mailing list?


Thanks,
Rafael


On Tue, Aug 11, 2015 at 7:10 PM, Mike <the.lists at mgm51.com> wrote:

> On 8/11/2015 3:27 PM, Simon Lockhart wrote:
> > On Tue Aug 11, 2015 at 01:35:28pm -0400, Jay Ashworth wrote:
> >> Absolutely feel free to use it; I haven't seen a single message on it
> in...
> >> well, it was 3 years ago I was in datacenters regularly, so I'm goin
> with
> >> "3 years".  :-)
> >
> > There's a message there now... :)
> >
> > Rather than fragmenting further, I'd suggest building up demand first on
> > existing infrastructure. If it gets to the size of NANOG and needing a
> > support organisation around it, then it can split off then...
> >
> > Simon
> >
>
>
> At some point (hopefully sooner than later) the OP should just move
> forward in some manner with the concept.
>
> If I've learned anything about mailing lists in the past 35+ years,
> things will be discussed and discussed and discussed and...
>
>
> Parkinson's Law of Triviality comes to mind...
>
> http://www.greatleadershipbydan.com/2012/12/parkinsons-law-of-triviality.html
>

From nanog at ics-il.net  Wed Aug 12 00:50:24 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 11 Aug 2015 19:50:24 -0500 (CDT)
Subject: Branch Location Over The Internet
In-Reply-To: <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>
Message-ID: <861436159.6886.1439340647030.JavaMail.mhammett@ThunderFuck>

EoIP will tunnel over anything IP, including the public Internet. VPLS will only go over your network. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 



----- Original Message -----

From: "Colton Conor" <colton.conor at gmail.com> 
To: "J?rgen Jaritsch" <jj at anexia.at> 
Cc: nanog at nanog.org 
Sent: Tuesday, August 11, 2015 5:27:22 PM 
Subject: Re: Branch Location Over The Internet 

EoIP seems to be what I am looking for, however this recent Mikrotik 
session says: 

EoIP could be a solution for tunneling L2 over L3. 
? EoIP disadvantages: ? Fragmentation of L2 frames over multiple L3 packets 
? Performance issues ? 
VPLS advantages: ? No fragmentation. ? 60% more performance then EoIP. 

So it sounds like VPLS might be better than EoIP? I can't find much about 
EoIP online, so is this a Mikrotik only protocol? 

On Tue, Aug 11, 2015 at 1:46 PM, J?rgen Jaritsch <jj at anexia.at> wrote: 

> Hi, 
> 
> Mikrotik Routerboard + (encrypted) Ethernet over IP (EoIP). If required: 
> MPLS+OSPF+BGP in the EoIP for additional features. 
> 
> Build the pseudo Layer2 with two dedicated boxes. In the HQ you can hand 
> it over directly to the MX80 and at the new office you can work with small 
> boxes like Cisco 7301 (also available with redundant PS) or if you need 
> more ports: 19xx ... 
> 
> #) cheap setup 
> #) can easily transport a few hundred Meg 
> #) you can use refurb parts if required 
> #) big community support for Mikrotik Routerboards 
> #) encrypted transport possible 
> #) works with dynamic IPs 
> #) MPLS in the EoIP allows you to transport VRFs with BGP signaling 
> 
> Etc etc 
> 
> Best regards 
> 
> 
> J?rgen Jaritsch 
> Head of Network & Infrastructure 
> 
> ANEXIA Internetdienstleistungs GmbH 
> 
> Telefon: +43-5-0556-300 
> Telefax: +43-5-0556-500 
> 
> E-Mail: jj at anexia.at 
> Web: http://www.anexia.at 
> 
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt 
> Gesch?ftsf?hrer: Alexander Windbichler 
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT 
> U63216601 
> 
> 
> 
> -----Original Message----- 
> *From:* Colton Conor [colton.conor at gmail.com] 
> *Received:* Dienstag, 11 Aug. 2015, 20:23 
> *To:* NANOG [nanog at nanog.org] 
> *Subject:* Branch Location Over The Internet 
> 
> We have an enterprise that has a headquarter office with redundant fiber 
> connections, its own ASN, its own /22 IP block from ARIN, and a couple of 
> gigabit internet connections from multiple providers. The office is taking 
> full BGP routes from tier 1 providers using a Juniper MX80. 
> 
> They are establishing their first branch location, and need the branch 
> location to be able to securely communicate back to headquarters, AND be 
> able to use a /24 of headquarters public IP addresses. Ideally the device 
> at the HQ location would hand out public IP address using DHCP to the other 
> side of the tunnel at the branch location. 
> 
> We know that in an ideal world it would be wise to get layer 2 transport 
> connections from HQ to the branch location, but lets assume that is not an 
> option. Please don't flood this thread about how it could be an option 
> because it's not at this time. This setup will be temporary and in service 
> for the next year until we get fiber to the branch site. 
> 
> Let's assume at the branch location we can get a DOCSIS cable internet 
> connection from a incumbent cable provider such as Comcast, and that 
> provider will give us a couple static IP address. Assume as a backup, we 
> have a PPPoE DSL connection from the ILEC such as Verizon who gives us a 
> dynamic IP address. 
> 
> What solution could we put at the HQ site and the branch site to achieve 
> this? Ideally we would want the solution to load balance between the 
> connections based on the connections speeds, and failover if one is down. 
> The cable connection will be much faster speed (probably 150Mbps down and 
> 10 Upload) compared to the DSL connection (10 download and 1 upload). If we 
> need more speed we can upgrade the cable modem to a higher package, but for 
> DSL that is the max speed so we might have to get multiple DSL lines. The 
> cable solution could always be used as the primary, and the DSL connection 
> could only be used as backup if that makes things easier. 
> 
> If you were to do this with Juniper or Cisco gear what would you have at 
> each location? What technology would you use? 
> 
> I know there is Pepewave and a couple of other software solutions that seem 
> to have a proprietary load balancing solutions developed, but I would 
> prefer to use a common Cisco or Juniper solution if one exists. 
> 
> There will be 50 users at the branch office. There is only one branch 
> location at this time, but they might expand to a couple more but under 10. 
> 


From michael.bubb at gmail.com  Wed Aug 12 02:06:19 2015
From: michael.bubb at gmail.com (Michael Bubb)
Date: Tue, 11 Aug 2015 22:06:19 -0400
Subject: advice dealing with clean-mx
Message-ID: <CAKib_RDkirqW-_L=EqYeYtQE8z_UR_SRZFyFzX=zURB+8VDtpg@mail.gmail.com>

hello

I've lurked on this list for a while - I have an issue that I need help
with.

I work for a company that does fraud detection we host our servers on
physica hardware in managed hosting datacenters (softlayer, hertzer,
coresites, etc).

Recently we were flagged for malware buy clean-mx. It was the IP of an
haproxy loadbalancer.

I followed up by following the link to clean-mx. It looked as if the score
was based upon information from the following sites:

http://www.malwaredomainlist.com
https://www.virustotal.com
http://urlquery.net

When I checked the ip in question against these sites all the checks passed
exceptfor one -  fortinet. And fortinet indicated that it was an unknown
signature - not specifically malware.

So it appeared clean.

I am hesitant to deal directly with clean-mx as we do not have any existing
relationship and frankly a google search turns up many horror stories.

I am mindful that these may be the 'stories' of frustrated fraudsters.

I honestly do not know how to evaluate this situation. If clean-mx is legit
then it would make sense to have a relationship with them .  If they are
not then how does one deal with them?

thank you

Michael

-- 
Michael Bubb   +1.646.783.8769 | KD2DTY
Resume - http://mbubb.devio.us/res/resume.html

 *noli timere*

From fergdawgster at mykolab.com  Wed Aug 12 02:23:00 2015
From: fergdawgster at mykolab.com (Paul Ferguson)
Date: Tue, 11 Aug 2015 19:23:00 -0700
Subject: advice dealing with clean-mx
In-Reply-To: <CAKib_RDkirqW-_L=EqYeYtQE8z_UR_SRZFyFzX=zURB+8VDtpg@mail.gmail.com>
References: <CAKib_RDkirqW-_L=EqYeYtQE8z_UR_SRZFyFzX=zURB+8VDtpg@mail.gmail.com>
Message-ID: <55CAAE04.2070807@mykolab.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Follow-up off-list.

- - ferg


On 8/11/2015 7:06 PM, Michael Bubb wrote:

> hello
> 
> I've lurked on this list for a while - I have an issue that I need 
> help with.
> 
> I work for a company that does fraud detection we host our servers 
> on physica hardware in managed hosting datacenters (softlayer, 
> hertzer, coresites, etc).
> 
> Recently we were flagged for malware buy clean-mx. It was the IP
> of an haproxy loadbalancer.
> 
> I followed up by following the link to clean-mx. It looked as if 
> the score was based upon information from the following sites:
> 
> http://www.malwaredomainlist.com https://www.virustotal.com 
> http://urlquery.net
> 
> When I checked the ip in question against these sites all the 
> checks passed exceptfor one -  fortinet. And fortinet indicated 
> that it was an unknown signature - not specifically malware.
> 
> So it appeared clean.
> 
> I am hesitant to deal directly with clean-mx as we do not have any 
> existing relationship and frankly a google search turns up many 
> horror stories.
> 
> I am mindful that these may be the 'stories' of frustrated 
> fraudsters.
> 
> I honestly do not know how to evaluate this situation. If clean-mx 
> is legit then it would make sense to have a relationship with them 
> .  If they are not then how does one deal with them?
> 
> thank you
> 
> Michael
> 


- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXKrgQACgkQKJasdVTchbItgQEAu5l1e8I7wJlLhi8Pweka18T+
Lo93urUoy9lipfag9yEBAMvlKpULyLCtCbUGzneqQhP367wn8TFJFpdpvdufTdIe
=xPEu
-----END PGP SIGNATURE-----

From randy at psg.com  Wed Aug 12 03:12:26 2015
From: randy at psg.com (Randy Bush)
Date: Wed, 12 Aug 2015 12:12:26 +0900
Subject: Data Center operations mail list?
In-Reply-To: <20150811192715.GB2558@dilbert.slimey.org>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
Message-ID: <m27fp1ci91.wl%randy@psg.com>

> Rather than fragmenting further, I'd suggest building up demand first
> on existing infrastructure. If it gets to the size of NANOG and
> needing a support organisation around it, then it can split off
> then...

no!  we need committees, and different colored badges, and web sites,
and deadlines, and lots of stuff the insecure can put on their resumes.

randy

From mtaylor at mty.net.au  Wed Aug 12 03:26:17 2015
From: mtaylor at mty.net.au (Matt Taylor)
Date: Wed, 12 Aug 2015 13:26:17 +1000
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <55CA17CB.6020308@wholesaleinternet.net>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
 <4695.1439255263@turing-police.cc.vt.edu> <55C94FB2.6070900@mykolab.com>
 <55C992DE.3020906@yahoo.fr> <9889B2E9-FB43-4252-84F9-F633AEF4E588@enzu.com>
 <55CA17CB.6020308@wholesaleinternet.net>
Message-ID: <55CABCD9.2020703@mty.net.au>

I have not experienced any problems with multiple source attacks at the 
same time. This is also including with multiple destinations too.

I guess it really depends on what you expect the product to do, and how 
you write integration too.

Regards,
Matt.

On 12/08/2015 01:42, Aaron wrote:
> We tested it a while back and found that it was fine for single source
> attacks but fell over with multiple sources.  Has that changed?
>
>
>
> On 8/11/2015 9:42 AM, Nick Rose wrote:
>> We have processed just under a million anomalies with this software,
>> we use the Chelsio cards for filtering. We had some troubles with
>> packet loss on the filter side until we started using those which were
>> a new feature in the latest release.
>>
>> If you have any questions I would be happy to answer them.
>>
>> Regards,
>> Nick Rose | CTO
>> Enzu Inc
>> nick.rose at enzu.com
>> www.enzu.com <http://www.enzu.com/>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 8/11/15, 2:14 AM, "NANOG on behalf of marcel.duregards at yahoo.fr"
>> <nanog-bounces at nanog.org on behalf of marcel.duregards at yahoo.fr> wrote:
>>
>>> anybody from this impressive list ?:
>>>
>>> https://www.andrisoft.com/company/customers
>>>
>>> -- Marcel
>>>
>>>
>>>
>>> On 11.08.2015 03:28, Paul Ferguson wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> On 8/10/2015 6:07 PM, Valdis.Kletnieks at vt.edu wrote:
>>>>
>>>>> On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said:
>>>>>
>>>>>> Once setup correctly. very good product - it's been running for 8
>>>>>> months now and hasn't had any issues. It's been very reliable.
>>>>> I'll bite - (roughly) how many times has it triggered and mitigated
>>>>> an actual DDoS during those 8 months?  We probably draw different
>>>>> conclusions from "8 months and 1 DDoS" reliable and "8 months of
>>>>> 5-a-week" reliable...
>>>>>
>>>>
>>>> I think that would definitely depend on how the network is base-lined.
>>>>
>>>> That is sometimes more of an art than a science. :-)
>>>>
>>>> - - ferg
>>>>
>>>>
>>>> - --
>>>> Paul Ferguson
>>>> PGP Public Key ID: 0x54DC85B2
>>>> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v2
>>>>
>>>> iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe
>>>> 70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP
>>>> =d7d1
>>>> -----END PGP SIGNATURE-----
>>>>
>

From rafael at gav.ufsc.br  Wed Aug 12 04:00:04 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Tue, 11 Aug 2015 23:00:04 -0500
Subject: Data Center operations mail list?
In-Reply-To: <m27fp1ci91.wl%randy@psg.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org> <m27fp1ci91.wl%randy@psg.com>
Message-ID: <CAJB2g-H2JNwNYh=B0D0V2h_fNtOY71kk8Bqr3--1mRPT9sfm1A@mail.gmail.com>

Haha, are you saying some people out there put nanog on their resume? I
thought 2008 was long gone.

On Tue, Aug 11, 2015 at 10:12 PM, Randy Bush <randy at psg.com> wrote:

> > Rather than fragmenting further, I'd suggest building up demand first
> > on existing infrastructure. If it gets to the size of NANOG and
> > needing a support organisation around it, then it can split off
> > then...
>
> no!  we need committees, and different colored badges, and web sites,
> and deadlines, and lots of stuff the insecure can put on their resumes.
>
> randy
>

From marcel.duregards at yahoo.fr  Wed Aug 12 04:49:02 2015
From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr)
Date: Wed, 12 Aug 2015 06:49:02 +0200
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <55CA17CB.6020308@wholesaleinternet.net>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
 <CALgsdbcLEMxBtoLhTchN8ioC68VZnzrkcRCbv1ouzO6dRnyArw@mail.gmail.com>
 <20150810141014.GP30897@Vurt.local> <55C92FB9.10402@spectrum.com.au>
 <CALf9hzBCG1Hiq-_w41-CwS_c8nz=m0MMoQqyUz7X63tS2tpkNg@mail.gmail.com>
 <4695.1439255263@turing-police.cc.vt.edu> <55C94FB2.6070900@mykolab.com>
 <55C992DE.3020906@yahoo.fr> <9889B2E9-FB43-4252-84F9-F633AEF4E588@enzu.com>
 <55CA17CB.6020308@wholesaleinternet.net>
Message-ID: <55CAD03E.90407@yahoo.fr>

Aaron,

Do you remember which release or when it was ?
Are you talking about detection or filtering which failed for many 
sources targeting a single destination ?
Which sensor did you test, packet sensor or flow sensor ?

Thank,
Regards,
- Marcel


On 11.08.2015 17:42, Aaron wrote:
> We tested it a while back and found that it was fine for single source
> attacks but fell over with multiple sources.  Has that changed?
>
>
>
> On 8/11/2015 9:42 AM, Nick Rose wrote:
>> We have processed just under a million anomalies with this software,
>> we use the Chelsio cards for filtering. We had some troubles with
>> packet loss on the filter side until we started using those which were
>> a new feature in the latest release.
>>
>> If you have any questions I would be happy to answer them.
>>
>> Regards,
>> Nick Rose | CTO
>> Enzu Inc
>> nick.rose at enzu.com
>> www.enzu.com <http://www.enzu.com/>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 8/11/15, 2:14 AM, "NANOG on behalf of marcel.duregards at yahoo.fr"
>> <nanog-bounces at nanog.org on behalf of marcel.duregards at yahoo.fr> wrote:
>>
>>> anybody from this impressive list ?:
>>>
>>> https://www.andrisoft.com/company/customers
>>>
>>> -- Marcel
>>>
>>>
>>>
>>> On 11.08.2015 03:28, Paul Ferguson wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> On 8/10/2015 6:07 PM, Valdis.Kletnieks at vt.edu wrote:
>>>>
>>>>> On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said:
>>>>>
>>>>>> Once setup correctly. very good product - it's been running for 8
>>>>>> months now and hasn't had any issues. It's been very reliable.
>>>>> I'll bite - (roughly) how many times has it triggered and mitigated
>>>>> an actual DDoS during those 8 months?  We probably draw different
>>>>> conclusions from "8 months and 1 DDoS" reliable and "8 months of
>>>>> 5-a-week" reliable...
>>>>>
>>>>
>>>> I think that would definitely depend on how the network is base-lined.
>>>>
>>>> That is sometimes more of an art than a science. :-)
>>>>
>>>> - - ferg
>>>>
>>>>
>>>> - --
>>>> Paul Ferguson
>>>> PGP Public Key ID: 0x54DC85B2
>>>> Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v2
>>>>
>>>> iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe
>>>> 70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP
>>>> =d7d1
>>>> -----END PGP SIGNATURE-----
>>>>
>

From mark.tinka at seacom.mu  Wed Aug 12 06:26:12 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 12 Aug 2015 08:26:12 +0200
Subject: Cogent revisited
In-Reply-To: <01bb01d0d43e$0fd8c630$2f8a5290$@webjogger.net>
References: <01bb01d0d43e$0fd8c630$2f8a5290$@webjogger.net>
Message-ID: <55CAE704.2040108@seacom.mu>



On 11/Aug/15 16:00, Adam Greene wrote:
>  
>
> Have opinions changed since then? Or is Cogent still the "budget alternative
> to have in your mix, but better to stay away from if you need
> high-performance, reliable, mostly standalone bandwidth" (which is how I
> would summarize the consensus in 2012)?

We use Cogent. No major drama. Then again, we have 7x of the top global
providers in the mix.

My take is if you want to be single-homed, buy from a network slightly
lower in the chain to the top providers. They'll have a good blend.

If you want to buy from Cogent, buy from a slightly smaller ISP as well,
or add one or two other global providers into your mix. I'd do this
anyway, whether it was Cogent or not.

Mark.

From randy at psg.com  Wed Aug 12 06:33:26 2015
From: randy at psg.com (Randy Bush)
Date: Wed, 12 Aug 2015 15:33:26 +0900
Subject: router dump and config
Message-ID: <m2bnedaudl.wl%randy@psg.com>

[ uncast reply please, unless you just wanna tell me to foad publicly,
  which is fine ]

purely for research, and we promise to destroy after.  would appreciate
   one router config (passwords/credentials removed, of course)
   rib dump from that router (we can process C or J)
which has a number of large tier-1 peers

we are not really looking at peering or anything such as that.  no
politics or business involved at all.  it's about ACL load, RPKI
simulation, ...

thanks

randy

From mark.tinka at seacom.mu  Wed Aug 12 06:34:36 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 12 Aug 2015 08:34:36 +0200
Subject: Data Center operations mail list?
In-Reply-To: <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
Message-ID: <55CAE8FC.6060405@seacom.mu>



On 11/Aug/15 17:46, Alex Brooks wrote:
> With the lack of interest compared to NANOG (especially seeing how the
> old list simply dried up) it might be best making the list global
> rather than North America only to get the traffic levels up a bit.

Tend to agree that a list with global scope might be more useful.

Mark.

From jwbensley at gmail.com  Wed Aug 12 09:02:50 2015
From: jwbensley at gmail.com (James Bensley)
Date: Wed, 12 Aug 2015 10:02:50 +0100
Subject: Cogent revisited
In-Reply-To: <011f01d0d476$eb8f4950$c2addbf0$@webjogger.net>
References: <01bb01d0d43e$0fd8c630$2f8a5290$@webjogger.net>
 <CAB2srOB6HQZGDrNx1xaM=x6b8OREu6x7yXadBcVwTwtCgmh_hA@mail.gmail.com>
 <011f01d0d476$eb8f4950$c2addbf0$@webjogger.net>
Message-ID: <CAAWx_pWn1nXLkFcsNvBTf8BCOg_4gWvLs9v2nsZvQf9KP7-hEg@mail.gmail.com>

On 11 August 2015 at 21:47, Adam Greene <maillist at webjogger.net> wrote:

Perhaps that depends on were are you in the world and your traffic types.

I have worked with two UK ISPs that have Cogent as one of their
transit providers, neither have had any problems in the 5+ years
they've both had the Cogent transit, it has always "just worked".


Cheers,
James.

From rafael at gav.ufsc.br  Wed Aug 12 12:33:05 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Wed, 12 Aug 2015 07:33:05 -0500
Subject: Data Center operations mail list?
In-Reply-To: <55CAE8FC.6060405@seacom.mu>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
Message-ID: <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>

I was actually surprised with how many people subscribed already. I think
we are close to 100 already in less than 24 hours.

I could use some help drafting some basic mailing list rules (no spam, no
soliciting, etc) and if anyone has any suggestions, please let me know.


On Wed, Aug 12, 2015 at 1:34 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 11/Aug/15 17:46, Alex Brooks wrote:
> > With the lack of interest compared to NANOG (especially seeing how the
> > old list simply dried up) it might be best making the list global
> > rather than North America only to get the traffic levels up a bit.
>
> Tend to agree that a list with global scope might be more useful.
>
> Mark.
>

From oliver.oboyle at gmail.com  Wed Aug 12 12:53:25 2015
From: oliver.oboyle at gmail.com (Oliver O'Boyle)
Date: Wed, 12 Aug 2015 08:53:25 -0400
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
Message-ID: <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>

I missed the subscription info. Can you repost please? I can be #100 :)

On Wed, Aug 12, 2015 at 8:33 AM, Rafael Possamai <rafael at gav.ufsc.br> wrote:

> I was actually surprised with how many people subscribed already. I think
> we are close to 100 already in less than 24 hours.
>
> I could use some help drafting some basic mailing list rules (no spam, no
> soliciting, etc) and if anyone has any suggestions, please let me know.
>
>
> On Wed, Aug 12, 2015 at 1:34 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
> >
> >
> > On 11/Aug/15 17:46, Alex Brooks wrote:
> > > With the lack of interest compared to NANOG (especially seeing how the
> > > old list simply dried up) it might be best making the list global
> > > rather than North America only to get the traffic levels up a bit.
> >
> > Tend to agree that a list with global scope might be more useful.
> >
> > Mark.
> >
>



-- 
:o@>

From ramy.ihashish at gmail.com  Wed Aug 12 14:28:47 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Wed, 12 Aug 2015 17:28:47 +0300
Subject: Experience on Wanguard for 'anti' DDOS solutions
Message-ID: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>

>
>
> Date: Tue, 11 Aug 2015 08:14:54 +0200
> From: "marcel.duregards at yahoo.fr" <marcel.duregards at yahoo.fr>
> To: nanog at nanog.org
> Subject: Re: Experience on Wanguard for 'anti' DDOS solutions
> Message-ID: <55C992DE.3020906 at yahoo.fr>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> anybody from this impressive list ?:
>
> https://www.andrisoft.com/company/customers
>
> -- Marcel
>
>
>
Anybody here compared Wanguard's performance with the DDoS vendors in the
market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?

Another question, have anybody from the reviewers tested the false
positives of the box, or experienced any false positive incidents?

Thanks,

Ramy

From cboyd at gizmopartners.com  Wed Aug 12 14:36:45 2015
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Wed, 12 Aug 2015 09:36:45 -0500
Subject: Data Center operations mail list?
In-Reply-To: <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
Message-ID: <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>


> On Aug 12, 2015, at 7:53 AM, Oliver O'Boyle <oliver.oboyle at gmail.com> wrote:
> 
> I missed the subscription info. Can you repost please? I can be #100 :)

http://lists.nadcog.org

Welcome aboard.

?Chris


From oliver.oboyle at gmail.com  Wed Aug 12 14:40:46 2015
From: oliver.oboyle at gmail.com (Oliver O'Boyle)
Date: Wed, 12 Aug 2015 10:40:46 -0400
Subject: Data Center operations mail list?
In-Reply-To: <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
Message-ID: <CAMOPTEyZba4R24sBO5Ji50d09eBOd61XyLn7px_nrPuBuc=w1w@mail.gmail.com>

Done, thanks!

On Wed, Aug 12, 2015 at 10:36 AM, Chris Boyd <cboyd at gizmopartners.com>
wrote:

>
> > On Aug 12, 2015, at 7:53 AM, Oliver O'Boyle <oliver.oboyle at gmail.com>
> wrote:
> >
> > I missed the subscription info. Can you repost please? I can be #100 :)
>
> http://lists.nadcog.org
>
> Welcome aboard.
>
> ?Chris
>
>


-- 
:o@>

From rwebb at ropeguru.com  Wed Aug 12 15:28:47 2015
From: rwebb at ropeguru.com (Robert Webb)
Date: Wed, 12 Aug 2015 11:28:47 -0400
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com><BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com><CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com><2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc><alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb><CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com><55CAE8FC.6060405@seacom.mu><CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
Message-ID: <ximss-516184@mail.ropeguru.com>

Interesting... I just went to the web site to subscribe and I received an 
email that I was already subscribed.

I don't remember doing that... So how did this happen??

Robert

On Wed, 12 Aug 2015 07:33:05 -0500
  Rafael Possamai <rafael at gav.ufsc.br> wrote:
> I was actually surprised with how many people subscribed already. I 
>think
> we are close to 100 already in less than 24 hours.
> 
> I could use some help drafting some basic mailing list rules (no 
>spam, no
> soliciting, etc) and if anyone has any suggestions, please let me 
>know.
> 
> 
> On Wed, Aug 12, 2015 at 1:34 AM, Mark Tinka <mark.tinka at seacom.mu> 
>wrote:
> 
>>
>> On 11/Aug/15 17:46, Alex Brooks wrote:
>> > With the lack of interest compared to NANOG (especially seeing how 
>>the
>> > old list simply dried up) it might be best making the list global
>> > rather than North America only to get the traffic levels up a bit.
>>
>> Tend to agree that a list with global scope might be more useful.
>>
>> Mark.
>>



From fdelmotte1 at mac.com  Wed Aug 12 15:42:37 2015
From: fdelmotte1 at mac.com (Fabien Delmotte)
Date: Wed, 12 Aug 2015 17:42:37 +0200
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
References: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
Message-ID: <AEAE5C0D-FE2F-4542-B237-159BF09671A9@mac.com>

Hello

My 2 cents
You can use Wanguard for the detection and A10 for the mitigation, you have just to play with the API.

Regards

Fabien

> Le 12 ao?t 2015 ? 16:28, Ramy Hashish <ramy.ihashish at gmail.com> a ?crit :
> 
>> 
>> 
>> Date: Tue, 11 Aug 2015 08:14:54 +0200
>> From: "marcel.duregards at yahoo.fr" <marcel.duregards at yahoo.fr>
>> To: nanog at nanog.org
>> Subject: Re: Experience on Wanguard for 'anti' DDOS solutions
>> Message-ID: <55C992DE.3020906 at yahoo.fr>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>> 
>> anybody from this impressive list ?:
>> 
>> https://www.andrisoft.com/company/customers
>> 
>> -- Marcel
>> 
>> 
>> 
> Anybody here compared Wanguard's performance with the DDoS vendors in the
> market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?
> 
> Another question, have anybody from the reviewers tested the false
> positives of the box, or experienced any false positive incidents?
> 
> Thanks,
> 
> Ramy


From z at amused.net  Tue Aug 11 22:49:26 2015
From: z at amused.net (Patrick Cole)
Date: Wed, 12 Aug 2015 08:49:26 +1000
Subject: Branch Location Over The Internet
In-Reply-To: <CAN9qwJ_1VLsfaM1qOSqELN1Q0=3NgktQr8rip4pm+qzhJPWySQ@mail.gmail.com>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
 <f6e861bd1e734077992dc840ae5024a4@anx-i-dag01.anx.local>
 <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>
 <CAN9qwJ_1VLsfaM1qOSqELN1Q0=3NgktQr8rip4pm+qzhJPWySQ@mail.gmail.com>
Message-ID: <20150811224926.GA4685@amused.net>

Josh,
Just an FYI,
I've successfully used these two EoIP implementations on Linux:

https://code.google.com/p/linux-eoip/
https://github.com/bbonev/eoip

So I wouldn't say EoIP is Mikrotik only -- these interop perfectly
with  Mikrotik.  I started using these due to stability problems 
we were having with CCRs.

Pat

Tue, Aug 11, 2015 at 06:32:55PM -0400, Josh Luthman wrote:


> Eoip is Mikrotik only
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> On Aug 11, 2015 6:28 PM, "Colton Conor" <colton.conor at gmail.com> wrote:
> 
> > EoIP seems to be what I am looking for, however this recent Mikrotik
> > session says:
> >
> > EoIP could be a solution for tunneling L2 over L3.
> > ? EoIP disadvantages: ? Fragmentation of L2 frames over multiple L3 packets
> > ? Performance issues ?
> > VPLS advantages: ? No fragmentation. ? 60% more performance then EoIP.
> >
> > So it sounds like VPLS might be better than EoIP? I can't find much about
> > EoIP online, so is this a Mikrotik only protocol?
> >
> > On Tue, Aug 11, 2015 at 1:46 PM, J?rgen Jaritsch <jj at anexia.at> wrote:
> >
> > > Hi,
> > >
> > > Mikrotik Routerboard + (encrypted) Ethernet over IP (EoIP). If required:
> > > MPLS+OSPF+BGP in the EoIP for additional features.
> > >
> > > Build the pseudo Layer2 with two dedicated boxes. In the HQ you can hand
> > > it over directly to the MX80 and at the new office you can work with
> > small
> > > boxes like Cisco 7301 (also available with redundant PS) or if you need
> > > more ports: 19xx ...
> > >
> > > #) cheap setup
> > > #) can easily transport a few hundred Meg
> > > #) you can use refurb parts if required
> > > #) big community support for Mikrotik Routerboards
> > > #) encrypted transport possible
> > > #) works with dynamic IPs
> > > #) MPLS in the EoIP allows you to transport VRFs with BGP signaling
> > >
> > > Etc etc
> > >
> > > Best regards
> > >
> > >
> > > J?rgen Jaritsch
> > > Head of Network & Infrastructure
> > >
> > > ANEXIA Internetdienstleistungs GmbH
> > >
> > > Telefon: +43-5-0556-300
> > > Telefax: +43-5-0556-500
> > >
> > > E-Mail: jj at anexia.at
> > > Web: http://www.anexia.at
> > >
> > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
> > > Gesch?ftsf?hrer: Alexander Windbichler
> > > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT
> > > U63216601
> > >
> > >
> > >
> > > -----Original Message-----
> > > *From:* Colton Conor [colton.conor at gmail.com]
> > > *Received:* Dienstag, 11 Aug. 2015, 20:23
> > > *To:* NANOG [nanog at nanog.org]
> > > *Subject:* Branch Location Over The Internet
> > >
> > > We have an enterprise that has a headquarter office with redundant fiber
> > > connections, its own ASN, its own /22 IP block from ARIN, and a couple of
> > > gigabit internet connections from multiple providers. The office is
> > taking
> > > full BGP routes from tier 1 providers using a Juniper MX80.
> > >
> > > They are establishing their first branch location, and need the branch
> > > location to be able to securely communicate back to headquarters, AND be
> > > able to use a /24 of  headquarters public IP addresses. Ideally the
> > device
> > > at the HQ location would hand out public IP address using DHCP to the
> > other
> > > side of the tunnel at the branch location.
> > >
> > > We know that in an ideal world it would be wise to get layer 2 transport
> > > connections from HQ to the branch location, but lets assume that is not
> > an
> > > option. Please don't flood this thread about how it could be an option
> > > because it's not at this time. This setup will be temporary and in
> > service
> > > for the next year until we get fiber to the branch site.
> > >
> > > Let's assume at the branch location we can get a DOCSIS cable internet
> > > connection from a incumbent cable provider such as Comcast, and that
> > > provider will give us a couple static IP address. Assume as a backup, we
> > > have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
> > > dynamic IP address.
> > >
> > > What solution could we put at the HQ site and the branch site to achieve
> > > this? Ideally we would want the solution to load balance between the
> > > connections based on the connections speeds, and failover if one is down.
> > > The cable connection will be much faster speed (probably 150Mbps down and
> > > 10 Upload) compared to the DSL connection (10 download and 1 upload). If
> > we
> > > need more speed we can upgrade the cable modem to a higher package, but
> > for
> > > DSL that is the max speed so we might have to get multiple DSL lines. The
> > > cable solution could always be used as the primary, and the DSL
> > connection
> > > could only be used as backup if that makes things easier.
> > >
> > > If you were to do this with Juniper or Cisco gear what would you have at
> > > each location? What technology would you use?
> > >
> > > I know there is Pepewave and a couple of other software solutions that
> > seem
> > > to have a proprietary load balancing solutions developed, but I would
> > > prefer to use a common Cisco or Juniper solution if one exists.
> > >
> > > There will be 50 users at the branch office. There is only one branch
> > > location at this time, but they might expand to a couple more but under
> > 10.
> > >
> >
> 

-- 
Patrick Cole <z at wwwires.com>
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630

From edward.lewis at icann.org  Wed Aug 12 01:13:24 2015
From: edward.lewis at icann.org (Edward Lewis)
Date: Wed, 12 Aug 2015 01:13:24 +0000
Subject: Live-streaming the Root Zone Key-Signing Key Ceremony 22
Message-ID: <D1EFA6C1.E166%edward.lewis@icann.org>

FYI,

(Apologies if you see duplicates of this message.)

ICANN, as the IANA Functions Operator, will be live-streaming the Root Zone
Key-Signing Key Ceremony (number 22) on Thursday, August 13.  The "main"
ceremony that day is scheduled to begin at 2000UTC.

(This is an activity related to DNSSEC.)

For more information about the event see:

     https://www.iana.org/dnssec/ceremonies/22

On Thursday there will be two cermonies as listed on that web page.

The first ceremnoy will rotate cryptographic officer duties, basically, a
change in some of the trusted community representatives participating in
the key ceremonies.

The second ceremony (the "main") will feature the introduction of two new
Hardware Security Modules.  This is the ceremony that will start at 2000
UTC.

Please see the above link for more information.  The live-streaming link
is at the bottom of the page.  (https://icann.adobeconnect.com/kskceremony)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150812/33694531/attachment.bin>

From jj at anexia.at  Wed Aug 12 16:49:30 2015
From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=)
Date: Wed, 12 Aug 2015 16:49:30 +0000
Subject: AW: Branch Location Over The Internet
In-Reply-To: <20150811224926.GA4685@amused.net>
References: <CAMDdSzN2HORMjUJbxGXZ1pp2JWb+uj_QrCVwyrf8vRhnj+Kj9Q@mail.gmail.com>
 <f6e861bd1e734077992dc840ae5024a4@anx-i-dag01.anx.local>
 <CAMDdSzNN0HXPRtnDDUZKa0UGf-jdqAVq3Jyg1T7CzfdFgtkjVg@mail.gmail.com>
 <CAN9qwJ_1VLsfaM1qOSqELN1Q0=3NgktQr8rip4pm+qzhJPWySQ@mail.gmail.com>
 <20150811224926.GA4685@amused.net>
Message-ID: <812474820fa942c1a5277db41f31aef0@anx-i-dag02.anx.local>

Patrick,

which CCR did you test?

Best regards




-----Urspr?ngliche Nachricht-----
Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Patrick Cole
Gesendet: Mittwoch, 12. August 2015 00:49
An: Josh Luthman <josh at imaginenetworksllc.com>
Cc: NANOG list <nanog at nanog.org>
Betreff: Re: Branch Location Over The Internet

Josh,
Just an FYI,
I've successfully used these two EoIP implementations on Linux:

https://code.google.com/p/linux-eoip/
https://github.com/bbonev/eoip

So I wouldn't say EoIP is Mikrotik only -- these interop perfectly
with  Mikrotik.  I started using these due to stability problems 
we were having with CCRs.

Pat

Tue, Aug 11, 2015 at 06:32:55PM -0400, Josh Luthman wrote:


> Eoip is Mikrotik only
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> On Aug 11, 2015 6:28 PM, "Colton Conor" <colton.conor at gmail.com> wrote:
> 
> > EoIP seems to be what I am looking for, however this recent Mikrotik
> > session says:
> >
> > EoIP could be a solution for tunneling L2 over L3.
> > ? EoIP disadvantages: ? Fragmentation of L2 frames over multiple L3 packets
> > ? Performance issues ?
> > VPLS advantages: ? No fragmentation. ? 60% more performance then EoIP.
> >
> > So it sounds like VPLS might be better than EoIP? I can't find much about
> > EoIP online, so is this a Mikrotik only protocol?
> >
> > On Tue, Aug 11, 2015 at 1:46 PM, J?rgen Jaritsch <jj at anexia.at> wrote:
> >
> > > Hi,
> > >
> > > Mikrotik Routerboard + (encrypted) Ethernet over IP (EoIP). If required:
> > > MPLS+OSPF+BGP in the EoIP for additional features.
> > >
> > > Build the pseudo Layer2 with two dedicated boxes. In the HQ you can hand
> > > it over directly to the MX80 and at the new office you can work with
> > small
> > > boxes like Cisco 7301 (also available with redundant PS) or if you need
> > > more ports: 19xx ...
> > >
> > > #) cheap setup
> > > #) can easily transport a few hundred Meg
> > > #) you can use refurb parts if required
> > > #) big community support for Mikrotik Routerboards
> > > #) encrypted transport possible
> > > #) works with dynamic IPs
> > > #) MPLS in the EoIP allows you to transport VRFs with BGP signaling
> > >
> > > Etc etc
> > >
> > > Best regards
> > >
> > >
> > > J?rgen Jaritsch
> > > Head of Network & Infrastructure
> > >
> > > ANEXIA Internetdienstleistungs GmbH
> > >
> > > Telefon: +43-5-0556-300
> > > Telefax: +43-5-0556-500
> > >
> > > E-Mail: jj at anexia.at
> > > Web: http://www.anexia.at
> > >
> > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt
> > > Gesch?ftsf?hrer: Alexander Windbichler
> > > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT
> > > U63216601
> > >
> > >
> > >
> > > -----Original Message-----
> > > *From:* Colton Conor [colton.conor at gmail.com]
> > > *Received:* Dienstag, 11 Aug. 2015, 20:23
> > > *To:* NANOG [nanog at nanog.org]
> > > *Subject:* Branch Location Over The Internet
> > >
> > > We have an enterprise that has a headquarter office with redundant fiber
> > > connections, its own ASN, its own /22 IP block from ARIN, and a couple of
> > > gigabit internet connections from multiple providers. The office is
> > taking
> > > full BGP routes from tier 1 providers using a Juniper MX80.
> > >
> > > They are establishing their first branch location, and need the branch
> > > location to be able to securely communicate back to headquarters, AND be
> > > able to use a /24 of  headquarters public IP addresses. Ideally the
> > device
> > > at the HQ location would hand out public IP address using DHCP to the
> > other
> > > side of the tunnel at the branch location.
> > >
> > > We know that in an ideal world it would be wise to get layer 2 transport
> > > connections from HQ to the branch location, but lets assume that is not
> > an
> > > option. Please don't flood this thread about how it could be an option
> > > because it's not at this time. This setup will be temporary and in
> > service
> > > for the next year until we get fiber to the branch site.
> > >
> > > Let's assume at the branch location we can get a DOCSIS cable internet
> > > connection from a incumbent cable provider such as Comcast, and that
> > > provider will give us a couple static IP address. Assume as a backup, we
> > > have a PPPoE DSL connection from the ILEC such as Verizon who gives us a
> > > dynamic IP address.
> > >
> > > What solution could we put at the HQ site and the branch site to achieve
> > > this? Ideally we would want the solution to load balance between the
> > > connections based on the connections speeds, and failover if one is down.
> > > The cable connection will be much faster speed (probably 150Mbps down and
> > > 10 Upload) compared to the DSL connection (10 download and 1 upload). If
> > we
> > > need more speed we can upgrade the cable modem to a higher package, but
> > for
> > > DSL that is the max speed so we might have to get multiple DSL lines. The
> > > cable solution could always be used as the primary, and the DSL
> > connection
> > > could only be used as backup if that makes things easier.
> > >
> > > If you were to do this with Juniper or Cisco gear what would you have at
> > > each location? What technology would you use?
> > >
> > > I know there is Pepewave and a couple of other software solutions that
> > seem
> > > to have a proprietary load balancing solutions developed, but I would
> > > prefer to use a common Cisco or Juniper solution if one exists.
> > >
> > > There will be 50 users at the branch office. There is only one branch
> > > location at this time, but they might expand to a couple more but under
> > 10.
> > >
> >
> 

-- 
Patrick Cole <z at wwwires.com>
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630

From rafael at gav.ufsc.br  Wed Aug 12 20:19:29 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Wed, 12 Aug 2015 15:19:29 -0500
Subject: Data Center operations mail list?
In-Reply-To: <ximss-516184@mail.ropeguru.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <ximss-516184@mail.ropeguru.com>
Message-ID: <CAJB2g-GiaBNFS6gqKRppZ8hBzL5NvtTAD60Sz7bsk-3WR3krUg@mail.gmail.com>

Robert, the first few people who expressed interested were subscribed
manually. Everyone else has been using the list website to subscribe! There
should have been a message sent out with the subscription email explaining
it :)



On Wed, Aug 12, 2015 at 10:28 AM, Robert Webb <rwebb at ropeguru.com> wrote:

> Interesting... I just went to the web site to subscribe and I received an
> email that I was already subscribed.
>
> I don't remember doing that... So how did this happen??
>
> Robert
>
>
> On Wed, 12 Aug 2015 07:33:05 -0500
>  Rafael Possamai <rafael at gav.ufsc.br> wrote:
>
>> I was actually surprised with how many people subscribed already. I think
>> we are close to 100 already in less than 24 hours.
>>
>> I could use some help drafting some basic mailing list rules (no spam, no
>> soliciting, etc) and if anyone has any suggestions, please let me know.
>>
>>
>> On Wed, Aug 12, 2015 at 1:34 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>>
>>
>>> On 11/Aug/15 17:46, Alex Brooks wrote:
>>> > With the lack of interest compared to NANOG (especially seeing how the
>>> > old list simply dried up) it might be best making the list global
>>> > rather than North America only to get the traffic levels up a bit.
>>>
>>> Tend to agree that a list with global scope might be more useful.
>>>
>>> Mark.
>>>
>>>
>
>

From nanogml at Mail.DDoS-Mitigator.net  Thu Aug 13 01:20:26 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Wed, 12 Aug 2015 18:20:26 -0700
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
References: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
Message-ID: <20150813012026.GA16939@Mail.DDoS-Mitigator.net>


hi ramy

On 08/12/15 at 05:28pm, Ramy Hashish wrote:
>
> Anybody here compared Wanguard's performance with the DDoS vendors in the
> market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?
 
wouldn't the above "comparison" be kinda funky comparing software solutions
with hardware appliances and/or cloud scubbers ??

comparisons between vendors should be between sw solutions,
or hw appliances vs other hw, or cloud vs other clouds

wanguard should be compared with other sw options or vendors using
sflow, netflow, jflow, etc etc
	http://www.andrisoft.com/software/wanguard
	http://bitbucket.org/tortoiselabs/ddosmon
	http://www.github.com/FastVPSEestiOu/fastnetmon
	http://nfdump.sourceforge.net
	http://nfsen.sourceforge.net

wanguard - software solution using sflow
	http://www.andrisoft.com/software/wanguard

arbor ---- hardware/software solutions -- "peakflow" 
	http://www.arbornetworks.com/products/peakflow

radware -- hardware/software/cloud solutions -- "defenseflow"
	http://www.radware.com/products/attack-mitigation-service/
	http://www.radware.com/Products/DefenseFlow/

nsfocus -- hardware/cloud solutions
	http://www.nsfocus.com/products/

A10 ------ hardware solution
	http://www.a10network.com/products

riorey --- hardware solution
	http://www.riorey.com/riorey-ddos-products

staminus - hardware/cloud solutions
	http://www.staminus.net/shield

# and to add to the ddos confusion ..

akamai/prolexic --- hardware/cloud solution

f5 ---------------- hardware/cloud solutions
	http://www.f5.com/resources/white-papers/mitigating-ddos-attacks-with-f5-technology

fortinet ---------- custom ASIC hardware and cloud solution
	http://www.fortinet.com/products/fortiddos/ddos-mitigation-appliances.html

- simulated ddos attacks should include:
  ==
  == you are already getting hourly low level DDoS attacks from your script kiddies
  ==	try to defend against those mostly harmless attacks first
  ==
    #
    # some trivial benchmark DDoS attacks to generate -- internally only
    #	- never send DDoS packets outside of your bldg/gateway
    #
    # DDoS-Simulator.net == generate any DDoS packets per your desires
    #	- use nc, socat, *perf, nping or hping to generate most of these DDoS attacks 
    #	- use dsniff/arpspoof to break everything
    #
    within your own network, send few packets per second attacks
    within your own network, send x,000 packets per second attacks
    within your own network, send xxx,000 packet per second attacks 
	sustained sporadically over hours/days

    - arp-based attacks
    - udp-based attacks
	nping -v -d1 -c 10000 --data-length 1511 --rate 12345 --udp 127.0.0.1 
	hping -c 10000 -d 1511 -i u 81 --rand-source -p 123 -S --udp -p 123 127.0.0.1 

    - icmp-based attacks
	ping -c 10000 -s 1511 -i 0.00008  127.0.0.1 
	nping -v -d1 -c 10000 --data-length 1511 --rate 12345 --icmp 127.0.0.1 
	hping -c 1 -d 1501 --rand-source --file TeraByteFile.bin --icmp 127.0.0.1 
	gazillionPingApps

    - tcp-based attacks --- ez to send malicious packets and to defend against
	# 10,000 random src add
	hping -c 10000 -d 1511 -i u 81 --rand-source -xxTCPflags 127.0.0.1 
		# -S = set SYN flag
		# -F = set FIN flag
		# -A = set ACK flag

    - application layer tests --- http, ssh, mail and 65,532 other ports
	 hping -c 10000 -d 1511 -i u 81 --rand-source -p 22 -S 127.0.0.1 
	 hping -c 10000 -d 1511 -i u 81 --rand-source -p 25 -S 127.0.0.1 
	 hping -c 10000 -d 1511 -i u 81 --rand-source -p 80 -S 127.0.0.1 
	 hping -c 10000 -d 1511 -i u 81 --rand-source -p 53 -S --udp 127.0.0.1 

		- these attack the servers or client desktop/laptops

    - volumetric attacks -- almost everybody will fail this test
    - volumetric attacks are pointless, you'll always fail at some point
	ping -f
	iperf
	socat

    - send spam  .......................... mitigated separately ...
    - send virus and worms to the list  ... mitigated separately ...

- cloud solutions
    - if you have regulatory compliance requirements, your options
      are extemely limited to a few certified amd expensive clouds

    - what triggers the packets to go to the cloud for scrubbing

    - you do NOT want somebody "looking" at millions of packets to
      decide to send it off the cloud for scrubbing or not

    - you might NOT want to send everything to the cloud and
      incurr un-necessary expenses if you're NOT under xxxGbit/sec 
      DDoS attacks

- ddos mitigation should be able to distinguish legit traffic 
  from real ddos traffic
	- eg folks downloading or sending 4GB dvd or larger files
	- eg silly folks sending 4GB dvd via emails

  # simplified way to distinguish legit users from ddos attackers

	if web servers are running only "apache",
	all other packets to other ports are DDoS attacks

	if mail servers are running only "sendmail",
	all other packets to other ports are DDoS attacks

	if ldap servers are running only "ldap",
	all other packets to other ports are DDoS attacks

	one way to determine legit web users from web ddos attacks
	is to look into apache's error logs for bad URLs

	one way to determine legit mail users from mail ddos attacks
	is to look into sendmail's error logs for bad things

	all servers require ssh, ntp/udp, dns/udp and should
	be locked to particular IP# only ... all other
	connection attempts are ddos attacks
#
# after you are done comparing all the various DDoS mitigation 
# products and solutions, your conclusion might look like:
#

  a) what's my ddos mitigation budget for the level of ddos attacks
     i'm already getting 

  b) icmp and udp attacks can only be mitigated at the ISP 
	- you'd need to find a pro-active ddos mitigating ISP

  c) arp attacks can usually be mitigated by properly configured
     servers and network infrastructure

  d) tcp-based attacks are trivial to mitigate
	- i prefer to mitigate with tarpits to counter the 
	zombie's attacks, requiring their zombie servers to have 
	huge amts of kernel memory to sustain any tcp-based attacks

  e) volumetric attacks are a nuisance and expensive to resolve and
     everybody fails volumetric attacks after x,xxxGbit/sec attacks

  f) if you have governmental regulatory compliance issues,
     you're options are limited to using inhouse distributed colo 
     or finding certified ddos scrubbers with proper certifications

> Another question, have anybody from the reviewers tested the false
> positives of the box, or experienced any false positive incidents?

any "false positives" for ddos attacks are a bad thing ... especially
if you're not gonna deliver it to the end user b/c the ddos box says 
"these are bad packets"

pixie dust
alvin
# DDoS-Mitigator.net/Competitors
# DDoS-Mitigator.net/Mitigation
# DDoS-Simulator.net/Malicious-DDoS
# DDoS-Simulator.net/DDoS-Simulation-Plan
#

From ramy.ihashish at gmail.com  Thu Aug 13 04:42:26 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Thu, 13 Aug 2015 07:42:26 +0300
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <AEAE5C0D-FE2F-4542-B237-159BF09671A9@mac.com>
References: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
 <AEAE5C0D-FE2F-4542-B237-159BF09671A9@mac.com>
Message-ID: <CAOLsBOv4quzg9a4Y5to7qVyy2=_U-uysKzO2hDwYuMDWSqffxQ@mail.gmail.com>

Hello Fabien,

And why don't you use A10 for both detection and mitigation?

Thanks,

Ramy

On Wed, Aug 12, 2015 at 6:42 PM, Fabien Delmotte <fdelmotte1 at mac.com> wrote:

> Hello
>
> My 2 cents
> You can use Wanguard for the detection and A10 for the mitigation, you
> have just to play with the API.
>
> Regards
>
> Fabien
>
> > Le 12 ao?t 2015 ? 16:28, Ramy Hashish <ramy.ihashish at gmail.com> a ?crit
> :
> >
> >>
> >>
> >> Date: Tue, 11 Aug 2015 08:14:54 +0200
> >> From: "marcel.duregards at yahoo.fr" <marcel.duregards at yahoo.fr>
> >> To: nanog at nanog.org
> >> Subject: Re: Experience on Wanguard for 'anti' DDOS solutions
> >> Message-ID: <55C992DE.3020906 at yahoo.fr>
> >> Content-Type: text/plain; charset=windows-1252; format=flowed
> >>
> >> anybody from this impressive list ?:
> >>
> >> https://www.andrisoft.com/company/customers
> >>
> >> -- Marcel
> >>
> >>
> >>
> > Anybody here compared Wanguard's performance with the DDoS vendors in the
> > market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?
> >
> > Another question, have anybody from the reviewers tested the false
> > positives of the box, or experienced any false positive incidents?
> >
> > Thanks,
> >
> > Ramy
>
>

From lou at metron.com  Thu Aug 13 05:10:12 2015
From: lou at metron.com (Lou Katz)
Date: Wed, 12 Aug 2015 22:10:12 -0700
Subject: Can someone from Cogentco.com contact me offlist?
Message-ID: <20150813051012.GA80780@metron.com>

A routing/filtering problem probably between be2185.ccr22.cle04.atlas.cogentco.com
and be2009.ccr21.alb02.atlas.cogentco.com.
-- 

-=[Lou Katz]=-
Composed on an ASR33


From marcel.duregards at yahoo.fr  Thu Aug 13 05:14:37 2015
From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr)
Date: Thu, 13 Aug 2015 07:14:37 +0200
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
References: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
Message-ID: <55CC27BD.5080609@yahoo.fr>

you can try to get some financials (probably poor technical) view on DDOS :
http://www.infonetics.com/pr/2014/1H14-DDoS-Prevention-Appliances-Market-Highlights.asp


The DDOS prevention Appliances report is not free, and I doubt it's 
really technical :-)
But at least you could know what your financial guys might think. Could 
help you if you want to convince them to buy Arbor :-).

- Marcel


On 12.08.2015 16:28, Ramy Hashish wrote:
>>
>>
>> Date: Tue, 11 Aug 2015 08:14:54 +0200
>> From: "marcel.duregards at yahoo.fr" <marcel.duregards at yahoo.fr>
>> To: nanog at nanog.org
>> Subject: Re: Experience on Wanguard for 'anti' DDOS solutions
>> Message-ID: <55C992DE.3020906 at yahoo.fr>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> anybody from this impressive list ?:
>>
>> https://www.andrisoft.com/company/customers
>>
>> -- Marcel
>>
>>
>>
> Anybody here compared Wanguard's performance with the DDoS vendors in the
> market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?
>
> Another question, have anybody from the reviewers tested the false
> positives of the box, or experienced any false positive incidents?
>
> Thanks,
>
> Ramy
>

From nanog at ics-il.net  Thu Aug 13 12:04:29 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Thu, 13 Aug 2015 07:04:29 -0500 (CDT)
Subject: Can someone from Cogentco.com contact me offlist?
In-Reply-To: <20150813051012.GA80780@metron.com>
Message-ID: <1548364703.2809.1439467471001.JavaMail.mhammett@ThunderFuck>

OP gets 543 sales calls.... 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Lou Katz" <lou at metron.com> 
To: nanog at nanog.org 
Sent: Thursday, August 13, 2015 12:10:12 AM 
Subject: Can someone from Cogentco.com contact me offlist? 

A routing/filtering problem probably between be2185.ccr22.cle04.atlas.cogentco.com 
and be2009.ccr21.alb02.atlas.cogentco.com. 
-- 

-=[Lou Katz]=- 
Composed on an ASR33 



From jared at puck.Nether.net  Thu Aug 13 14:00:33 2015
From: jared at puck.Nether.net (Jared Mauch)
Date: Thu, 13 Aug 2015 10:00:33 -0400
Subject: ATT wireless IPv6
In-Reply-To: <CAJ0+aXZqZtULfNxJsda2G794TVUP1jGZ9Kj6CjOwxwYHSHmFBg@mail.gmail.com>
References: <D5F9AE2F-D87D-47A1-928E-9FD528BD5E5D@puck.nether.net>
 <55A6DEDE.2090701@NEEBU.Net>
 <3627BB47-6B49-4F42-9165-45FA19D7EFD3@puck.nether.net>
 <CAJ0+aXZqZtULfNxJsda2G794TVUP1jGZ9Kj6CjOwxwYHSHmFBg@mail.gmail.com>
Message-ID: <20150813140033.GC31601@puck.nether.net>

	I don't have an android device, perhaps someone with one
can comment?

	- Jared

On Tue, Jul 28, 2015 at 03:36:38AM +0530, Anurag Bhatia wrote:
> Hi Jared
> 
> 
> I am curious on prefix size of routed block. Is that a /64 routed prefix?
> 
> How well it works with Android tethering?
> 
> 
> 
> 
> 
> On Thu, Jul 16, 2015 at 4:03 AM, Jared Mauch <jared at puck.nether.net> wrote:
> 
> >
> > > On Jul 15, 2015, at 6:29 PM, Jake Khuon <khuon at NEEBU.Net> wrote:
> > >
> > > On 15/07/15 04:54, Jared Mauch wrote:
> > >> Does anyone know what the story is here? They have some transparent
> > proxies for IPv4 traffic and I was wondering if they were to be IPv6
> > enabled soon or if IPv6 will reach the handset.
> > >
> > > Hmmm...  I'm seeing my rmnet1 interface on my Galaxy S5 as having an
> > > address out of the 2600:380:46ae::/38 space which is allocated to AT&T
> > > Mobility.
> >
> > I exchanged a few emails earlier today with someone and it seems to depend
> > on your APN.  If you have the VoLTE APN on your device you can get IPv6,
> > including when tethering. The APN you want is nxtgenphone.
> >
> > If you have a device where you can not edit the APN settings (iPhone) you
> > can not use the IPv6 enabled VoLTE APN.
> >
> > I suspect this will be enabled if they launch VoLTE on the iPhone.
> >
> > - Jared
> 
> 
> 
> 
> -- 
> 
> 
> Anurag Bhatia
> anuragbhatia.com
> 
> 
> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2

-- 
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 m4rtntns at gmail.com  Thu Aug 13 22:56:00 2015
From: m4rtntns at gmail.com (Martin T)
Date: Fri, 14 Aug 2015 01:56:00 +0300
Subject: Is it possible to roughly estimate network traffic distribution for
 given ASN?
Message-ID: <CAJx5YvGyGkU-LdbhMjLGr4GVsU_2oXhUJ3_iBX3rD3_H2DUG+A@mail.gmail.com>

Hi,

there are various tools out there which show the prefix distribution
among the peers/uplinks for given ASN. For example
https://radar.qrator.net/as3333/graph#96311 or
http://bgp.he.net/AS3333#_asinfo. As far as I know, those tools build
the graphs mainly based on data from route servers. Am I correct that
at best this data could give very rough estimation on ingress traffic
for ASN as those graphs indicate announced prefixes? I mean for
example if ASN 1 announces 1.1.0.0/16, 2.2.0.0/16 and 3.3.0.0/16 to
ASN 2, but only 1.1.0.0/16 to ASN 3, then one could assume that more
ingress data to ASN 1 goes over ASN 2. What about egress traffic? In
general, are there ways to roughly estimate network traffic
distribution for given ASN among its peers/uplinks? I would say it is
not possible.


thanks,
Martin

From streiner at cluebyfour.org  Fri Aug 14 00:39:09 2015
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 13 Aug 2015 20:39:09 -0400 (EDT)
Subject: Is it possible to roughly estimate network traffic distribution
 for given ASN?
In-Reply-To: <CAJx5YvGyGkU-LdbhMjLGr4GVsU_2oXhUJ3_iBX3rD3_H2DUG+A@mail.gmail.com>
References: <CAJx5YvGyGkU-LdbhMjLGr4GVsU_2oXhUJ3_iBX3rD3_H2DUG+A@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1508132029230.2137@whammy.cluebyfour.org>

On Fri, 14 Aug 2015, Martin T wrote:

> there are various tools out there which show the prefix distribution
> among the peers/uplinks for given ASN. For example
> https://radar.qrator.net/as3333/graph#96311 or
> http://bgp.he.net/AS3333#_asinfo. As far as I know, those tools build
> the graphs mainly based on data from route servers. Am I correct that
> at best this data could give very rough estimation on ingress traffic
> for ASN as those graphs indicate announced prefixes? I mean for
> example if ASN 1 announces 1.1.0.0/16, 2.2.0.0/16 and 3.3.0.0/16 to
> ASN 2, but only 1.1.0.0/16 to ASN 3, then one could assume that more
> ingress data to ASN 1 goes over ASN 2. What about egress traffic? In
> general, are there ways to roughly estimate network traffic
> distribution for given ASN among its peers/uplinks? I would say it is
> not possible.

You can certainly make inferences about the traffic between ASN 1 and ASN 
2, 3, etc... however without being the operator of one of those ASNs, 
those inferences are just that - inferences.  Even if you operate a 
network that peers with both ASN 1 and ASN 3, the traffic you see 
transiting your network to get to/from them might only be a fraction of 
the total traffic between those ASNs, given the possibility of there being 
other paths between then that don't cross your network.

What are you trying to figure out?  If you want to see how much traffic 
you move between your AS and another AS, Netflow, IPFIX, and other tools 
can help you figure that out.  If you're looking for the same kind of 
data for a source, destination (or both) that you don't control, all you 
can realistically do is guess.

jms

From baldur.norddahl at gmail.com  Fri Aug 14 02:09:59 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 14 Aug 2015 04:09:59 +0200
Subject: Is it possible to roughly estimate network traffic distribution
 for given ASN?
In-Reply-To: <CAJx5YvGyGkU-LdbhMjLGr4GVsU_2oXhUJ3_iBX3rD3_H2DUG+A@mail.gmail.com>
References: <CAJx5YvGyGkU-LdbhMjLGr4GVsU_2oXhUJ3_iBX3rD3_H2DUG+A@mail.gmail.com>
Message-ID: <CAPkb-7BrhfiPrO3AE4-dCmhsp1fgF3rZ9x0yxEid02J28XS-nw@mail.gmail.com>

You may be able to view what routes I announce but you still have no idea
what my route policy is like. I might prefer one upstream over another due
to pricing, latency, capacity or any other unknown reason. And that is
never published.

If you can not know my egress, you will not know my ingress either as that
would be someone else egress and you can not know their egress....

You could use RIPE Atlas or the NLNOG RING to do traceroutes. That would
give you an idea of how traffic actually flows.

Knowing the routes tells you nothing about how much traffic will be
exchanged. How do you know which ASN has a deal with a big CDN or which
ASNs are content heavy vs eyeball heavy? Only the source or destination ASN
can know for sure how much traffic is exchanged.

Regards,

Baldur

From Matthew.Black at csulb.edu  Fri Aug 14 04:12:57 2015
From: Matthew.Black at csulb.edu (Matthew Black)
Date: Fri, 14 Aug 2015 04:12:57 +0000
Subject: Verizon FIOS routing trouble to Facebook
Message-ID: <ED78B1C68B84A14FA706D13A230D7B437822BB05@ITS-MAIL02.campus.ad.csulb.edu>

Anyone around from Verizon? Cannot reach Facebook through Verizon FIOS in Long Beach, CA. No trouble on the AT&T 4G LTE network.

Thursday, August 14, 2015 @ 0410 UTC

matthew black
california state university, long beach



From morrowc.lists at gmail.com  Fri Aug 14 04:18:11 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 14 Aug 2015 00:18:11 -0400
Subject: Verizon FIOS routing trouble to Facebook
In-Reply-To: <ED78B1C68B84A14FA706D13A230D7B437822BB05@ITS-MAIL02.campus.ad.csulb.edu>
References: <ED78B1C68B84A14FA706D13A230D7B437822BB05@ITS-MAIL02.campus.ad.csulb.edu>
Message-ID: <CAL9jLaZRGCAsB2aWsPLRz2HX3=ZOGuhRFVgJMjrD89-n+tJzjw@mail.gmail.com>

On Fri, Aug 14, 2015 at 12:12 AM, Matthew Black <Matthew.Black at csulb.edu> wrote:
> Anyone around from Verizon? Cannot reach Facebook through Verizon FIOS in Long Beach, CA. No trouble on the AT&T 4G LTE network.
>

$ p www.facebook.com
PING star.c10r.facebook.com (31.13.69.197) 56(84) bytes of data.
64 bytes from edge-star-shv-01-iad3.facebook.com (31.13.69.197):
icmp_seq=1 ttl=89 time=12.1 ms
64 bytes from edge-star-shv-01-iad3.facebook.com (31.13.69.197):
icmp_seq=2 ttl=89 time=5.64 ms

(looks like I'm talking to an east-coast fb instance)

...
 5  0.ae6.xl2.iad8.alter.net (140.222.228.57)  24.242 ms  24.707 ms *
 6  0.xe-11-0-1.gw9.iad8.alter.net (152.63.33.169)  22.515 ms
0.xe-11-1-0.gw9.iad8.alter.net (152.63.35.117)  15.337 ms
0.xe-10-3-0.gw9.iad8.alter.net (152.63.41.246)  10.154 ms
 7  fb-gw.customer.alter.net (204.148.11.102)  24.263 ms  11.457 ms  9.897 ms
 8  psw01a.iad3.tfbnw.net (204.15.23.162)  10.428 ms
psw01b.iad3.tfbnw.net (204.15.23.154)  7.720 ms psw01c.iad3.tfbnw.net
(204.15.23.144)  9.050 ms
...

From Matthew.Black at csulb.edu  Fri Aug 14 04:30:47 2015
From: Matthew.Black at csulb.edu (Matthew Black)
Date: Fri, 14 Aug 2015 04:30:47 +0000
Subject: Verizon FIOS routing trouble to Facebook
In-Reply-To: <CAL9jLaZRGCAsB2aWsPLRz2HX3=ZOGuhRFVgJMjrD89-n+tJzjw@mail.gmail.com>
References: <ED78B1C68B84A14FA706D13A230D7B437822BB05@ITS-MAIL02.campus.ad.csulb.edu>
 <CAL9jLaZRGCAsB2aWsPLRz2HX3=ZOGuhRFVgJMjrD89-n+tJzjw@mail.gmail.com>
Message-ID: <ED78B1C68B84A14FA706D13A230D7B437822BCB3@ITS-MAIL02.campus.ad.csulb.edu>

Pinging star.c10r.facebook.com [31.13.70.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

As I said, it fails from FIOS in Long Beach CA.

On the phone with FIOS support now. The tech wants me to reset my router to factory defaults even after explaining I can reach everything else. I suggested they had an upstream routing or peering problem.



-----Original Message-----
From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow
Sent: Thursday, August 13, 2015 9:18 PM
To: Matthew Black
Cc: nanog at nanog.org
Subject: Re: Verizon FIOS routing trouble to Facebook

On Fri, Aug 14, 2015 at 12:12 AM, Matthew Black <Matthew.Black at csulb.edu> wrote:
> Anyone around from Verizon? Cannot reach Facebook through Verizon FIOS in Long Beach, CA. No trouble on the AT&T 4G LTE network.
>

$ p www.facebook.com
PING star.c10r.facebook.com (31.13.69.197) 56(84) bytes of data.
64 bytes from edge-star-shv-01-iad3.facebook.com (31.13.69.197):
icmp_seq=1 ttl=89 time=12.1 ms
64 bytes from edge-star-shv-01-iad3.facebook.com (31.13.69.197):
icmp_seq=2 ttl=89 time=5.64 ms

(looks like I'm talking to an east-coast fb instance)

...
 5  0.ae6.xl2.iad8.alter.net (140.222.228.57)  24.242 ms  24.707 ms *
 6  0.xe-11-0-1.gw9.iad8.alter.net (152.63.33.169)  22.515 ms 0.xe-11-1-0.gw9.iad8.alter.net (152.63.35.117)  15.337 ms 0.xe-10-3-0.gw9.iad8.alter.net (152.63.41.246)  10.154 ms
 7  fb-gw.customer.alter.net (204.148.11.102)  24.263 ms  11.457 ms  9.897 ms
 8  psw01a.iad3.tfbnw.net (204.15.23.162)  10.428 ms psw01b.iad3.tfbnw.net (204.15.23.154)  7.720 ms psw01c.iad3.tfbnw.net
(204.15.23.144)  9.050 ms
...

From phill at daa.com.au  Thu Aug 13 00:36:24 2015
From: phill at daa.com.au (Phill Twiss)
Date: Thu, 13 Aug 2015 08:36:24 +0800
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-GiaBNFS6gqKRppZ8hBzL5NvtTAD60Sz7bsk-3WR3krUg@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <ximss-516184@mail.ropeguru.com>
 <CAJB2g-GiaBNFS6gqKRppZ8hBzL5NvtTAD60Sz7bsk-3WR3krUg@mail.gmail.com>
Message-ID: <55CBE688.20802@daa.com.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

De-lurking

Hi Rafael and everyone else :}( sorry the cross-post )

	You should really have captcha's configured for your mailman lists

	Some shady actors out there are using mailman lists to target certain
email addresses.  Its a pretty dumb attack, but its annoying :}

	The target will be hit by hundreds ( if not thousands ) of subscribe
confirmation requests.

	We changed to captcha's a month or more ago, we still get an average
of 300 od IP's trying to do this in period of a few hours.

	Keep an eye out in your logfiles for some of the strings below ( they
all seem to try to use the same password ), if you have any issues
with getting captcha's to work properly, drop me an email :}

	Below is an sanitised ( list name and target) entry from the Apache
logs ( the IP is real, screw em :} )

64.234.104.150 - - [13/Aug/2015:08:15:54 +0800] "GET
/mailman/subscribe/<<Sanitised list name >>?email=<< Sanitised_TARGET
>> @YAHOO.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&diges
t=0&email-button=Subscribe
HTTP/1.1"
>> 
301 801 "http://tools.vietche.biz/Boom/" "Mozilla/5.0
(Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0"

	
	Regards

	Phill Twiss


On 13/08/2015 4:19 AM, Rafael Possamai wrote:
> Robert, the first few people who expressed interested were
> subscribed manually. Everyone else has been using the list website
> to subscribe! There should have been a message sent out with the
> subscription email explaining it :)
> 
> 
> 
> On Wed, Aug 12, 2015 at 10:28 AM, Robert Webb <rwebb at ropeguru.com>
> wrote:
> 
>> Interesting... I just went to the web site to subscribe and I
>> received an email that I was already subscribed.
>> 
>> I don't remember doing that... So how did this happen??
>> 
>> Robert
>> 
>> 
>> On Wed, 12 Aug 2015 07:33:05 -0500 Rafael Possamai
>> <rafael at gav.ufsc.br> wrote:
>> 
>>> I was actually surprised with how many people subscribed
>>> already. I think we are close to 100 already in less than 24
>>> hours.
>>> 
>>> I could use some help drafting some basic mailing list rules
>>> (no spam, no soliciting, etc) and if anyone has any
>>> suggestions, please let me know.
>>> 
>>> 
>>> On Wed, Aug 12, 2015 at 1:34 AM, Mark Tinka
>>> <mark.tinka at seacom.mu> wrote:
>>> 
>>> 
>>>> On 11/Aug/15 17:46, Alex Brooks wrote:
>>>>> With the lack of interest compared to NANOG (especially
>>>>> seeing how the old list simply dried up) it might be best
>>>>> making the list global rather than North America only to
>>>>> get the traffic levels up a bit.
>>>> 
>>>> Tend to agree that a list with global scope might be more
>>>> useful.
>>>> 
>>>> Mark.
>>>> 
>>>> 
>> 
>> 
> 

- -- 
Phill Twiss | IT Manager | Consultant Software Engineer
Data Analysis Australia Pty Ltd | STRATEGIC INFORMATION CONSULTANTS
97 Broadway, Nedlands, Western Australia, 6009 | PO Box 3258, Broadway
Nedlands, WA, 6009
T: +61 8 9468 2523 (Direct) | +61 8 9468 2533 or +61 8 9386 3304
(Reception)
F: +61 8 9386 3202 | E: phill at daa.com.au <mailto:phill at daa.com.au> | I:
http://www.daa.com.au <http://www.daa.com.au/>
This e-mail message and its attachments are privileged and confidential.
If you are not the intended recipient, please delete the message and
notify the sender.
While every care is taken, it is recommended that you scan any
attachments for viruses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVy+aHAAoJEGwAYdQtPZ9OLAwP/0/9A1zyYpFNDzIr4uHbPfcW
C0qJK+65xuKdoQ6nGV0bm7g8Ve82+YQta90LNggm6ncl9hKH5G6fShF+e09h54FJ
o+iDBAgOyhk1HjsGw7/fVMpVm9CILgjSV1tgA/HM66YGIOglslv8B10UBT9CJELD
JZ0Bzo3OPkTOUA/+casK3ydUn1Dpuaol4/i5iR/G7Td+F0oY3qyiXDUXVjMaN4MX
XzTRi6Luf+tS/agwnPYpX96vZ17xRn5/OVHwUSjTsnPQTUTuyTKm+S9rvuUBIawQ
qAv9sdyAVEH6IbdpQfv7hzmlm8Qj29VlyfT9Em6WEpBcDCph5GcFewEXLu4gajUI
dlj1n20W7NDb/bPnFUkgH0Nx6ZYV6mn9HzE29L2vnQWYN/EMdc3q5s7P1JYOe0u2
7e9xB6W0ZINPEVh4XS6HYtolYdXxD2oGRKi1suAXwUtO8gtBxonvGE5T7KbtM2WG
XSzR61dMZdBcBXGMSQvdU3nPgddbiV39tSwq7XhnPbu+JH0HjVYXM+CsP9hvT2zl
dKKDa7CTmjHH6yr1jlMDUP92i9OOMXVSW4l8pVFBKBJRduqGZiSArSMYpY1ADjID
iIO7qw2bCdClNiWaQ1JrdaZnKZQZ8nk2G679GY7XNUm9dxz8WBvErmWMzWp/xxwQ
a/7piwQb0C5+7jblAB23
=anjV
-----END PGP SIGNATURE-----

From carlos at race.com  Fri Aug 14 07:25:38 2015
From: carlos at race.com (Carlos Alcantar)
Date: Fri, 14 Aug 2015 07:25:38 +0000
Subject: Verizon FIOS routing trouble to Facebook
In-Reply-To: <ED78B1C68B84A14FA706D13A230D7B437822BCB3@ITS-MAIL02.campus.ad.csulb.edu>
References: <ED78B1C68B84A14FA706D13A230D7B437822BB05@ITS-MAIL02.campus.ad.csulb.edu>
 <CAL9jLaZRGCAsB2aWsPLRz2HX3=ZOGuhRFVgJMjrD89-n+tJzjw@mail.gmail.com>,
 <ED78B1C68B84A14FA706D13A230D7B437822BCB3@ITS-MAIL02.campus.ad.csulb.edu>
Message-ID: <DM2PR12MB01128FDCB144A04674BE72D6A07C0@DM2PR12MB0112.namprd12.prod.outlook.com>

Don't know if this is related but we got this maintenance notice from facebook.  Router is within the same region.

----------------------?

Subject: Facebook Network Maintenance Notification AS32934
 

Hi Peers,
  
Facebook will be performing maintenance at Coresite LA1 One Wilshire in Los Angeles California. This will affect all peering sessions on our routers and you will see the peering go down intermittently. 
 
ASN: 32934
 
Start: August 13 2015,  10:00 AM  PST
End:  August  13 2015,   6:00  PM  PST
 
 
Peering details: as32934.peeringdb.com 
 
Robert Horrigan
Edge & Network Services Team

----------------------?

Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com


________________________________________
From: NANOG <nanog-bounces at nanog.org> on behalf of Matthew Black <Matthew.Black at csulb.edu>
Sent: Thursday, August 13, 2015 9:30 PM
To: Christopher Morrow
Cc: nanog at nanog.org
Subject: RE: Verizon FIOS routing trouble to Facebook

Pinging star.c10r.facebook.com [31.13.70.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

As I said, it fails from FIOS in Long Beach CA.

On the phone with FIOS support now. The tech wants me to reset my router to factory defaults even after explaining I can reach everything else. I suggested they had an upstream routing or peering problem.



-----Original Message-----
From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow
Sent: Thursday, August 13, 2015 9:18 PM
To: Matthew Black
Cc: nanog at nanog.org
Subject: Re: Verizon FIOS routing trouble to Facebook

On Fri, Aug 14, 2015 at 12:12 AM, Matthew Black <Matthew.Black at csulb.edu> wrote:
> Anyone around from Verizon? Cannot reach Facebook through Verizon FIOS in Long Beach, CA. No trouble on the AT&T 4G LTE network.
>

$ p www.facebook.com
PING star.c10r.facebook.com (31.13.69.197) 56(84) bytes of data.
64 bytes from edge-star-shv-01-iad3.facebook.com (31.13.69.197):
icmp_seq=1 ttl=89 time=12.1 ms
64 bytes from edge-star-shv-01-iad3.facebook.com (31.13.69.197):
icmp_seq=2 ttl=89 time=5.64 ms

(looks like I'm talking to an east-coast fb instance)

...
 5  0.ae6.xl2.iad8.alter.net (140.222.228.57)  24.242 ms  24.707 ms *
 6  0.xe-11-0-1.gw9.iad8.alter.net (152.63.33.169)  22.515 ms 0.xe-11-1-0.gw9.iad8.alter.net (152.63.35.117)  15.337 ms 0.xe-10-3-0.gw9.iad8.alter.net (152.63.41.246)  10.154 ms
 7  fb-gw.customer.alter.net (204.148.11.102)  24.263 ms  11.457 ms  9.897 ms
 8  psw01a.iad3.tfbnw.net (204.15.23.162)  10.428 ms psw01b.iad3.tfbnw.net (204.15.23.154)  7.720 ms psw01c.iad3.tfbnw.net
(204.15.23.144)  9.050 ms
...

From m4rtntns at gmail.com  Fri Aug 14 07:54:40 2015
From: m4rtntns at gmail.com (Martin T)
Date: Fri, 14 Aug 2015 10:54:40 +0300
Subject: Is it possible to roughly estimate network traffic distribution
 for given ASN?
In-Reply-To: <CAPkb-7BrhfiPrO3AE4-dCmhsp1fgF3rZ9x0yxEid02J28XS-nw@mail.gmail.com>
References: <CAJx5YvGyGkU-LdbhMjLGr4GVsU_2oXhUJ3_iBX3rD3_H2DUG+A@mail.gmail.com>
 <CAPkb-7BrhfiPrO3AE4-dCmhsp1fgF3rZ9x0yxEid02J28XS-nw@mail.gmail.com>
Message-ID: <CAJx5YvG_EUUfpUc9gDqavgEf-gupQ9r5QAua0VgQxZtcR5akRg@mail.gmail.com>

Thanks for confirming this! One last question- am I correct that those
graphs referred in my initial e-mail indicate announced prefixes? Only
way to have some insight about received prefixes for particular ASN is
to check the RIR database aut-num object and hope that this is
up-to-date and all the routing policies are describe there in detail?
Again, RIPE Atlas or the NLNOG RING or looking-glass could also help a
little.


thanks,
Martin

On 8/14/15, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> You may be able to view what routes I announce but you still have no idea
> what my route policy is like. I might prefer one upstream over another due
> to pricing, latency, capacity or any other unknown reason. And that is
> never published.
>
> If you can not know my egress, you will not know my ingress either as that
> would be someone else egress and you can not know their egress....
>
> You could use RIPE Atlas or the NLNOG RING to do traceroutes. That would
> give you an idea of how traffic actually flows.
>
> Knowing the routes tells you nothing about how much traffic will be
> exchanged. How do you know which ASN has a deal with a big CDN or which
> ASNs are content heavy vs eyeball heavy? Only the source or destination ASN
> can know for sure how much traffic is exchanged.
>
> Regards,
>
> Baldur
>

From morrowc.lists at gmail.com  Fri Aug 14 13:58:42 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 14 Aug 2015 09:58:42 -0400
Subject: Verizon FIOS routing trouble to Facebook
In-Reply-To: <ED78B1C68B84A14FA706D13A230D7B437822BCB3@ITS-MAIL02.campus.ad.csulb.edu>
References: <ED78B1C68B84A14FA706D13A230D7B437822BB05@ITS-MAIL02.campus.ad.csulb.edu>
 <CAL9jLaZRGCAsB2aWsPLRz2HX3=ZOGuhRFVgJMjrD89-n+tJzjw@mail.gmail.com>
 <ED78B1C68B84A14FA706D13A230D7B437822BCB3@ITS-MAIL02.campus.ad.csulb.edu>
Message-ID: <CAL9jLab_F2CgUXPLGgAbxxb=YP1taecVVWWS5vOA4UGJqnSnSQ@mail.gmail.com>

On Fri, Aug 14, 2015 at 12:30 AM, Matthew Black <Matthew.Black at csulb.edu> wrote:
> 31.13.70.1

presumably this is fixed now, as:
 3  t1-0-0-9.washdc-lcr-22.verizon-gni.net (130.81.32.238)  9.706 ms
10.155 ms t1-2-0-0.washdc-lcr-21.verizon-gni.net (100.41.220.10)
8.803 ms
 4  * * *
 5  0.ae2.xl3.lax1.alter.net (140.222.227.73)  64.368 ms  63.868 ms  64.362 ms
 6  0.ae5.gw7.lax1.alter.net (152.63.112.222)  63.019 ms
0.ae6.gw7.lax1.alter.net (152.63.112.226)  67.564 ms
0.ae5.gw7.lax1.alter.net (152.63.112.222)  67.939 ms
 7  facebook-gw.customer.alter.net (152.179.103.150)  68.375 ms
177.174 ms  63.066 ms
 8  po101.psw01b.lax3.tfbnw.net (31.13.29.103)  62.537 ms
po101.psw01d.lax3.tfbnw.net (31.13.29.107)  62.533 ms  62.531 ms
 9  msw1aa.01.lax3.tfbnw.net (173.252.64.50)  63.043 ms
msw1ab.01.lax3.tfbnw.net (204.15.22.123)  63.023 ms
msw1ah.01.lax3.tfbnw.net (204.15.22.114)  63.205 ms
10  edge-star-shv-01-lax1.facebook.com (31.13.70.1)  62.434 ms  61.857
ms  62.454 ms

and:
$ p 31.13.70.1
PING 31.13.70.1 (31.13.70.1) 56(84) bytes of data.
64 bytes from 31.13.70.1: icmp_seq=1 ttl=89 time=111 ms

-chris

From julianeble at yahoo.com.br  Fri Aug 14 15:06:20 2015
From: julianeble at yahoo.com.br (Julian Eble)
Date: Fri, 14 Aug 2015 15:06:20 +0000 (UTC)
Subject: BRAS sugestion
Message-ID: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>

Hello Nanog,
Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion?

Thank you!

From Valdis.Kletnieks at vt.edu  Fri Aug 14 15:19:54 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 14 Aug 2015 11:19:54 -0400
Subject: BRAS sugestion
In-Reply-To: Your message of "Fri, 14 Aug 2015 15:06:20 -0000."
 <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <3468.1439565594@turing-police.cc.vt.edu>

On Fri, 14 Aug 2015 15:06:20 -0000, Julian Eble said:
> Our company are constantly growing and we're looking for a 30k+ subscribers
> BRAS, does the community have a sugestion?

Is a monolithic 30k+ a requirement, or would 3-4 10K boxes(or other
similar combo) be usable?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150814/1d0ae5de/attachment.pgp>

From listas at esds.com.br  Fri Aug 14 15:51:27 2015
From: listas at esds.com.br (Eduardo Schoedler)
Date: Fri, 14 Aug 2015 12:51:27 -0300
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAHf3uWw2tT0PHma0RSPqnGWSQG63QXLcQrzGhNnXKKGbjEOAuA@mail.gmail.com>

Juniper MX

2015-08-14 12:06 GMT-03:00 Julian Eble <julianeble at yahoo.com.br>:
> Hello Nanog,
> Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion?
>
> Thank you!



-- 
Eduardo Schoedler

From aj at sneep.net  Fri Aug 14 15:53:21 2015
From: aj at sneep.net (Alastair Johnson)
Date: Fri, 14 Aug 2015 11:53:21 -0400
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <55CE0EF1.3050404@sneep.net>

On 8/14/15 11:06 AM, Julian Eble wrote:
> Hello Nanog,
> Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion?

Alcatel-Lucent 7750SR


AJ
<disclaimer: I work for Alcatel-Lucent>


From mike.lyon at gmail.com  Fri Aug 14 16:01:08 2015
From: mike.lyon at gmail.com (Mike Lyon)
Date: Fri, 14 Aug 2015 09:01:08 -0700
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAFFgAjApfSU_byQu7fpdN2BDSa-r-g72gvi-_+A3wVLd8gMAYw@mail.gmail.com>

Victoria's Secret
On Aug 14, 2015 8:08 AM, "Julian Eble" <julianeble at yahoo.com.br> wrote:

> Hello Nanog,
> Our company are constantly growing and we're looking for a 30k+
> subscribers BRAS, does the community have a sugestion?
>
> Thank you!
>

From magicsata at gmail.com  Fri Aug 14 16:04:54 2015
From: magicsata at gmail.com (Alistair Mackenzie)
Date: Fri, 14 Aug 2015 17:04:54 +0100
Subject: BRAS sugestion
In-Reply-To: <CAFFgAjApfSU_byQu7fpdN2BDSa-r-g72gvi-_+A3wVLd8gMAYw@mail.gmail.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
 <CAFFgAjApfSU_byQu7fpdN2BDSa-r-g72gvi-_+A3wVLd8gMAYw@mail.gmail.com>
Message-ID: <CA+bbMkvAcN3h8QaouWCHa4SmAw5HRz5VGXKoBFuaS7CAV_pFpQ@mail.gmail.com>

I'm pretty sure this would get expensive for 30k+.

Perhaps try Walmart?

On 14 August 2015 at 17:01, Mike Lyon <mike.lyon at gmail.com> wrote:

> Victoria's Secret
> On Aug 14, 2015 8:08 AM, "Julian Eble" <julianeble at yahoo.com.br> wrote:
>
> > Hello Nanog,
> > Our company are constantly growing and we're looking for a 30k+
> > subscribers BRAS, does the community have a sugestion?
> >
> > Thank you!
> >
>

From mark.tinka at seacom.mu  Fri Aug 14 16:06:16 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 14 Aug 2015 18:06:16 +0200
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <55CE11F8.6050500@seacom.mu>



On 14/Aug/15 17:06, Julian Eble wrote:

> Hello Nanog,
> Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion?

Cisco ASR1006 or ASR1013
Cisco ASR9006, ASR9010, ASR9904, ASR9912 or ASR9922
Juniper MX240, MX480, MX960, MX2010 or MX2020
Alcatel-Lucent 7750SR

Smaller models allow you to distribute workload into smaller chunks.
Bigger models do the opposite, but scale faster.

Mark.

From clayton at MNSi.Net  Fri Aug 14 16:07:52 2015
From: clayton at MNSi.Net (Clayton Zekelman)
Date: Fri, 14 Aug 2015 12:07:52 -0400
Subject: BRAS sugestion
In-Reply-To: <CAHf3uWw2tT0PHma0RSPqnGWSQG63QXLcQrzGhNnXKKGbjEOAuA@mail.g
 mail.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
 <CAHf3uWw2tT0PHma0RSPqnGWSQG63QXLcQrzGhNnXKKGbjEOAuA@mail.gmail.com>
Message-ID: <1439568478_5548@surgemail.mnsi.net>


We just bought a couple of MX480s for B-RAS to replace some aging 
Cisco 7206/VXRs. Not racked or powered yet (showed up yesterday), but 
hope to have one of them online for testing next week.

Our initial test with an eval MX-80 verified functionality.

At 11:51 AM 14/08/2015, Eduardo Schoedler wrote:
>Juniper MX
>
>2015-08-14 12:06 GMT-03:00 Julian Eble <julianeble at yahoo.com.br>:
> > Hello Nanog,
> > Our company are constantly growing and we're looking for a 30k+ 
> subscribers BRAS, does the community have a sugestion?
> >
> > Thank you!
>
>
>
>--
>Eduardo Schoedler

---

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

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


From dave.taht at gmail.com  Fri Aug 14 16:12:35 2015
From: dave.taht at gmail.com (Dave Taht)
Date: Fri, 14 Aug 2015 09:12:35 -0700
Subject: BRAS sugestion
In-Reply-To: <55CE11F8.6050500@seacom.mu>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
 <55CE11F8.6050500@seacom.mu>
Message-ID: <CAA93jw7Y2yQy0c1vwU_J=VfZxbiaL6JKax=NhiQE+fTLy-q4nA@mail.gmail.com>

Has anyone in the BRAS world paid attention to bufferbloat yet?

From mark.tinka at seacom.mu  Fri Aug 14 16:22:10 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 14 Aug 2015 18:22:10 +0200
Subject: BRAS sugestion
In-Reply-To: <1439568478_5548@surgemail.mnsi.net>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
 <CAHf3uWw2tT0PHma0RSPqnGWSQG63QXLcQrzGhNnXKKGbjEOAuA@mail.gmail.com>
 <1439568478_5548@surgemail.mnsi.net>
Message-ID: <55CE15B2.8020204@seacom.mu>



On 14/Aug/15 18:07, Clayton Zekelman wrote:

>
> We just bought a couple of MX480s for B-RAS to replace some aging
> Cisco 7206/VXRs. Not racked or powered yet (showed up yesterday), but
> hope to have one of them online for testing next week.
>
> Our initial test with an eval MX-80 verified functionality.

I like that Juniper finally dropped further development of the dedicate
BRAS code. It had become annoying.

Mark.


From alter3d at alter3d.ca  Fri Aug 14 16:52:35 2015
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Fri, 14 Aug 2015 12:52:35 -0400
Subject: BRAS sugestion
In-Reply-To: <CA+bbMkvAcN3h8QaouWCHa4SmAw5HRz5VGXKoBFuaS7CAV_pFpQ@mail.gmail.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
 <CAFFgAjApfSU_byQu7fpdN2BDSa-r-g72gvi-_+A3wVLd8gMAYw@mail.gmail.com>
 <CA+bbMkvAcN3h8QaouWCHa4SmAw5HRz5VGXKoBFuaS7CAV_pFpQ@mail.gmail.com>
Message-ID: <55CE1CD3.2040000@alter3d.ca>

The Walmart ones cost less upfront, but their support sucks.  This often 
leads to sags in performance, especially from the view of the average 
eyeball network user, which results in personal discomfort when senior 
management determines that the best way to resolve the issue is to bring 
in some external consultants to really strip the system down and get 
hands-on with optimizing heap sizes.



On 08/14/2015 12:04 PM, Alistair Mackenzie wrote:
> I'm pretty sure this would get expensive for 30k+.
>
> Perhaps try Walmart?
>
> On 14 August 2015 at 17:01, Mike Lyon <mike.lyon at gmail.com> wrote:
>
>> Victoria's Secret
>> On Aug 14, 2015 8:08 AM, "Julian Eble" <julianeble at yahoo.com.br> wrote:
>>
>>> Hello Nanog,
>>> Our company are constantly growing and we're looking for a 30k+
>>> subscribers BRAS, does the community have a sugestion?
>>>
>>> Thank you!
>>>


From baldur.norddahl at gmail.com  Fri Aug 14 17:00:45 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 14 Aug 2015 19:00:45 +0200
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAPkb-7AZGLV6KLzjsv4uNBCR1xzevuRrBQjCddMfbmDwAwv_Qg@mail.gmail.com>

I have a related question. What functionality defines BRAS?

I do not think I have any BRAS in my network, but I am not sure :-)

Regards,

Baldur

From cscora at apnic.net  Fri Aug 14 18:12:59 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 15 Aug 2015 04:12:59 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201508141812.t7EICxYk028592@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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 15 Aug, 2015

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

Analysis Summary
----------------

BGP routing table entries examined:                              555591
    Prefixes after maximum aggregation (per Origin AS):          209897
    Deaggregation factor:                                          2.65
    Unique aggregates announced (without unneeded subnets):      271515
Total ASes present in the Internet Routing Table:                 51157
    Prefixes per ASN:                                             10.86
Origin-only ASes present in the Internet Routing Table:           36687
Origin ASes announcing only one prefix:                           16138
Transit ASes present in the Internet Routing Table:                6349
Transit-only ASes present in the Internet Routing Table:            171
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      45
    Max AS path prepend of ASN ( 55644)                              41
Prefixes from unregistered ASNs in the Routing Table:              1137
    Unregistered ASNs in the Routing Table:                         417
Number of 32-bit ASNs allocated by the RIRs:                      10589
Number of 32-bit ASNs visible in the Routing Table:                8121
Prefixes from 32-bit ASNs in the Routing Table:                   30113
Number of bogon 32-bit ASNs visible in the Routing Table:            17
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            469
Number of addresses announced to Internet:                   2791842272
    Equivalent to 166 /8s, 104 /16s and 33 /24s
    Percentage of available address space announced:               75.4
    Percentage of allocated address space announced:               75.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.6
Total number of prefixes smaller than registry allocations:      185606

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   137009
    Total APNIC prefixes after maximum aggregation:               39843
    APNIC Deaggregation factor:                                    3.44
Prefixes being announced from the APNIC address blocks:          144204
    Unique aggregates announced from the APNIC address blocks:    59017
APNIC Region origin ASes present in the Internet Routing Table:    5075
    APNIC Prefixes per ASN:                                       28.41
APNIC Region origin ASes announcing only one prefix:               1195
APNIC Region transit ASes present in the Internet Routing Table:    892
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         45
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1594
Number of APNIC addresses announced to Internet:              750617152
    Equivalent to 44 /8s, 189 /16s and 130 /24s
    Percentage of available APNIC address space announced:         87.7

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:                    180583
    Total ARIN prefixes after maximum aggregation:                88197
    ARIN Deaggregation factor:                                     2.05
Prefixes being announced from the ARIN address blocks:           183340
    Unique aggregates announced from the ARIN address blocks:     85722
ARIN Region origin ASes present in the Internet Routing Table:    16588
    ARIN Prefixes per ASN:                                        11.05
ARIN Region origin ASes announcing only one prefix:                6063
ARIN Region transit ASes present in the Internet Routing Table:    1739
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:     601
Number of ARIN addresses announced to Internet:              1103720224
    Equivalent to 65 /8s, 201 /16s and 111 /24s
    Percentage of available ARIN address space announced:          58.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, 64198-64296, 393216-395164
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:                    134477
    Total RIPE prefixes after maximum aggregation:                67196
    RIPE Deaggregation factor:                                     2.00
Prefixes being announced from the RIPE address blocks:           141153
    Unique aggregates announced from the RIPE address blocks:     87697
RIPE Region origin ASes present in the Internet Routing Table:    17968
    RIPE Prefixes per ASN:                                         7.86
RIPE Region origin ASes announcing only one prefix:                8068
RIPE Region transit ASes present in the Internet Routing Table:    2967
Average RIPE Region AS path length visible:                         4.5
    Max RIPE Region AS path length visible:                          40
Number of RIPE region 32-bit ASNs visible in the Routing Table:    3939
Number of RIPE addresses announced to Internet:               699098752
    Equivalent to 41 /8s, 171 /16s and 102 /24s
    Percentage of available RIPE address space announced:         101.6

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-204287
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:                   60885
    Total LACNIC prefixes after maximum aggregation:              11560
    LACNIC Deaggregation factor:                                   5.27
Prefixes being announced from the LACNIC address blocks:          72180
    Unique aggregates announced from the LACNIC address blocks:   33385
LACNIC Region origin ASes present in the Internet Routing Table:   2463
    LACNIC Prefixes per ASN:                                      29.31
LACNIC Region origin ASes announcing only one prefix:               616
LACNIC Region transit ASes present in the Internet Routing Table:   510
Average LACNIC Region AS path length visible:                       5.1
    Max LACNIC Region AS path length visible:                        28
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1848
Number of LACNIC addresses announced to Internet:             168753920
    Equivalent to 10 /8s, 14 /16s and 251 /24s
    Percentage of available LACNIC address space announced:       100.6

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:                  12336
    Total AfriNIC prefixes after maximum aggregation:              3053
    AfriNIC Deaggregation factor:                                  4.04
Prefixes being announced from the AfriNIC address blocks:         14245
    Unique aggregates announced from the AfriNIC address blocks:   5286
AfriNIC Region origin ASes present in the Internet Routing Table:   739
    AfriNIC Prefixes per ASN:                                     19.28
AfriNIC Region origin ASes announcing only one prefix:              196
AfriNIC Region transit ASes present in the Internet Routing Table:  162
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  139
Number of AfriNIC addresses announced to Internet:             69037056
    Equivalent to 4 /8s, 29 /16s and 108 /24s
    Percentage of available AfriNIC address space announced:       68.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     3011      11302         988   Korea Telecom
 7545     2766        339         136   TPG Telecom Limited
17974     2706        904          80   PT Telekomunikasi Indonesia
 4755     2031        426         225   TATA Communications formerly 
 4538     1950       4190          71   China Education and Research 
 9829     1863       1372         196   National Internet Backbone
 9808     1577       8639          18   Guangdong Mobile Communicatio
 4808     1524       2252         471   CNCGROUP IP network China169 
 9583     1523        120         572   Sify Limited
 9498     1376        335         109   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     3181       2961         140   Cox Communications Inc.
 6389     2715       3688          51   BellSouth.net Inc.
 3356     2563      10710         512   Level 3 Communications, Inc.
18566     2114        386         244   MegaPath Corporation
20115     1874       1853         405   Charter Communications
 6983     1740        851         243   EarthLink, Inc.
 4323     1589       1005         411   tw telecom holdings, inc.
30036     1573        319         458   Mediacom Communications Corp
  701     1409      11393         687   MCI Communications Services, 
22561     1373        415         256   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
20940     2069        817        1498   Akamai International B.V.
34984     2031        305         379   TELLCOM ILETISIM HIZMETLERI A
 6849     1207        355          21   JSC "Ukrtelecom"
13188     1068         97          77   TOV "Bank-Inform"
31148     1055         46          24   Freenet Ltd.
 8551      996        376          52   Bezeq International-Ltd
12479      978        933          77   France Telecom Espana SA
 8402      948        544          15   OJSC "Vimpelcom"
 6830      918       2696         471   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     3342        539         146   Telmex Colombia S.A.
28573     2282       2171         119   NET Servi?os de Comunica??o S
 8151     1685       3261         486   Uninet S.A. de C.V.
 7303     1560        931         240   Telecom Argentina S.A.
 6147     1447        374          30   Telefonica del Peru S.A.A.
 6503     1251        421          55   Axtel, S.A.B. de C.V.
26615     1075       2325          35   Tim Celular S.A.
 7738      996       1882          41   Telemar Norte Leste S.A.
 3816      947        430         162   COLOMBIA TELECOMUNICACIONES S
11830      922        364          15   Instituto Costarricense de El

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      903        280          26   Link Egypt (Link.NET)
 8452      857       1470          14   TE-AS
36903      512        258          99   Office National des Postes et
36992      442       1229          32   ETISALAT MISR
37492      312        175          71   Orange Tunisie
24835      308        146          12   Vodafone Data
 3741      252        857         208   Internet Solutions
29571      248         21          13   Cote d'Ivoire Telecom
37054      211         20           7   Data Telecom Service
36947      183        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     3342        539         146   Telmex Colombia S.A.
22773     3181       2961         140   Cox Communications Inc.
 4766     3011      11302         988   Korea Telecom
 7545     2766        339         136   TPG Telecom Limited
 6389     2715       3688          51   BellSouth.net Inc.
17974     2706        904          80   PT Telekomunikasi Indonesia
 3356     2563      10710         512   Level 3 Communications, Inc.
39891     2472        128           6   SaudiNet, Saudi Telecom Compa
28573     2282       2171         119   NET Servi?os de Comunica??o S
18566     2114        386         244   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      3181        3041      Cox Communications Inc.
 6389      2715        2664      BellSouth.net Inc.
 7545      2766        2630      TPG Telecom Limited
17974      2706        2626      PT Telekomunikasi Indonesia
39891      2472        2466      SaudiNet, Saudi Telecom Compa
28573      2282        2163      NET Servi?os de Comunica??o S
 3356      2563        2051      Level 3 Communications, Inc.
 4766      3011        2023      Korea Telecom
 4538      1950        1879      China Education and Research 
18566      2114        1870      MegaPath Corporation

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
47092   UNALLOCATED  8.8.204.0/24         16410       The Reynolds and Rey
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
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

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.1.0/24        9730     Bharti Telesonic Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.56.0/22       23456     32bit Transition AS
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
23.249.144.0/21      40430     colo4jax, LLC
23.249.152.0/21      40430     colo4jax, LLC
27.54.116.0/22       23456     32bit Transition AS
27.96.88.0/22        23456     32bit Transition AS
27.100.7.0/24        56096     >>UNKNOWN<<
27.100.24.0/22       23456     32bit Transition AS
27.109.124.0/22      23456     32bit Transition AS

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:17       /9:13      /10:36      /11:96      /12:263     
/13:505     /14:1002    /15:1731    /16:12890   /17:7251    /18:12377   
/19:25530   /20:36031   /21:38782   /22:61043   /23:53092   /24:301881  
/25:1121    /26:1155    /27:716     /28:14      /29:14      /30:9       
/31:0       /32:22      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2432          2472      SaudiNet, Saudi Telecom Compa
22773     2373          3181      Cox Communications Inc.
18566     2039          2114      MegaPath Corporation
 6389     1610          2715      BellSouth.net Inc.
30036     1394          1573      Mediacom Communications Corp
 6983     1385          1740      EarthLink, Inc.
34984     1340          2031      TELLCOM ILETISIM HIZMETLERI A
10620     1209          3342      Telmex Colombia S.A.
11492     1112          1196      CABLE ONE, INC.
22561     1046          1373      CenturyTel Internet Holdings,

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1540      2:691       4:97        5:1851      6:25        8:1384   
  12:1806     13:14       14:1403     15:17       16:2        17:42     
  18:22       20:49       23:1308     24:1747     27:2029     31:1575   
  32:37       33:2        34:4        35:3        36:158      37:2002   
  38:1037     39:14       40:70       41:2804     42:302      43:1416   
  44:31       45:953      46:2358     47:52       49:930      50:789    
  52:15       54:86       55:5        56:6        57:42       58:1350   
  59:718      60:480      61:1753     62:1370     63:1904     64:4428   
  65:2251     66:4036     67:2062     68:1071     69:3240     70:1029   
  71:449      72:1971     74:2587     75:353      76:390      77:1322   
  78:1127     79:812      80:1358     81:1333     82:858      83:719    
  84:783      85:1351     86:450      87:1041     88:538      89:1945   
  90:147      91:5938     92:846      93:2276     94:2080     95:2192   
  96:413      97:347      98:987      99:56      100:75      101:851    
 103:8025    104:1988    105:71      106:347     107:1051    108:624    
 109:2126    110:1191    111:1455    112:811     113:1101    114:846    
 115:1296    116:1452    117:1075    118:1885    119:1454    120:455    
 121:1087    122:2160    123:1842    124:1525    125:1618    128:651    
 129:393     130:429     131:1245    132:527     133:171     134:410    
 135:102     136:351     137:328     138:1108    139:145     140:241    
 141:492     142:668     143:532     144:543     145:126     146:795    
 147:589     148:1261    149:429     150:570     151:801     152:528    
 153:253     154:495     155:869     156:427     157:421     158:358    
 159:1033    160:407     161:664     162:2020    163:456     164:701    
 165:709     166:300     167:856     168:1247    169:188     170:1469   
 171:253     172:245     173:1514    174:719     175:696     176:1423   
 177:3876    178:2160    179:977     180:1937    181:1662    182:1792   
 183:632     184:763     185:4066    186:2908    187:1839    188:2068   
 189:1594    190:7811    191:1113    192:8615    193:5654    194:4220   
 195:3649    196:1993    197:1054    198:5620    199:5508    200:6677   
 201:3281    202:9507    203:9160    204:4684    205:2851    206:3024   
 207:2988    208:4000    209:3918    210:3597    211:1919    212:2526   
 213:2258    214:841     215:74      216:5746    217:1833    218:735    
 219:462     220:1542    221:809     222:473     223:817    

End of report

From clinton at scripty.com  Fri Aug 14 18:29:58 2015
From: clinton at scripty.com (Clinton Work)
Date: Fri, 14 Aug 2015 12:29:58 -0600
Subject: BRAS sugestion
In-Reply-To: <CAPkb-7AZGLV6KLzjsv4uNBCR1xzevuRrBQjCddMfbmDwAwv_Qg@mail.gmail.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
 <CAPkb-7AZGLV6KLzjsv4uNBCR1xzevuRrBQjCddMfbmDwAwv_Qg@mail.gmail.com>
Message-ID: <1439576998.3539919.356486145.351DD28B@webmail.messagingengine.com>

BRAS functionality would normally be large scale DHCP or PPPoE customer
termination handled by RADIUS for authentication and policy management.  


On Fri, Aug 14, 2015, at 11:00 AM, Baldur Norddahl wrote:
> I have a related question. What functionality defines BRAS?
> 
> I do not think I have any BRAS in my network, but I am not sure :-)

From tarko at lanparty.ee  Fri Aug 14 19:15:56 2015
From: tarko at lanparty.ee (Tarko Tikan)
Date: Fri, 14 Aug 2015 22:15:56 +0300
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <55CE3E6C.7060001@lanparty.ee>

hey,

> Our company are constantly growing and we're looking for a 30k+
> subscribers BRAS, does the community have a sugestion?

I can tell only good stories about Alcatel 7750-SR. Extensive BNG 
feature set (both v4 and v6) and very stable platform.

-- 
tarko

From jimpop at gmail.com  Fri Aug 14 19:16:15 2015
From: jimpop at gmail.com (Jim Popovitch)
Date: Fri, 14 Aug 2015 15:16:15 -0400
Subject: Data Center operations mail list?
In-Reply-To: <55CBE688.20802@daa.com.au>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <ximss-516184@mail.ropeguru.com>
 <CAJB2g-GiaBNFS6gqKRppZ8hBzL5NvtTAD60Sz7bsk-3WR3krUg@mail.gmail.com>
 <55CBE688.20802@daa.com.au>
Message-ID: <CAGfsgR3DpDpvg1UQr8_CSn=VRK5amNBUZYRSTEc-i9cAk5ynDg@mail.gmail.com>

On Wed, Aug 12, 2015 at 8:36 PM, Phill Twiss <phill at daa.com.au> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> De-lurking
>
> Hi Rafael and everyone else :}( sorry the cross-post )
>
>         You should really have captcha's configured for your mailman lists
>
>         Some shady actors out there are using mailman lists to target certain
> email addresses.  Its a pretty dumb attack, but its annoying :}
>
>         The target will be hit by hundreds ( if not thousands ) of subscribe
> confirmation requests.
>
>         We changed to captcha's a month or more ago, we still get an average
> of 300 od IP's trying to do this in period of a few hours.
>
>         Keep an eye out in your logfiles for some of the strings below ( they
> all seem to try to use the same password ), if you have any issues
> with getting captcha's to work properly, drop me an email :}
>
>         Below is an sanitised ( list name and target) entry from the Apache
> logs ( the IP is real, screw em :} )
>
> 64.234.104.150 - - [13/Aug/2015:08:15:54 +0800] "GET
> /mailman/subscribe/<<Sanitised list name >>?email=<< Sanitised_TARGET
>>> @YAHOO.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&diges
> t=0&email-button=Subscribe
> HTTP/1.1"
>>>
> 301 801 "http://tools.vietche.biz/Boom/" "Mozilla/5.0
> (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0"

That's a very old (in Internet Years) Mailman problem that was solved
with session cookies in v2.1.16 (16-Oct-2013).  If you're still
paranoid, and don't want to piss your users off with privacy leaking
captcha, then just set up some referer checking in your apache or
nginx configs:

Apache:

      # Prevent subscription request spam
     SetEnvIf Referer lists\.example\.com localreferer
     <Location /mailman/subscribe>
        Order deny,allow
        Deny from all
        Allow from env=localreferer
     </Location>

Nginx:

        location /mailman/subscribe {
                valid_referers server_names;
                if ($invalid_referer) { return 403; }
        }


-Jim P.

From jazzbotley at gmail.com  Fri Aug 14 21:46:58 2015
From: jazzbotley at gmail.com (Jeff Wilson)
Date: Fri, 14 Aug 2015 16:46:58 -0500
Subject: Some Verizon FIOS subscribers in DFW blocked from tcp80/443 to
 regional higher-eds
Message-ID: <CACDW_ufvXYCJ-XV+6rPyiDnXCmPHWAEqRASHLhLeQTJWUTDM5Q@mail.gmail.com>

Our help desk has fielded dozens of calls from Verizon FIOS subscribers in
the Dallas/Ft Worth area. Traceroutes from Verizon subscribers make it to
campus, and traceroutes from campus make it to the subscribers' IP
addresses. One subscriber can hit some of our websites, another subscriber
can hit none. The outage is inconsistent, as if some kind of deep-packet
inspection is in play.

My upstream tells me we're not the only higher-ed affected.

Any advice on how to get hold of Verizon NOC?

-- 

Regards,
Jeff

a.k.a. jeff (underscore) wilson (at) baylor (dot) edu
AS 30674

From rafael at gav.ufsc.br  Fri Aug 14 21:52:10 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Fri, 14 Aug 2015 16:52:10 -0500
Subject: Data Center operations mail list?
In-Reply-To: <CAGfsgR3DpDpvg1UQr8_CSn=VRK5amNBUZYRSTEc-i9cAk5ynDg@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <ximss-516184@mail.ropeguru.com>
 <CAJB2g-GiaBNFS6gqKRppZ8hBzL5NvtTAD60Sz7bsk-3WR3krUg@mail.gmail.com>
 <55CBE688.20802@daa.com.au>
 <CAGfsgR3DpDpvg1UQr8_CSn=VRK5amNBUZYRSTEc-i9cAk5ynDg@mail.gmail.com>
Message-ID: <CAJB2g-H31JjJa56oOXcGn99KY9GZMcE13f-GZqyz_SOVJc5JCw@mail.gmail.com>

Thanks! That works for Apache2.2. For those interested that are using
Apache2.4, make this change:

-Order deny,allow
-Deny from all
+Require all denied

The rest should be the same. Here is some more info:
http://httpd.apache.org/docs/2.4/upgrading.html


Best,
Rafael




On Fri, Aug 14, 2015 at 2:16 PM, Jim Popovitch <jimpop at gmail.com> wrote:

> That's a very old (in Internet Years) Mailman problem that was solved
> with session cookies in v2.1.16 (16-Oct-2013).  If you're still
> paranoid, and don't want to piss your users off with privacy leaking
> captcha, then just set up some referer checking in your apache or
> nginx configs:
>
> Apache:
>
>       # Prevent subscription request spam
>      SetEnvIf Referer lists\.example\.com localreferer
>      <Location /mailman/subscribe>
>         Order deny,allow
>         Deny from all
>         Allow from env=localreferer
>      </Location>
> -Jim P.
>

From cidr-report at potaroo.net  Fri Aug 14 22:00:00 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 14 Aug 2015 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201508142200.t7EM00SG053050@wattle.apnic.net>

This report has been generated at Fri Aug 14 21:14:47 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
        07-08-15    560808      308900
        08-08-15    563028      308941
        09-08-15    562862      308856
        10-08-15    562870      309114
        11-08-15    563278      308945
        12-08-15    563468      309531
        13-08-15    563435      309686
        14-08-15    564268      309596


AS Summary
         51439  Number of ASes in routing system
         20401  Number of ASes announcing only one prefix
          3351  Largest number of prefixes announced by an AS
                AS10620: Telmex Colombia S.A.,CO
      120888576  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').

 --- 14Aug15 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     564392   309560   254832    45.2%   All ASes

AS22773     3184      170     3014    94.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS17974     2706       80     2626    97.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS39891     2473       35     2438    98.6%   ALJAWWALSTC-AS Saudi Telecom
                                               Company JSC,SA
AS28573     2282      126     2156    94.5%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS6389      2715      723     1992    73.4%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS9394      2286      318     1968    86.1%   CTTNET China TieTong
                                               Telecommunications
                                               Corporation,CN
AS3356      2571      634     1937    75.3%   LEVEL3 - Level 3
                                               Communications, Inc.,US
AS7545      2878     1031     1847    64.2%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS10620     3351     1706     1645    49.1%   Telmex Colombia S.A.,CO
AS4766      3011     1459     1552    51.5%   KIXS-AS-KR Korea Telecom,KR
AS9808      1577       54     1523    96.6%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS6983      1739      246     1493    85.9%   ITCDELTA - Earthlink, Inc.,US
AS20115     1874      418     1456    77.7%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS4755      2031      704     1327    65.3%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS9498      1376      119     1257    91.4%   BBIL-AP BHARTI Airtel Ltd.,IN
AS4323      1594      412     1182    74.2%   TWTC - tw telecom holdings,
                                               inc.,US
AS18566     2115      940     1175    55.6%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS6147      1447      278     1169    80.8%   Telefonica del Peru S.A.A.,PE
AS7303      1560      423     1137    72.9%   Telecom Argentina S.A.,AR
AS6849      1208       74     1134    93.9%   UKRTELNET JSC UKRTELECOM,UA
AS22561     1373      321     1052    76.6%   CENTURYLINK-LEGACY-LIGHTCORE -
                                               CenturyTel Internet Holdings,
                                               Inc.,US
AS4808      1542      512     1030    66.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network,CN
AS7552      1135      137      998    87.9%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS8151      1687      732      955    56.6%   Uninet S.A. de C.V.,MX
AS7738       996       77      919    92.3%   Telemar Norte Leste S.A.,BR
AS8402       939       21      918    97.8%   CORBINA-AS OJSC "Vimpelcom",RU
AS26615     1075      210      865    80.5%   Tim Celular S.A.,BR
AS38285      981      134      847    86.3%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU
AS55430      857       67      790    92.2%   STARHUBINTERNET-AS-NGNBN
                                               Starhub Internet Pte Ltd,SG
AS24560     1245      457      788    63.3%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services,IN

Total      55808    12618    43190    77.4%   Top 30 total


Possible Bogus Routes

        14.192.56.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        23.226.112.0/20      AS62788 -Reserved AS-,ZZ
        23.249.144.0/20      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        23.249.144.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        23.249.152.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        27.54.116.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.96.88.0/22        AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.100.7.0/24        AS56096 
        27.100.24.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.109.124.0/22      AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.111.72.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.112.120.0/22      AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.116.40.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        27.122.60.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        31.170.96.0/23       AS19798 YOUZEE-MAIN Manaslu Media Entertainment SL,ES
        31.217.248.0/21      AS44902 COV-ASN COVAGE NETWORKS SASU,FR
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.3.0/24         AS37004 -Reserved AS-,ZZ
        41.73.4.0/24         AS37004 -Reserved AS-,ZZ
        41.73.5.0/24         AS37004 -Reserved AS-,ZZ
        41.73.6.0/24         AS37004 -Reserved AS-,ZZ
        41.73.7.0/24         AS37004 -Reserved AS-,ZZ
        41.73.8.0/24         AS37004 -Reserved AS-,ZZ
        41.73.9.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.14.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.17.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.126.0/24      AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        41.189.127.0/24      AS37000 -Reserved AS-,ZZ
        41.189.128.0/24      AS37000 -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.254.196.0/24      AS31972 EMGINECONCEPT-01 - Emagine Concept, Inc.,US
        61.14.224.0/19       AS20043 STADIS-LLC-AS LLC Stadis,RU
        64.28.145.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.28.146.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.57.192.0/22       AS33321 -Reserved AS-,ZZ
        64.234.239.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.,US
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.,US
        66.11.224.0/21       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.234.0/24       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.236.0/22       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.59.192.0/19       AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.228.160.0/20      AS7233  YAHOO-US - Yahoo,US
        66.228.176.0/21      AS17110 YAHOO-US2 - Yahoo,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
        68.234.0.0/19        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.0.0/20        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.5.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.7.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.16.0/20       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.16.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.17.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.18.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.19.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.20.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.21.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.22.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.23.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.24.0/22       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.26.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.28.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.29.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        69.24.96.0/20        AS26804 -Reserved AS-,ZZ
        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.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
        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
        100.64.8.0/24        AS10620 Telmex Colombia S.A.,CO
        100.64.11.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.12.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.22.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.23.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.24.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.25.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.26.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.27.0/24       AS10620 Telmex Colombia S.A.,CO
        100.100.1.0/24       AS9730  BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN
        103.1.220.0/22       AS20422 OJSC-KOMMUNENERGO-AS OJSC Kommunenergo,RU
        103.5.192.0/22       AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        103.6.108.0/22       AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        103.9.184.0/22       AS58616 
        103.10.222.0/24      AS13189 
        103.11.16.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.13.1.0/24        AS58609 
        103.14.24.0/24       AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.44.0/24       AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID
        103.18.45.0/24       AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID
        103.18.47.0/24       AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID
        103.20.100.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.101.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.219.0/24      AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU
        103.22.212.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.23.148.0/23      AS13209 
        103.23.148.0/24      AS13209 
        103.23.149.0/24      AS13209 
        103.25.144.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.37.188.0/22      AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.225.116.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.228.8.0/22       AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.229.152.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.231.36.0/22      AS2519  VECTANT VECTANT Ltd.,JP
        103.232.142.0/23     AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG
        103.232.164.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.233.140.0/23     AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF
        103.234.8.0/22       AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.244.112.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.52.0/22      AS2519  VECTANT VECTANT Ltd.,JP
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.196.0/22     AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.249.72.0/22      AS13282 GATEWAY-AS-AP GATEWAY INC,JP
        103.250.220.0/24     AS58973 
        103.250.221.0/24     AS58973 
        103.253.164.0/23     AS13317 
        106.0.32.0/19        AS20043 STADIS-LLC-AS LLC Stadis,RU
        112.140.188.0/22     AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        113.20.156.0/22      AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        116.12.32.0/21       AS38555 
        116.12.32.0/24       AS38555 
        116.193.164.0/22     AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        116.199.203.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.205.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.206.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.207.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        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
        118.103.160.0/19     AS20043 STADIS-LLC-AS LLC Stadis,RU
        119.42.32.0/19       AS20043 STADIS-LLC-AS LLC Stadis,RU
        124.40.240.0/22      AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        124.108.20.0/22      AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        125.254.52.0/22      AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        130.51.0.0/17        AS20055 RUCLICK-AS RU-CLICK LLC,RU
        138.117.224.0/19     AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        142.147.62.0/24      AS3958  AIRCANADA - Air Canada,CA
        142.147.101.0/24     AS13855 CFU-NET - The Municipal Communications Utility of the City of Cedar Falls, Iowa,US
        151.216.32.0/24      AS20199 SERVERPARS Rayan Pardaz Khorshid Shargh Ltd.,IR
        154.168.28.0/23      AS29571 CITelecom-AS,CI
        160.19.16.0/22       AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        160.19.40.0/22       AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        162.216.176.0/22     AS36114 VERSAWEB-ASN - Versaweb, LLC,US
        162.221.44.0/22      AS10431 -Reserved AS-,ZZ
        162.221.64.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        162.221.64.0/22      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        162.221.68.0/22      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        162.222.128.0/21     AS36114 VERSAWEB-ASN - Versaweb, LLC,US
        162.245.64.0/21      AS62788 -Reserved AS-,ZZ
        162.245.100.0/23     AS10431 -Reserved AS-,ZZ
        162.245.102.0/24     AS10431 -Reserved AS-,ZZ
        162.245.103.0/24     AS10431 -Reserved AS-,ZZ
        162.248.224.0/21     AS62788 -Reserved AS-,ZZ
        166.93.0.0/16        AS23537 CRITIGEN - Micro Source, Inc.,US
        167.88.48.0/20       AS29927 -Reserved AS-,ZZ
        170.95.0.0/16        AS20055 RUCLICK-AS RU-CLICK LLC,RU
        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
        173.249.191.0/24     AS45816 ISHK-AP I-Services Network Solution Limited,HK
        180.222.120.0/21     AS23818 JETINTERNET JETINTERNET Corporation,JP
        181.225.156.0/22     AS10834 Telefonica de Argentina,AR
        185.17.98.0/23       AS19798 HILF-AS Hilf Telecom B.V.,NL
        185.52.57.0/24       AS48039 KGT-AS KGT new media,DE
        185.52.58.0/24       AS48039 KGT-AS KGT new media,DE
        185.113.116.0/22     AS21446 AS21446 VPK-Telecom,RU
        186.148.224.0/21     AS52302 Awknet International, S.A.,PA
        189.14.112.0/20      AS52720 WEBFOCO TELECOMUNICACOES LTDA,BR
        189.14.116.0/22      AS28282 -Reserved AS-,ZZ
        189.14.120.0/22      AS28282 -Reserved AS-,ZZ
        189.14.124.0/22      AS28282 -Reserved AS-,ZZ
        190.111.128.0/19     AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        190.111.160.0/19     AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        190.112.128.0/19     AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        190.115.64.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        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.67.160.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.67.161.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.67.162.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.75.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.46.0/23      AS17139 NETRANGE - Corporate Colocation 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.195.36.0/24      AS63242 LIGHTSPEED-COMMUNICATIONS - Lightspeed Communications, LLC,US
        192.206.140.0/24     AS54926 -Reserved AS-,ZZ
        192.206.141.0/24     AS54926 -Reserved AS-,ZZ
        192.206.142.0/24     AS54926 -Reserved AS-,ZZ
        192.206.143.0/24     AS54926 -Reserved AS-,ZZ
        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.22.224.0/20      AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        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.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.56.203.0/24      AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR
        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.151.160.0/19     AS39906 COPROSYS CoProSys a.s.,CZ
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        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.130.0/24     AS21104 AM-NETSYS-AS Netsys JV LLC,AM
        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.8.0/21       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.9.9.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.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.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        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.180.0/24       AS37004 -Reserved AS-,ZZ
        196.3.181.0/24       AS37004 -Reserved AS-,ZZ
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        196.22.11.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        198.8.72.0/21        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.72.0/22        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.76.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.77.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.78.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.79.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,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.91.44.0/22       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.44.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.45.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.46.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.47.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,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.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.103.89.0/24      AS19523 -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.50.192.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        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
        200.124.64.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        201.77.5.0/24        AS28650 Lojas Simonetti Ltda,BR
        201.77.7.0/24        AS28650 Lojas Simonetti Ltda,BR
        201.131.5.0/24       AS28389 -Reserved AS-,ZZ
        201.131.88.0/24      AS8151  Uninet S.A. de C.V.,MX
        201.216.64.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        201.216.96.0/19      AS20422 CJSC-MMS-AS CJSC Mashzavod-Marketing-Servis,RU
        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.133.208.0/20     AS17440 IDNIC-ID Indonesia Network Information Center,ID
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom,SG
        202.160.128.0/19     AS20043 STADIS-LLC-AS LLC Stadis,RU
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK
        203.76.224.0/19      AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        203.78.130.0/24      AS18222 
        203.95.192.0/19      AS20418 LLC-SK-CONTINENT-AS LLC SK Continent,RU
        203.142.219.0/24     AS45149 
        203.160.48.0/21      AS38008 
        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.153.206.0/23     AS3561  CENTURYLINK-LEGACY-SAVVIS - Savvis,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.44.0/24       AS11065 -Reserved AS-,ZZ
        208.67.45.0/24       AS11065 -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.74.12.0/23       AS209   CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.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.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
        212.81.32.0/23       AS41175 INTERNETBORDER Internet Border Technologies AB,SE
        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 Aug 14 22:00:01 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 14 Aug 2015 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201508142200.t7EM01iw053064@wattle.apnic.net>

BGP Update Report
Interval: 06-Aug-15 -to- 13-Aug-15 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS38197          414510 10.4%     318.6 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK
 2 - AS9829           213210  5.3%     151.6 -- BSNL-NIB National Internet Backbone,IN
 3 - AS16637          137322  3.5%    1387.1 -- MTNNS-AS,ZA
 4 - AS22059          124965  3.1%   62482.5 -- -Reserved AS-,ZZ
 5 - AS36947           88843  2.2%    1233.9 -- ALGTEL-AS,DZ
 6 - AS12091           76867  1.9%    1671.0 -- MTNNS-AS,ZA
 7 - AS28024           74066  1.9%      47.1 -- Nuevatel PCS de Bolivia S.A.,BO
 8 - AS21669           70249  1.8%   11708.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US
 9 - AS3709            60561  1.5%    2243.0 -- NET-CITY-SA - City of San Antonio,US
10 - AS11139           36179  0.9%     128.8 -- CWDOM - Cable & Wireless Dominica,DM
11 - AS8402            35269  0.9%     251.9 -- CORBINA-AS OJSC "Vimpelcom",RU
12 - AS30295           31181  0.8%    3897.6 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
13 - AS56636           29122  0.7%   29122.0 -- ASVEDARU VEDA Ltd.,RU
14 - AS197068           28112  0.7%    2008.0 -- QRATOR HLL LLC,RU
15 - AS25563           27957  0.7%    9319.0 -- WEBLAND-AS Webland AG,CH
16 - AS131090           27379  0.7%    1521.1 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
17 - AS11056           25658  0.6%   25658.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US
18 - AS45528           25137  0.6%      78.1 -- TDN Tikona Digital Networks Pvt Ltd.,IN
19 - AS14522           23763  0.6%      84.9 -- Satnet,EC
20 - AS2088            17660  0.4%    4415.0 -- FR-RENATER-MAYOTTE Reseau National de telecommunications pour la Technologie,EU


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS22059          124965  3.1%   62482.5 -- -Reserved AS-,ZZ
 2 - AS56636           29122  0.7%   29122.0 -- ASVEDARU VEDA Ltd.,RU
 3 - AS11056           25658  0.6%   25658.0 -- BERGERMONTAGUE - Berger & Montague, P.C,US
 4 - AS31357           14347  0.4%   14347.0 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
 5 - AS46464           12235  0.3%   12235.0 -- AUC-1882 - Atlantic Union College,US
 6 - AS21669           70249  1.8%   11708.2 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US
 7 - AS197914           11435  0.3%   11435.0 -- STOCKHO-AS Stockho Hosting SARL,FR
 8 - AS40493           10560  0.3%   10560.0 -- FACILITYSOURCEINC - FacilitySource,US
 9 - AS59771           10284  0.3%   10284.0 -- WIOLLO-AS Wiollo Sp. z o.o.,PL
10 - AS393588            9551  0.2%    9551.0 -- MUBEA-FLO - Mubea,US
11 - AS25563           27957  0.7%    9319.0 -- WEBLAND-AS Webland AG,CH
12 - AS37590            6673  0.2%    6673.0 -- BCA-ASN,AO
13 - AS21973            5213  0.1%    5213.0 -- XPONET - Xponet,US
14 - AS2088            17660  0.4%    4415.0 -- FR-RENATER-MAYOTTE Reseau National de telecommunications pour la Technologie,EU
15 - AS30295           31181  0.8%    3897.6 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
16 - AS200562            3881  0.1%    3881.0 -- WELLTEL-IE WELLTEL (IRELAND) LTD,IE
17 - AS38000            6687  0.2%    3343.5 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN
18 - AS47680            6373  0.2%    3186.5 -- NHCS EOBO Limited,IE
19 - AS6468             2902  0.1%    2902.0 -- EASYLINK-AS6468 - Easylink Services Corporation,US
20 - AS196742           11202  0.3%    2800.5 -- EKRAN-AS CJSC "Ekran",RU


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 105.96.0.0/22     86629  2.0%   AS36947 -- ALGTEL-AS,DZ
 2 - 209.212.8.0/24    70183  1.7%   AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US
 3 - 76.191.107.0/24   62524  1.5%   AS22059 -- -Reserved AS-,ZZ
 4 - 64.34.125.0/24    62441  1.5%   AS22059 -- -Reserved AS-,ZZ
 5 - 195.128.159.0/24  29122  0.7%   AS56636 -- ASVEDARU VEDA Ltd.,RU
 6 - 185.65.148.0/24   28080  0.7%   AS197068 -- QRATOR HLL LLC,RU
 7 - 61.7.155.0/24     27197  0.6%   AS131090 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
 8 - 50.202.59.0/24    25658  0.6%   AS11056 -- BERGERMONTAGUE - Berger & Montague, P.C,US
 9 - 78.140.0.0/18     14347  0.3%   AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
10 - 74.112.8.0/21     12235  0.3%   AS46464 -- AUC-1882 - Atlantic Union College,US
11 - 130.0.192.0/21    11435  0.3%   AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR
12 - 37.220.156.0/22   11159  0.3%   AS196742 -- EKRAN-AS CJSC "Ekran",RU
13 - 199.60.236.0/24   11004  0.3%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
14 - 66.19.194.0/24    10714  0.2%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.,US
15 - 8.17.26.0/24      10560  0.2%   AS40493 -- FACILITYSOURCEINC - FacilitySource,US
16 - 199.60.234.0/23   10469  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
17 - 185.72.196.0/22   10284  0.2%   AS59771 -- WIOLLO-AS Wiollo Sp. z o.o.,PL
18 - 199.60.233.0/24    9688  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
19 - 92.43.216.0/21     9560  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
20 - 192.58.137.0/24    9551  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 carlos at race.com  Fri Aug 14 22:27:46 2015
From: carlos at race.com (Carlos Alcantar)
Date: Fri, 14 Aug 2015 22:27:46 +0000
Subject: Some Verizon FIOS subscribers in DFW blocked from tcp80/443 to
 regional higher-eds
In-Reply-To: <CACDW_ufvXYCJ-XV+6rPyiDnXCmPHWAEqRASHLhLeQTJWUTDM5Q@mail.gmail.com>
References: <CACDW_ufvXYCJ-XV+6rPyiDnXCmPHWAEqRASHLhLeQTJWUTDM5Q@mail.gmail.com>
Message-ID: <DM2PR12MB0112950F911A8DCEE3AEAC54A07C0@DM2PR12MB0112.namprd12.prod.outlook.com>

don't know if it's related but someone posted on the outages list about a level3 fiber cut.  verizon and level3 could be in the same right of way.


?
Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com


________________________________________
From: NANOG <nanog-bounces at nanog.org> on behalf of Jeff Wilson <jazzbotley at gmail.com>
Sent: Friday, August 14, 2015 2:46 PM
To: nanog at nanog.org
Subject: Some Verizon FIOS subscribers in DFW blocked from tcp80/443 to regional higher-eds

Our help desk has fielded dozens of calls from Verizon FIOS subscribers in
the Dallas/Ft Worth area. Traceroutes from Verizon subscribers make it to
campus, and traceroutes from campus make it to the subscribers' IP
addresses. One subscriber can hit some of our websites, another subscriber
can hit none. The outage is inconsistent, as if some kind of deep-packet
inspection is in play.

My upstream tells me we're not the only higher-ed affected.

Any advice on how to get hold of Verizon NOC?

--

Regards,
Jeff

a.k.a. jeff (underscore) wilson (at) baylor (dot) edu
AS 30674


From modonovan at btireland.net  Fri Aug 14 15:32:58 2015
From: modonovan at btireland.net (Mick O Donovan)
Date: Fri, 14 Aug 2015 16:32:58 +0100
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <20150814153258.GA4905@carra.btireland.net>

On Fri, Aug 14, 2015 at 03:06:20PM +0000, Julian Eble wrote:
> Hello Nanog,
> Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion?
> 
> Thank you!

Cisco ASR 1004/6
Alcatel Lucent 7750 SR12 with MSA card

a WHOLE bunch of others :)

-- 
Mick O'Donovan | Network Engineer | BT Ireland |
Website: http://www.btireland.net
Looking Glass: http://lg.as2110.net
Peering Record: http://as2110.peeringdb.com
AS-SET Macro: AS-BTIRE | ASN: 2110
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150814/fba08901/attachment.pgp>

From jhamilton at empiredistrict.com  Fri Aug 14 21:30:30 2015
From: jhamilton at empiredistrict.com (Jordan Hamilton)
Date: Fri, 14 Aug 2015 21:30:30 +0000
Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent
 in Dallas 
Message-ID: <9E011DD002D07D44997466761AE668099F3468C9@SRV-EMPIRE183V.empiredistrict.com>

I have several customers that are having packet loss issues, the packet loss appears to be associated with a Cogent router interface of 38.104.86.222.  My upstream provider is telling me that the packet loss is being caused by a net neutrality peering dispute between CenturyTel/Quest and Cogent in Dallas.  I did some quick googling to see if I could come up with any articles or something like that I could provide to my customers and did not see anything.  Anyone know any details?

Thanks

Jordan Hamilton
Senior Telecommunications Engineer

Empire District Electric Co.
720 Schifferdecker
PO Box 127
Joplin, MO 64802

Ph:  417-625-4223
Cell:  417-388-3351


--
Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.  Check your e-mail security settings to determine how attachments are handled.

--
This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100.
Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited.

From ahad at telcoinabox.com  Sat Aug 15 01:58:29 2015
From: ahad at telcoinabox.com (Ahad Aboss)
Date: Sat, 15 Aug 2015 11:58:29 +1000
Subject: BRAS sugestion
In-Reply-To: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CF962BA7-AA67-4A6E-B2EC-5AB8DB4A8E21@telcoinabox.com>

Julian

If you have budget constraints, try getting 2 x ASR1004, else ASR1006 with dual RP would take care of your needs.


Cheers

Ahad
Sent from my iPhone

> On 15 Aug 2015, at 1:06 am, Julian Eble <julianeble at yahoo.com.br> wrote:
> 
> Hello Nanog,
> Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion?
> 
> Thank you!

From marcel.duregards at yahoo.fr  Sat Aug 15 12:07:37 2015
From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr)
Date: Sat, 15 Aug 2015 14:07:37 +0200
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <CAOLsBOv4quzg9a4Y5to7qVyy2=_U-uysKzO2hDwYuMDWSqffxQ@mail.gmail.com>
References: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
 <AEAE5C0D-FE2F-4542-B237-159BF09671A9@mac.com>
 <CAOLsBOv4quzg9a4Y5to7qVyy2=_U-uysKzO2hDwYuMDWSqffxQ@mail.gmail.com>
Message-ID: <55CF2B89.1010701@yahoo.fr>

One thing which is not so obvious is to reduce false positive.
This is hard when you have a mix of traffic profiles/patterns within 
your network, with customers in differents domains (scientists, 
financials, video addicted, torrent addicted, etc...) with different 
bandwidth.

a)
Does anybody tried to separate ip range by traffic profile to apply 
specific rule/profile per ip allocation?

puts all financials clients into range X/X and define rule Z
puts all scientists clients into range Y/Y and apply rule Q
etc....

Does this help ?

b)
One other method could be to classify customers by their bandwidth.

profile 1. from 10-100M
profile 2. 100-500M
profile 3. 500M-1000M
profile 4. >1000M

Like this you do not mix big BW with small BW customer, and do not get 
alerted when client from profile 4 start to download at 1G.

Any experience ?

My guess is that solution b is better than a. Not so easy to classify 
traffic pattern per group of client.

Thank, best regards.
- Marcel



On 13.08.2015 06:42, Ramy Hashish wrote:
> Hello Fabien,
>
> And why don't you use A10 for both detection and mitigation?
>
> Thanks,
>
> Ramy
>
> On Wed, Aug 12, 2015 at 6:42 PM, Fabien Delmotte <fdelmotte1 at mac.com> wrote:
>
>> Hello
>>
>> My 2 cents
>> You can use Wanguard for the detection and A10 for the mitigation, you
>> have just to play with the API.
>>
>> Regards
>>
>> Fabien
>>
>>> Le 12 ao?t 2015 ? 16:28, Ramy Hashish <ramy.ihashish at gmail.com> a ?crit
>> :
>>>
>>>>
>>>>
>>>> Date: Tue, 11 Aug 2015 08:14:54 +0200
>>>> From: "marcel.duregards at yahoo.fr" <marcel.duregards at yahoo.fr>
>>>> To: nanog at nanog.org
>>>> Subject: Re: Experience on Wanguard for 'anti' DDOS solutions
>>>> Message-ID: <55C992DE.3020906 at yahoo.fr>
>>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>>>
>>>> anybody from this impressive list ?:
>>>>
>>>> https://www.andrisoft.com/company/customers
>>>>
>>>> -- Marcel
>>>>
>>>>
>>>>
>>> Anybody here compared Wanguard's performance with the DDoS vendors in the
>>> market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?
>>>
>>> Another question, have anybody from the reviewers tested the false
>>> positives of the box, or experienced any false positive incidents?
>>>
>>> Thanks,
>>>
>>> Ramy
>>
>>

From mhuff at ox.com  Sat Aug 15 13:40:54 2015
From: mhuff at ox.com (Matthew Huff)
Date: Sat, 15 Aug 2015 13:40:54 +0000
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas 
In-Reply-To: <9E011DD002D07D44997466761AE668099F3468C9@SRV-EMPIRE183V.empiredistrict.com>
References: <9E011DD002D07D44997466761AE668099F3468C9@SRV-EMPIRE183V.empiredistrict.com>
Message-ID: <3579403fd04b4a5bbcbc6c232afae0ba@pur-vm-exch13n1.ox.com>

It's only partially about net neutrality. Cogent provides cheap bandwidth for content providers, and sends a lot of traffic to eyeball networks. In the past, peering partners expected symmetrical load sharing. Cogent feels that eyeball networks should be happy to carry their traffic since the customers want their services, the eyeball networks want Cogent to pay them extra. When there is congestion, neither side wants to upgrade their peeing until this is resolved, so they haven't. This has been going on for at least 5 years, and happens all over the cogent peering map.

Depending on what protocol you are using, it can be an issue or not. Our end users on eyeball networks had difficulty maintaining VPN connections. We had to drop our Cogent upstream and work with our remaining upstream provides to traffic engineer around Cogent. YMMV.



----
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 Jordan Hamilton
Sent: Friday, August 14, 2015 5:31 PM
To: nanog at nanog.org
Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 

I have several customers that are having packet loss issues, the packet loss appears to be associated with a Cogent router interface of 38.104.86.222.  My upstream provider is telling me that the packet loss is being caused by a net neutrality peering dispute between CenturyTel/Quest and Cogent in Dallas.  I did some quick googling to see if I could come up with any articles or something like that I could provide to my customers and did not see anything.  Anyone know any details?

Thanks

Jordan Hamilton
Senior Telecommunications Engineer

Empire District Electric Co.
720 Schifferdecker
PO Box 127
Joplin, MO 64802

Ph:  417-625-4223
Cell:  417-388-3351


--
Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.  Check your e-mail security settings to determine how attachments are handled.

--
This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100.
Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited.

From list at satchell.net  Sat Aug 15 13:53:22 2015
From: list at satchell.net (Stephen Satchell)
Date: Sat, 15 Aug 2015 06:53:22 -0700
Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent
 in Dallas
In-Reply-To: <3579403fd04b4a5bbcbc6c232afae0ba@pur-vm-exch13n1.ox.com>
References: <9E011DD002D07D44997466761AE668099F3468C9@SRV-EMPIRE183V.empiredistrict.com>
 <3579403fd04b4a5bbcbc6c232afae0ba@pur-vm-exch13n1.ox.com>
Message-ID: <55CF4452.8080100@satchell.net>

On 08/15/2015 06:40 AM, Matthew Huff wrote:
> neither side wants to upgrade their peeing

Oh, the irony of this typo of "peering"...

From owen at delong.com  Sat Aug 15 16:44:57 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Aug 2015 09:44:57 -0700
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas 
In-Reply-To: <3579403fd04b4a5bbcbc6c232afae0ba@pur-vm-exch13n1.ox.com>
References: <9E011DD002D07D44997466761AE668099F3468C9@SRV-EMPIRE183V.empiredistrict.com>
 <3579403fd04b4a5bbcbc6c232afae0ba@pur-vm-exch13n1.ox.com>
Message-ID: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>

This issue isn?t limited to Cogent.

There is this bizarre belief by the larger eyeball networks (and CC, VZ, and TW are the worst offenders, pretty much in that order) that they are entitled to be paid by both the content provider _AND_ the eyeball user for carrying bits between the two.

In a healthy market, the eyeball providers would face competition and the content providers would simply ignore these demands and the eyeballs would buy from other eyeball providers.

Unfortunately, especially in the US, we don?t have a healthy market. In the best of circumstances, we have oligopolies and in the worst places, we have effective (or even actual) monopolies.

For example, in the area where I live, the claim you will hear is that there is competition. With my usage patterns, that?s a choice  between Comcast (up to 30/7 $100/mo), AT&T DSL (1.5M/384k $40/mo+) and wireless (Up to 30/15 $500+/month).

I?m not in some rural backwater or even some second-tier metro. I?m within 10 miles of the former MAE West and also within 10 miles of Equinix SV1 (11 Great Oaks). There?s major fiber bundles within 2 miles of my house. I?m near US101 and Capitol Expressway in San Jose.

The reason that things are this way, IMHO, is because we have allowed ?facilities based carriers? to leverage the monopoly on physical infrastructure into a monopoly for services over that infrastructure.

The most viable solution, IMHO, is to require a separation between physical infrastructure providers and those that provide services over that infrastructure. Breaking the tight coupling between the two and requiring physical infrastructure providers to lease facilities to operators on an equal footing for all operators will reduce the barriers to competition in the operator space. It will also make limited competition in the facilities space possible, though unlikely.

This model exists to some extent in a few areas that have municipal residential fiber services, and in most of those localities, it is working well.

That?s one of the reasons that the incumbent facilities based carriers have lobbied so hard to get laws in states where a city has done this that prevent other cities from following suit.

Fortunately, one of the big gains in recent FCC rulings is that these laws are likely to be rendered null and void.

Unfortunately, there is so much vested interest in the status quo that achieving this sort of separation is unlikely without a really strong grass roots movement. Sadly, the average sound-bite oriented citizen doesn?t know (or want to learn) enough to facilitate such a grass-roots movement, so if we want to build such a future, we have a long slog of public education and recruitment ahead of us.

In the mean time, we?ll get to continue to watch companies like CC, VZ, TW screw over their customers and the content providers their customers want to reach for the sake of extorting extra money from both sides of the transaction.

Owen

> On Aug 15, 2015, at 06:40 , Matthew Huff <mhuff at ox.com> wrote:
> 
> It's only partially about net neutrality. Cogent provides cheap bandwidth for content providers, and sends a lot of traffic to eyeball networks. In the past, peering partners expected symmetrical load sharing. Cogent feels that eyeball networks should be happy to carry their traffic since the customers want their services, the eyeball networks want Cogent to pay them extra. When there is congestion, neither side wants to upgrade their peeing until this is resolved, so they haven't. This has been going on for at least 5 years, and happens all over the cogent peering map.
> 
> Depending on what protocol you are using, it can be an issue or not. Our end users on eyeball networks had difficulty maintaining VPN connections. We had to drop our Cogent upstream and work with our remaining upstream provides to traffic engineer around Cogent. YMMV.
> 
> 
> 
> ----
> 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 Jordan Hamilton
> Sent: Friday, August 14, 2015 5:31 PM
> To: nanog at nanog.org
> Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 
> 
> I have several customers that are having packet loss issues, the packet loss appears to be associated with a Cogent router interface of 38.104.86.222.  My upstream provider is telling me that the packet loss is being caused by a net neutrality peering dispute between CenturyTel/Quest and Cogent in Dallas.  I did some quick googling to see if I could come up with any articles or something like that I could provide to my customers and did not see anything.  Anyone know any details?
> 
> Thanks
> 
> Jordan Hamilton
> Senior Telecommunications Engineer
> 
> Empire District Electric Co.
> 720 Schifferdecker
> PO Box 127
> Joplin, MO 64802
> 
> Ph:  417-625-4223
> Cell:  417-388-3351
> 
> 
> --
> Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.  Check your e-mail security settings to determine how attachments are handled.
> 
> --
> This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100.
> Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited.


From glen.kent at gmail.com  Sat Aug 15 16:47:31 2015
From: glen.kent at gmail.com (Glen Kent)
Date: Sat, 15 Aug 2015 22:17:31 +0530
Subject: Drops in Core
Message-ID: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>

Hi,

Is it fair to say that most traffic drops happen in the access layers, or
the first and the last miles, and the % of packet drops in the core are
minimal? So, if the packet has made it past the first mile and has
"entered" the core then chances are high that the packet will safely get
across till the exit in the core. Sure once it gets off the core, then all
bets are off on whether it will get dropped or not. However, the key point
is that the core usually does not drop too many packets - the probability
of drops are highest in the access side.

Is this correct?

Glen

From nanog at ics-il.net  Sat Aug 15 16:54:18 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 15 Aug 2015 11:54:18 -0500 (CDT)
Subject: Drops in Core
In-Reply-To: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
Message-ID: <1658205655.8764.1439657692160.JavaMail.mhammett@ThunderFuck>

I'd guess first\last\peering. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Glen Kent" <glen.kent at gmail.com> 
To: nanog at nanog.org 
Sent: Saturday, August 15, 2015 11:47:31 AM 
Subject: Drops in Core 

Hi, 

Is it fair to say that most traffic drops happen in the access layers, or 
the first and the last miles, and the % of packet drops in the core are 
minimal? So, if the packet has made it past the first mile and has 
"entered" the core then chances are high that the packet will safely get 
across till the exit in the core. Sure once it gets off the core, then all 
bets are off on whether it will get dropped or not. However, the key point 
is that the core usually does not drop too many packets - the probability 
of drops are highest in the access side. 

Is this correct? 

Glen 


From nanog at ics-il.net  Sat Aug 15 16:59:53 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 15 Aug 2015 11:59:53 -0500 (CDT)
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
Message-ID: <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>

Arrogance is the only reason I can think of why the incumbents think that way. I'd be surprised if any competitive providers (regardless of their market dominance) would expect free peering. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Owen DeLong" <owen at delong.com> 
To: "Matthew Huff" <mhuff at ox.com> 
Cc: nanog at nanog.org 
Sent: Saturday, August 15, 2015 11:44:57 AM 
Subject: Re: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 

This issue isn?t limited to Cogent. 

There is this bizarre belief by the larger eyeball networks (and CC, VZ, and TW are the worst offenders, pretty much in that order) that they are entitled to be paid by both the content provider _AND_ the eyeball user for carrying bits between the two. 

In a healthy market, the eyeball providers would face competition and the content providers would simply ignore these demands and the eyeballs would buy from other eyeball providers. 

Unfortunately, especially in the US, we don?t have a healthy market. In the best of circumstances, we have oligopolies and in the worst places, we have effective (or even actual) monopolies. 

For example, in the area where I live, the claim you will hear is that there is competition. With my usage patterns, that?s a choice between Comcast (up to 30/7 $100/mo), AT&T DSL (1.5M/384k $40/mo+) and wireless (Up to 30/15 $500+/month). 

I?m not in some rural backwater or even some second-tier metro. I?m within 10 miles of the former MAE West and also within 10 miles of Equinix SV1 (11 Great Oaks). There?s major fiber bundles within 2 miles of my house. I?m near US101 and Capitol Expressway in San Jose. 

The reason that things are this way, IMHO, is because we have allowed ?facilities based carriers? to leverage the monopoly on physical infrastructure into a monopoly for services over that infrastructure. 

The most viable solution, IMHO, is to require a separation between physical infrastructure providers and those that provide services over that infrastructure. Breaking the tight coupling between the two and requiring physical infrastructure providers to lease facilities to operators on an equal footing for all operators will reduce the barriers to competition in the operator space. It will also make limited competition in the facilities space possible, though unlikely. 

This model exists to some extent in a few areas that have municipal residential fiber services, and in most of those localities, it is working well. 

That?s one of the reasons that the incumbent facilities based carriers have lobbied so hard to get laws in states where a city has done this that prevent other cities from following suit. 

Fortunately, one of the big gains in recent FCC rulings is that these laws are likely to be rendered null and void. 

Unfortunately, there is so much vested interest in the status quo that achieving this sort of separation is unlikely without a really strong grass roots movement. Sadly, the average sound-bite oriented citizen doesn?t know (or want to learn) enough to facilitate such a grass-roots movement, so if we want to build such a future, we have a long slog of public education and recruitment ahead of us. 

In the mean time, we?ll get to continue to watch companies like CC, VZ, TW screw over their customers and the content providers their customers want to reach for the sake of extorting extra money from both sides of the transaction. 

Owen 

> On Aug 15, 2015, at 06:40 , Matthew Huff <mhuff at ox.com> wrote: 
> 
> It's only partially about net neutrality. Cogent provides cheap bandwidth for content providers, and sends a lot of traffic to eyeball networks. In the past, peering partners expected symmetrical load sharing. Cogent feels that eyeball networks should be happy to carry their traffic since the customers want their services, the eyeball networks want Cogent to pay them extra. When there is congestion, neither side wants to upgrade their peeing until this is resolved, so they haven't. This has been going on for at least 5 years, and happens all over the cogent peering map. 
> 
> Depending on what protocol you are using, it can be an issue or not. Our end users on eyeball networks had difficulty maintaining VPN connections. We had to drop our Cogent upstream and work with our remaining upstream provides to traffic engineer around Cogent. YMMV. 
> 
> 
> 
> ---- 
> 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 Jordan Hamilton 
> Sent: Friday, August 14, 2015 5:31 PM 
> To: nanog at nanog.org 
> Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 
> 
> I have several customers that are having packet loss issues, the packet loss appears to be associated with a Cogent router interface of 38.104.86.222. My upstream provider is telling me that the packet loss is being caused by a net neutrality peering dispute between CenturyTel/Quest and Cogent in Dallas. I did some quick googling to see if I could come up with any articles or something like that I could provide to my customers and did not see anything. Anyone know any details? 
> 
> Thanks 
> 
> Jordan Hamilton 
> Senior Telecommunications Engineer 
> 
> Empire District Electric Co. 
> 720 Schifferdecker 
> PO Box 127 
> Joplin, MO 64802 
> 
> Ph: 417-625-4223 
> Cell: 417-388-3351 
> 
> 
> -- 
> Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled. 
> 
> -- 
> This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100. 
> Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. 



From bill at herrin.us  Sat Aug 15 17:03:02 2015
From: bill at herrin.us (William Herrin)
Date: Sat, 15 Aug 2015 13:03:02 -0400
Subject: Drops in Core
In-Reply-To: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
Message-ID: <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>

On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent at gmail.com> wrote:
> Is it fair to say that most traffic drops happen in the access layers, or
> the first and the last miles, and the % of packet drops in the core are
> minimal? So, if the packet has made it past the first mile and has
> "entered" the core then chances are high that the packet will safely get
> across till the exit in the core.

Hi Glen,

I would expect congestion loss at enough peering points (center of the
core) to put it in the same league as noisy cable at the edge.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From glen.kent at gmail.com  Sat Aug 15 17:07:09 2015
From: glen.kent at gmail.com (Glen Kent)
Date: Sat, 15 Aug 2015 22:37:09 +0530
Subject: Drops in Core
In-Reply-To: <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
Message-ID: <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>

Hi Bill,

Just making sure that i get your point:

Youre saying that the probability of packet drop at peering points would
roughly match that at the edge. Is it? I thought that most core switches
have minimal buffering and really do cut-through forwarding. The idea is
that the traffic that they receive is already shaped by the upstream
routers.

Glen



On Sat, Aug 15, 2015 at 10:33 PM, William Herrin <bill at herrin.us> wrote:

> On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent at gmail.com> wrote:
> > Is it fair to say that most traffic drops happen in the access layers, or
> > the first and the last miles, and the % of packet drops in the core are
> > minimal? So, if the packet has made it past the first mile and has
> > "entered" the core then chances are high that the packet will safely get
> > across till the exit in the core.
>
> Hi Glen,
>
> I would expect congestion loss at enough peering points (center of the
> core) to put it in the same league as noisy cable at the edge.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>

From hannigan at gmail.com  Sat Aug 15 17:13:36 2015
From: hannigan at gmail.com (Martin Hannigan)
Date: Sat, 15 Aug 2015 13:13:36 -0400
Subject: Data Center operations mail list?
In-Reply-To: <20150811192715.GB2558@dilbert.slimey.org>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
Message-ID: <CAMDXq5M9wvC15QkuMyzwx7c+cMcEqF2Y1FTT1dujhn3muVEfWA@mail.gmail.com>

On Tue, Aug 11, 2015 at 3:27 PM, Simon Lockhart <simon at slimey.org> wrote:

> On Tue Aug 11, 2015 at 01:35:28pm -0400, Jay Ashworth wrote:
> > Absolutely feel free to use it; I haven't seen a single message on it
> in...
> > well, it was 3 years ago I was in datacenters regularly, so I'm goin with
> > "3 years".  :-)
>
> There's a message there now... :)
>
> Rather than fragmenting further, I'd suggest building up demand first on
> existing infrastructure. If it gets to the size of NANOG and needing a
> support organisation around it, then it can split off then...
>
>
>

A few of us have been operating and supporting a data center track at the
last 4 or 5 NANOG meetings. The sessions are well attended and the topics
are getting more interesting e.g. real estate, energy management and
interconnection focused.

There is reasonable demand for a forum.  It might need a little marketing
to get a list with traction going.

Best,

-M<

From bill at herrin.us  Sat Aug 15 17:16:51 2015
From: bill at herrin.us (William Herrin)
Date: Sat, 15 Aug 2015 13:16:51 -0400
Subject: Drops in Core
In-Reply-To: <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
Message-ID: <CAP-guGU1Z15cX6Nk9xezB0N6yOoiOXsbw8q_5F9KSotRkx3Evw@mail.gmail.com>

On Sat, Aug 15, 2015 at 1:07 PM, Glen Kent <glen.kent at gmail.com> wrote:
> Youre saying that the probability of packet drop at peering points would
> roughly match that at the edge. Is it? I thought that most core switches
> have minimal buffering and really do cut-through forwarding. The idea is
> that the traffic that they receive is already shaped by the upstream
> routers.

Hi Glen,

It a capacity question. Several core networks [cough Verizon cough]
intentionally under-provision the "settlement-free" peering links to
other core networks. You can't cut-through when the destination
interface already has a queue of packets waiting to be sent.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From owen at delong.com  Sat Aug 15 17:18:04 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Aug 2015 10:18:04 -0700
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
References: <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
Message-ID: <0A976B46-FF45-4E54-89D1-166DF0AD3491@delong.com>

Your reply implies that your understanding does not match my intended meaning.

(IOW, Perhaps you did not receive what I intended to transmit)

I?m saying that the incumbents in an act of unreasonable greed are demanding money for peering from providers with a lot of content providers while also collecting money from their direct customers for the sake of delivering that same content.

It would be like me standing between you and a hotdog stand and demanding that you give me 1.5x the price of the hotdog and then demanding that the hotdog stand sell me the hotdog to give to you for 0.5x the listed price.

In the more functional physical world, you simply walk around me and buy the hotdog for 1x the listed price and the only one who loses is the guy standing in the middle.

In the case of the incumbent facilities based carriers, they?ve managed to build a wall in front of the hot dog stand and a wall in front of you such that your view is limited to the window that they have to open and so is the hot dog vendor. Thus, you have no choice but to give them the extra 50% for the hot dog and the hot dog vendor has no choice but to give them half of the listed price as a ?delivery charge?.

Admittedly, the fractions are not as I described, but the basic principle is exactly as I have described it.

Owen

> On Aug 15, 2015, at 09:59 , Mike Hammett <nanog at ics-il.net> wrote:
> 
> Arrogance is the only reason I can think of why the incumbents think that way. I'd be surprised if any competitive providers (regardless of their market dominance) would expect free peering. 
> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> ----- Original Message -----
> 
> From: "Owen DeLong" <owen at delong.com> 
> To: "Matthew Huff" <mhuff at ox.com> 
> Cc: nanog at nanog.org 
> Sent: Saturday, August 15, 2015 11:44:57 AM 
> Subject: Re: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 
> 
> This issue isn?t limited to Cogent. 
> 
> There is this bizarre belief by the larger eyeball networks (and CC, VZ, and TW are the worst offenders, pretty much in that order) that they are entitled to be paid by both the content provider _AND_ the eyeball user for carrying bits between the two. 
> 
> In a healthy market, the eyeball providers would face competition and the content providers would simply ignore these demands and the eyeballs would buy from other eyeball providers. 
> 
> Unfortunately, especially in the US, we don?t have a healthy market. In the best of circumstances, we have oligopolies and in the worst places, we have effective (or even actual) monopolies. 
> 
> For example, in the area where I live, the claim you will hear is that there is competition. With my usage patterns, that?s a choice between Comcast (up to 30/7 $100/mo), AT&T DSL (1.5M/384k $40/mo+) and wireless (Up to 30/15 $500+/month). 
> 
> I?m not in some rural backwater or even some second-tier metro. I?m within 10 miles of the former MAE West and also within 10 miles of Equinix SV1 (11 Great Oaks). There?s major fiber bundles within 2 miles of my house. I?m near US101 and Capitol Expressway in San Jose. 
> 
> The reason that things are this way, IMHO, is because we have allowed ?facilities based carriers? to leverage the monopoly on physical infrastructure into a monopoly for services over that infrastructure. 
> 
> The most viable solution, IMHO, is to require a separation between physical infrastructure providers and those that provide services over that infrastructure. Breaking the tight coupling between the two and requiring physical infrastructure providers to lease facilities to operators on an equal footing for all operators will reduce the barriers to competition in the operator space. It will also make limited competition in the facilities space possible, though unlikely. 
> 
> This model exists to some extent in a few areas that have municipal residential fiber services, and in most of those localities, it is working well. 
> 
> That?s one of the reasons that the incumbent facilities based carriers have lobbied so hard to get laws in states where a city has done this that prevent other cities from following suit. 
> 
> Fortunately, one of the big gains in recent FCC rulings is that these laws are likely to be rendered null and void. 
> 
> Unfortunately, there is so much vested interest in the status quo that achieving this sort of separation is unlikely without a really strong grass roots movement. Sadly, the average sound-bite oriented citizen doesn?t know (or want to learn) enough to facilitate such a grass-roots movement, so if we want to build such a future, we have a long slog of public education and recruitment ahead of us. 
> 
> In the mean time, we?ll get to continue to watch companies like CC, VZ, TW screw over their customers and the content providers their customers want to reach for the sake of extorting extra money from both sides of the transaction. 
> 
> Owen 
> 
>> On Aug 15, 2015, at 06:40 , Matthew Huff <mhuff at ox.com> wrote: 
>> 
>> It's only partially about net neutrality. Cogent provides cheap bandwidth for content providers, and sends a lot of traffic to eyeball networks. In the past, peering partners expected symmetrical load sharing. Cogent feels that eyeball networks should be happy to carry their traffic since the customers want their services, the eyeball networks want Cogent to pay them extra. When there is congestion, neither side wants to upgrade their peeing until this is resolved, so they haven't. This has been going on for at least 5 years, and happens all over the cogent peering map. 
>> 
>> Depending on what protocol you are using, it can be an issue or not. Our end users on eyeball networks had difficulty maintaining VPN connections. We had to drop our Cogent upstream and work with our remaining upstream provides to traffic engineer around Cogent. YMMV. 
>> 
>> 
>> 
>> ---- 
>> 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 Jordan Hamilton 
>> Sent: Friday, August 14, 2015 5:31 PM 
>> To: nanog at nanog.org 
>> Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 
>> 
>> I have several customers that are having packet loss issues, the packet loss appears to be associated with a Cogent router interface of 38.104.86.222. My upstream provider is telling me that the packet loss is being caused by a net neutrality peering dispute between CenturyTel/Quest and Cogent in Dallas. I did some quick googling to see if I could come up with any articles or something like that I could provide to my customers and did not see anything. Anyone know any details? 
>> 
>> Thanks 
>> 
>> Jordan Hamilton 
>> Senior Telecommunications Engineer 
>> 
>> Empire District Electric Co. 
>> 720 Schifferdecker 
>> PO Box 127 
>> Joplin, MO 64802 
>> 
>> Ph: 417-625-4223 
>> Cell: 417-388-3351 
>> 
>> 
>> -- 
>> Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled. 
>> 
>> -- 
>> This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100. 
>> Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. 
> 
> 


From owen at delong.com  Sat Aug 15 17:21:34 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Aug 2015 10:21:34 -0700
Subject: Drops in Core
In-Reply-To: <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
Message-ID: <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>

I would say that the probability of a packet drop at any particular peering
point is less than the probability at one of the two edges.

However, given that most packets are likely to traverse multiple peering
points between the two edges, the probability of a packet drop along
the way at one of the several peering points overall is roughly equal
to the probability of a drop at one of the two edges.

YMMV.

Owen

> On Aug 15, 2015, at 10:07 , Glen Kent <glen.kent at gmail.com> wrote:
> 
> Hi Bill,
> 
> Just making sure that i get your point:
> 
> Youre saying that the probability of packet drop at peering points would
> roughly match that at the edge. Is it? I thought that most core switches
> have minimal buffering and really do cut-through forwarding. The idea is
> that the traffic that they receive is already shaped by the upstream
> routers.
> 
> Glen
> 
> 
> 
> On Sat, Aug 15, 2015 at 10:33 PM, William Herrin <bill at herrin.us> wrote:
> 
>> On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent at gmail.com> wrote:
>>> Is it fair to say that most traffic drops happen in the access layers, or
>>> the first and the last miles, and the % of packet drops in the core are
>>> minimal? So, if the packet has made it past the first mile and has
>>> "entered" the core then chances are high that the packet will safely get
>>> across till the exit in the core.
>> 
>> Hi Glen,
>> 
>> I would expect congestion loss at enough peering points (center of the
>> core) to put it in the same league as noisy cable at the edge.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> 
>> --
>> William Herrin ................ herrin at dirtside.com  bill at herrin.us
>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>> 


From nanog at ics-il.net  Sat Aug 15 17:22:13 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sat, 15 Aug 2015 12:22:13 -0500 (CDT)
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <0A976B46-FF45-4E54-89D1-166DF0AD3491@delong.com>
Message-ID: <1099028084.8801.1439659365749.JavaMail.mhammett@ThunderFuck>

I think we're on the same side, just saying it differently substituting greed for arrogance. 

Additionally, the last mile providers are acting no differently than a carrier would, getting paid on both sides... only carriers are typically balanced ratios where as last mile\first mile are not. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Owen DeLong" <owen at delong.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: nanog at nanog.org 
Sent: Saturday, August 15, 2015 12:18:04 PM 
Subject: Re: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 

Your reply implies that your understanding does not match my intended meaning. 

(IOW, Perhaps you did not receive what I intended to transmit) 

I?m saying that the incumbents in an act of unreasonable greed are demanding money for peering from providers with a lot of content providers while also collecting money from their direct customers for the sake of delivering that same content. 

It would be like me standing between you and a hotdog stand and demanding that you give me 1.5x the price of the hotdog and then demanding that the hotdog stand sell me the hotdog to give to you for 0.5x the listed price. 

In the more functional physical world, you simply walk around me and buy the hotdog for 1x the listed price and the only one who loses is the guy standing in the middle. 

In the case of the incumbent facilities based carriers, they?ve managed to build a wall in front of the hot dog stand and a wall in front of you such that your view is limited to the window that they have to open and so is the hot dog vendor. Thus, you have no choice but to give them the extra 50% for the hot dog and the hot dog vendor has no choice but to give them half of the listed price as a ?delivery charge?. 

Admittedly, the fractions are not as I described, but the basic principle is exactly as I have described it. 

Owen 

> On Aug 15, 2015, at 09:59 , Mike Hammett <nanog at ics-il.net> wrote: 
> 
> Arrogance is the only reason I can think of why the incumbents think that way. I'd be surprised if any competitive providers (regardless of their market dominance) would expect free peering. 
> 
> 
> 
> 
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> ----- Original Message ----- 
> 
> From: "Owen DeLong" <owen at delong.com> 
> To: "Matthew Huff" <mhuff at ox.com> 
> Cc: nanog at nanog.org 
> Sent: Saturday, August 15, 2015 11:44:57 AM 
> Subject: Re: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 
> 
> This issue isn?t limited to Cogent. 
> 
> There is this bizarre belief by the larger eyeball networks (and CC, VZ, and TW are the worst offenders, pretty much in that order) that they are entitled to be paid by both the content provider _AND_ the eyeball user for carrying bits between the two. 
> 
> In a healthy market, the eyeball providers would face competition and the content providers would simply ignore these demands and the eyeballs would buy from other eyeball providers. 
> 
> Unfortunately, especially in the US, we don?t have a healthy market. In the best of circumstances, we have oligopolies and in the worst places, we have effective (or even actual) monopolies. 
> 
> For example, in the area where I live, the claim you will hear is that there is competition. With my usage patterns, that?s a choice between Comcast (up to 30/7 $100/mo), AT&T DSL (1.5M/384k $40/mo+) and wireless (Up to 30/15 $500+/month). 
> 
> I?m not in some rural backwater or even some second-tier metro. I?m within 10 miles of the former MAE West and also within 10 miles of Equinix SV1 (11 Great Oaks). There?s major fiber bundles within 2 miles of my house. I?m near US101 and Capitol Expressway in San Jose. 
> 
> The reason that things are this way, IMHO, is because we have allowed ?facilities based carriers? to leverage the monopoly on physical infrastructure into a monopoly for services over that infrastructure. 
> 
> The most viable solution, IMHO, is to require a separation between physical infrastructure providers and those that provide services over that infrastructure. Breaking the tight coupling between the two and requiring physical infrastructure providers to lease facilities to operators on an equal footing for all operators will reduce the barriers to competition in the operator space. It will also make limited competition in the facilities space possible, though unlikely. 
> 
> This model exists to some extent in a few areas that have municipal residential fiber services, and in most of those localities, it is working well. 
> 
> That?s one of the reasons that the incumbent facilities based carriers have lobbied so hard to get laws in states where a city has done this that prevent other cities from following suit. 
> 
> Fortunately, one of the big gains in recent FCC rulings is that these laws are likely to be rendered null and void. 
> 
> Unfortunately, there is so much vested interest in the status quo that achieving this sort of separation is unlikely without a really strong grass roots movement. Sadly, the average sound-bite oriented citizen doesn?t know (or want to learn) enough to facilitate such a grass-roots movement, so if we want to build such a future, we have a long slog of public education and recruitment ahead of us. 
> 
> In the mean time, we?ll get to continue to watch companies like CC, VZ, TW screw over their customers and the content providers their customers want to reach for the sake of extorting extra money from both sides of the transaction. 
> 
> Owen 
> 
>> On Aug 15, 2015, at 06:40 , Matthew Huff <mhuff at ox.com> wrote: 
>> 
>> It's only partially about net neutrality. Cogent provides cheap bandwidth for content providers, and sends a lot of traffic to eyeball networks. In the past, peering partners expected symmetrical load sharing. Cogent feels that eyeball networks should be happy to carry their traffic since the customers want their services, the eyeball networks want Cogent to pay them extra. When there is congestion, neither side wants to upgrade their peeing until this is resolved, so they haven't. This has been going on for at least 5 years, and happens all over the cogent peering map. 
>> 
>> Depending on what protocol you are using, it can be an issue or not. Our end users on eyeball networks had difficulty maintaining VPN connections. We had to drop our Cogent upstream and work with our remaining upstream provides to traffic engineer around Cogent. YMMV. 
>> 
>> 
>> 
>> ---- 
>> 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 Jordan Hamilton 
>> Sent: Friday, August 14, 2015 5:31 PM 
>> To: nanog at nanog.org 
>> Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas 
>> 
>> I have several customers that are having packet loss issues, the packet loss appears to be associated with a Cogent router interface of 38.104.86.222. My upstream provider is telling me that the packet loss is being caused by a net neutrality peering dispute between CenturyTel/Quest and Cogent in Dallas. I did some quick googling to see if I could come up with any articles or something like that I could provide to my customers and did not see anything. Anyone know any details? 
>> 
>> Thanks 
>> 
>> Jordan Hamilton 
>> Senior Telecommunications Engineer 
>> 
>> Empire District Electric Co. 
>> 720 Schifferdecker 
>> PO Box 127 
>> Joplin, MO 64802 
>> 
>> Ph: 417-625-4223 
>> Cell: 417-388-3351 
>> 
>> 
>> -- 
>> Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled. 
>> 
>> -- 
>> This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100. 
>> Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. 
> 
> 



From rafael at gav.ufsc.br  Sat Aug 15 17:26:15 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Sat, 15 Aug 2015 12:26:15 -0500
Subject: Drops in Core
In-Reply-To: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
Message-ID: <CAJB2g-EvmvAaCbFfObhTU7jy8QL0t8SA3xovKgToEHE=5Oq=Og@mail.gmail.com>

Hi Glen,

If you first list the causes of a dropped packet, then you can figure out
how likely they are at different points in time (first\last\peer\etc) by
making some assumptions.

Here's an **example**:

*Cause | Location | Likelihood*
Congestion | Last mile | Low
Congestion | First mile | Low
Congestion | Peering | Medium
Layer 1 | First mile | Low
Layer 1 | Core | Low
Layer 1 | Last mile | High

You can even go as far as drawing a cause and effect diagram for each
location. Then you can collect real world data and fine tune your
assumptions.


Rafael


On Sat, Aug 15, 2015 at 11:47 AM, Glen Kent <glen.kent at gmail.com> wrote:

> Hi,
>
> Is it fair to say that most traffic drops happen in the access layers, or
> the first and the last miles, and the % of packet drops in the core are
> minimal? So, if the packet has made it past the first mile and has
> "entered" the core then chances are high that the packet will safely get
> across till the exit in the core. Sure once it gets off the core, then all
> bets are off on whether it will get dropped or not. However, the key point
> is that the core usually does not drop too many packets - the probability
> of drops are highest in the access side.
>
> Is this correct?
>
> Glen
>

From bill at herrin.us  Sat Aug 15 17:28:00 2015
From: bill at herrin.us (William Herrin)
Date: Sat, 15 Aug 2015 13:28:00 -0400
Subject: Drops in Core
In-Reply-To: <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
Message-ID: <CAP-guGUMFjyk0mGtFjkydzziTKTzj+DVKQuZEptgbgAsD8PWHQ@mail.gmail.com>

On Sat, Aug 15, 2015 at 1:21 PM, Owen DeLong <owen at delong.com> wrote:
> I would say that the probability of a packet drop at any particular peering
> point is less than the probability at one of the two edges.
>
> However, given that most packets are likely to traverse multiple peering
> points between the two edges, the probability of a packet drop along
> the way at one of the several peering points overall is roughly equal
> to the probability of a drop at one of the two edges.

Hi Owen,

Generally speaking there are zero or one settlement free peering
points in the active path between any two edges. Not always, but close
enough to it to discount the exceptions.

Speaking for my own experience, I almost never see loss on my Verizon
FiOS edge but see loss at the various Verizon borders with other
networks -all the time-.  They keep pitching me on upgrading to 75/75
but that isn't the upgrade I need.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From glen.kent at gmail.com  Sat Aug 15 17:31:56 2015
From: glen.kent at gmail.com (Glen Kent)
Date: Sat, 15 Aug 2015 23:01:56 +0530
Subject: Drops in Core
In-Reply-To: <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
Message-ID: <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>

Is there a paper or a presentation that discusses the drops in the core?

If i were to break the total path into three legs -- the first, middle and
the last, then are you saying that the probability of packet loss is
perhaps 1/3 in each leg (because the packet passes through different IXes).
That sounds too aggressive for the middle mile. Dont you think so?

On Sat, Aug 15, 2015 at 10:51 PM, Owen DeLong <owen at delong.com> wrote:

> I would say that the probability of a packet drop at any particular peering
> point is less than the probability at one of the two edges.
>
> However, given that most packets are likely to traverse multiple peering
> points between the two edges, the probability of a packet drop along
> the way at one of the several peering points overall is roughly equal
> to the probability of a drop at one of the two edges.
>
> YMMV.
>
> Owen
>
> > On Aug 15, 2015, at 10:07 , Glen Kent <glen.kent at gmail.com> wrote:
> >
> > Hi Bill,
> >
> > Just making sure that i get your point:
> >
> > Youre saying that the probability of packet drop at peering points would
> > roughly match that at the edge. Is it? I thought that most core switches
> > have minimal buffering and really do cut-through forwarding. The idea is
> > that the traffic that they receive is already shaped by the upstream
> > routers.
> >
> > Glen
> >
> >
> >
> > On Sat, Aug 15, 2015 at 10:33 PM, William Herrin <bill at herrin.us> wrote:
> >
> >> On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent <glen.kent at gmail.com>
> wrote:
> >>> Is it fair to say that most traffic drops happen in the access layers,
> or
> >>> the first and the last miles, and the % of packet drops in the core are
> >>> minimal? So, if the packet has made it past the first mile and has
> >>> "entered" the core then chances are high that the packet will safely
> get
> >>> across till the exit in the core.
> >>
> >> Hi Glen,
> >>
> >> I would expect congestion loss at enough peering points (center of the
> >> core) to put it in the same league as noisy cable at the edge.
> >>
> >> Regards,
> >> Bill Herrin
> >>
> >>
> >>
> >> --
> >> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> >> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> >>
>
>

From deleskie at gmail.com  Sat Aug 15 17:32:38 2015
From: deleskie at gmail.com (jim deleskie)
Date: Sat, 15 Aug 2015 14:32:38 -0300
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
References: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>

In my 20+ yrs now of playing this game, "everyone" has had a turn thinking
their content/eyeballs are special and should get free "peering".

On Sat, Aug 15, 2015 at 1:59 PM, Mike Hammett <nanog at ics-il.net> wrote:

> Arrogance is the only reason I can think of why the incumbents think that
> way. I'd be surprised if any competitive providers (regardless of their
> market dominance) would expect free peering.
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
> ----- Original Message -----
>
> From: "Owen DeLong" <owen at delong.com>
> To: "Matthew Huff" <mhuff at ox.com>
> Cc: nanog at nanog.org
> Sent: Saturday, August 15, 2015 11:44:57 AM
> Subject: Re: net neutrality peering dispute between CenturyTel/Qwest and
> Cogent in Dallas
>
> This issue isn?t limited to Cogent.
>
> There is this bizarre belief by the larger eyeball networks (and CC, VZ,
> and TW are the worst offenders, pretty much in that order) that they are
> entitled to be paid by both the content provider _AND_ the eyeball user for
> carrying bits between the two.
>
> In a healthy market, the eyeball providers would face competition and the
> content providers would simply ignore these demands and the eyeballs would
> buy from other eyeball providers.
>
> Unfortunately, especially in the US, we don?t have a healthy market. In
> the best of circumstances, we have oligopolies and in the worst places, we
> have effective (or even actual) monopolies.
>
> For example, in the area where I live, the claim you will hear is that
> there is competition. With my usage patterns, that?s a choice between
> Comcast (up to 30/7 $100/mo), AT&T DSL (1.5M/384k $40/mo+) and wireless (Up
> to 30/15 $500+/month).
>
> I?m not in some rural backwater or even some second-tier metro. I?m within
> 10 miles of the former MAE West and also within 10 miles of Equinix SV1 (11
> Great Oaks). There?s major fiber bundles within 2 miles of my house. I?m
> near US101 and Capitol Expressway in San Jose.
>
> The reason that things are this way, IMHO, is because we have allowed
> ?facilities based carriers? to leverage the monopoly on physical
> infrastructure into a monopoly for services over that infrastructure.
>
> The most viable solution, IMHO, is to require a separation between
> physical infrastructure providers and those that provide services over that
> infrastructure. Breaking the tight coupling between the two and requiring
> physical infrastructure providers to lease facilities to operators on an
> equal footing for all operators will reduce the barriers to competition in
> the operator space. It will also make limited competition in the facilities
> space possible, though unlikely.
>
> This model exists to some extent in a few areas that have municipal
> residential fiber services, and in most of those localities, it is working
> well.
>
> That?s one of the reasons that the incumbent facilities based carriers
> have lobbied so hard to get laws in states where a city has done this that
> prevent other cities from following suit.
>
> Fortunately, one of the big gains in recent FCC rulings is that these laws
> are likely to be rendered null and void.
>
> Unfortunately, there is so much vested interest in the status quo that
> achieving this sort of separation is unlikely without a really strong grass
> roots movement. Sadly, the average sound-bite oriented citizen doesn?t know
> (or want to learn) enough to facilitate such a grass-roots movement, so if
> we want to build such a future, we have a long slog of public education and
> recruitment ahead of us.
>
> In the mean time, we?ll get to continue to watch companies like CC, VZ, TW
> screw over their customers and the content providers their customers want
> to reach for the sake of extorting extra money from both sides of the
> transaction.
>
> Owen
>
> > On Aug 15, 2015, at 06:40 , Matthew Huff <mhuff at ox.com> wrote:
> >
> > It's only partially about net neutrality. Cogent provides cheap
> bandwidth for content providers, and sends a lot of traffic to eyeball
> networks. In the past, peering partners expected symmetrical load sharing.
> Cogent feels that eyeball networks should be happy to carry their traffic
> since the customers want their services, the eyeball networks want Cogent
> to pay them extra. When there is congestion, neither side wants to upgrade
> their peeing until this is resolved, so they haven't. This has been going
> on for at least 5 years, and happens all over the cogent peering map.
> >
> > Depending on what protocol you are using, it can be an issue or not. Our
> end users on eyeball networks had difficulty maintaining VPN connections.
> We had to drop our Cogent upstream and work with our remaining upstream
> provides to traffic engineer around Cogent. YMMV.
> >
> >
> >
> > ----
> > 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 Jordan
> Hamilton
> > Sent: Friday, August 14, 2015 5:31 PM
> > To: nanog at nanog.org
> > Subject: net neutrality peering dispute between CenturyTel/Qwest and
> Cogent in Dallas
> >
> > I have several customers that are having packet loss issues, the packet
> loss appears to be associated with a Cogent router interface of
> 38.104.86.222. My upstream provider is telling me that the packet loss is
> being caused by a net neutrality peering dispute between CenturyTel/Quest
> and Cogent in Dallas. I did some quick googling to see if I could come up
> with any articles or something like that I could provide to my customers
> and did not see anything. Anyone know any details?
> >
> > Thanks
> >
> > Jordan Hamilton
> > Senior Telecommunications Engineer
> >
> > Empire District Electric Co.
> > 720 Schifferdecker
> > PO Box 127
> > Joplin, MO 64802
> >
> > Ph: 417-625-4223
> > Cell: 417-388-3351
> >
> >
> > --
> > Note: To protect against computer viruses, e-mail programs may prevent
> sending or receiving certain types of file attachments. Check your e-mail
> security settings to determine how attachments are handled.
> >
> > --
> > This e-mail and any files transmitted with it are the property of THE
> EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely
> for the use of the individual or entity to whom this email is addressed. If
> you are not one of the named recipients or otherwise have reason to believe
> that you have received this message in error, please delete this message
> immediately from your computer and contact the sender by telephone at
> (417)-625-5100.
> > Any other use, retention, dissemination, forwarding, printing or copying
> of this email is strictly prohibited.
>
>
>

From rafael at gav.ufsc.br  Sat Aug 15 17:39:51 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Sat, 15 Aug 2015 12:39:51 -0500
Subject: Drops in Core
In-Reply-To: <CAPLq3UMcDsqXr_iP1QTjGYvbTuggv4wyoGFJ3p6jzEUCVs5tig@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAJB2g-EvmvAaCbFfObhTU7jy8QL0t8SA3xovKgToEHE=5Oq=Og@mail.gmail.com>
 <CAPLq3UMcDsqXr_iP1QTjGYvbTuggv4wyoGFJ3p6jzEUCVs5tig@mail.gmail.com>
Message-ID: <CAJB2g-F9ZSGjoc1yswQitS=N7ewQjUBCcDowtH1nCZhP7R5OpA@mail.gmail.com>

That was just an example, that list has to be completed on a specific
network or scenario, it changes dramatically. Imagine you were to create a
list for a DoD network instead of public peering based network, it would
change dramatically.



On Sat, Aug 15, 2015 at 12:28 PM, Glen Kent <glen.kent at gmail.com> wrote:

> Why do you say that Layer 1 issues in the last mile would be very high?
> How is it any different from the first mile?
>
> On Sat, Aug 15, 2015 at 10:56 PM, Rafael Possamai <rafael at gav.ufsc.br>
> wrote:
>
>> Hi Glen,
>>
>> If you first list the causes of a dropped packet, then you can figure out
>> how likely they are at different points in time (first\last\peer\etc) by
>> making some assumptions.
>>
>> Here's an **example**:
>>
>> *Cause | Location | Likelihood*
>> Congestion | Last mile | Low
>> Congestion | First mile | Low
>> Congestion | Peering | Medium
>> Layer 1 | First mile | Low
>> Layer 1 | Core | Low
>> Layer 1 | Last mile | High
>>
>> You can even go as far as drawing a cause and effect diagram for each
>> location. Then you can collect real world data and fine tune your
>> assumptions.
>>
>>
>> Rafael
>>
>>
>> On Sat, Aug 15, 2015 at 11:47 AM, Glen Kent <glen.kent at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Is it fair to say that most traffic drops happen in the access layers, or
>>> the first and the last miles, and the % of packet drops in the core are
>>> minimal? So, if the packet has made it past the first mile and has
>>> "entered" the core then chances are high that the packet will safely get
>>> across till the exit in the core. Sure once it gets off the core, then
>>> all
>>> bets are off on whether it will get dropped or not. However, the key
>>> point
>>> is that the core usually does not drop too many packets - the probability
>>> of drops are highest in the access side.
>>>
>>> Is this correct?
>>>
>>> Glen
>>>
>>
>>
>

From job at instituut.net  Sat Aug 15 17:41:29 2015
From: job at instituut.net (Job Snijders)
Date: Sat, 15 Aug 2015 19:41:29 +0200
Subject: Drops in Core
In-Reply-To: <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
Message-ID: <20150815174129.GJ72293@-.true.nl>

On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:
> Is there a paper or a presentation that discusses the drops in the core?
> 
> If i were to break the total path into three legs -- the first, middle
> and the last, then are you saying that the probability of packet loss
> is perhaps 1/3 in each leg (because the packet passes through
> different IXes).

It is unlikely packets pass through an IXP more then once.

Kind regards,

Job

From bill at herrin.us  Sat Aug 15 17:42:53 2015
From: bill at herrin.us (William Herrin)
Date: Sat, 15 Aug 2015 13:42:53 -0400
Subject: Drops in Core
In-Reply-To: <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
Message-ID: <CAP-guGVcW6BDk+3A4r2XLSWtnRhPeQj6KfrhjeAQ3jBRaENqpA@mail.gmail.com>

On Sat, Aug 15, 2015 at 1:31 PM, Glen Kent <glen.kent at gmail.com> wrote:
> Is there a paper or a presentation that discusses the drops in the core?

Hi Glen,

Probably, but I don't know where to point you.


> If i were to break the total path into three legs -- the first, middle and
> the last, then are you saying that the probability of packet loss is perhaps
> 1/3 in each leg (because the packet passes through different IXes). That
> sounds too aggressive for the middle mile. Dont you think so?

Break it in to five legs:

1. Your immediate last mile
2. The set of networks you directly or indirectly pay to transmit and
receive packets
3. The border link between your networks and the remote user's networks
4. The set of networks the remote user directly or indirectly pays to
transmit and receive packets
5. The remote user's immediate last mile

In some cases, your packets meet on a network which both you and the
remote user pay for. In those cases, leg 3 does not exist. However,
those cases are less common than the one where neither of you pays the
same networks.

Legs 1 and 5 are often over noisy copper wire suspended from a street pole.
Leg 3 is routinely under-provisioned (too little bandwidth for the
traffic demand).
Legs 2 and 4 rarely exhibit loss for long.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From mpetach at netflight.com  Sat Aug 15 18:14:14 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 15 Aug 2015 11:14:14 -0700
Subject: Drops in Core
In-Reply-To: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
Message-ID: <CAEmG1=pOGJbYXgXqvtFhrFM5eNdSk-XRr+U57Vf5aEkik8L4EQ@mail.gmail.com>

Quite the inverse, I'd say; most of the capacity
headaches center around the handoff between
networks, and most of the congestion points
I come across are with private peering links
where one party or the other is unwilling or
unable to augment capacity.  The first and
last mile are fine, but the handoff between
the networks is where congestion and drops
occur.
As others have noted, this will vary greatly
depending on the network in question--so
asking a broad community like this is going
to yield a broad range of answers.  You
aren't going to find one single answer, you'll
find a probability curve that represents the
answers from many people running different
networks.
You'll find the location of packet drops tends
to shift depending on where companies are
willing to spend money; some companies
will spend money on the access layer to
ensure no drops happen there, but are
less willing to pay for capacity upgrades
at peering handoffs.  Other networks will
short-change their access, but maintain a
well-connected peering edge.

So--short answer is there is no one answer
to your question.  Collect the different answers,
plot the curve, and decide where along the
curve you want *your* network to land,
and build accordingly.  Nobody has infinite
money, so nobody builds to a level to ensure
zero loss probability to every destination around
the planet.

Matt



On Sat, Aug 15, 2015 at 9:47 AM, Glen Kent <glen.kent at gmail.com> wrote:
> Hi,
>
> Is it fair to say that most traffic drops happen in the access layers, or
> the first and the last miles, and the % of packet drops in the core are
> minimal? So, if the packet has made it past the first mile and has
> "entered" the core then chances are high that the packet will safely get
> across till the exit in the core. Sure once it gets off the core, then all
> bets are off on whether it will get dropped or not. However, the key point
> is that the core usually does not drop too many packets - the probability
> of drops are highest in the access side.
>
> Is this correct?
>
> Glen
>

From mpetach at netflight.com  Sat Aug 15 19:15:59 2015
From: mpetach at netflight.com (Matthew Petach)
Date: Sat, 15 Aug 2015 12:15:59 -0700
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
References: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
 <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
Message-ID: <CAEmG1=oWiwMfXADbSOsjmcEeCAbYHYapZbnvX73niDwb7qEtKA@mail.gmail.com>

I dunno, Jim, that sounds almost like you might
think the inevitable outcome will be an "everyone
pays" model of settlements, the way telcos do
it.  Unfortunately, in that model, the only winners
are the transit networks in the middle, because
no accounting department is going to want to
keep track of settlements for 4,000 other ASNs
that you peer with; their demand will be "reduce
the number of invoices, aggregate through 2 or
3 providers so we only have a small number of
invoices to reconcile."
I can see where you're coming from, but I'm not
sure I like the destination.  :(

Matt


On Sat, Aug 15, 2015 at 10:32 AM, jim deleskie <deleskie at gmail.com> wrote:
> In my 20+ yrs now of playing this game, "everyone" has had a turn thinking
> their content/eyeballs are special and should get free "peering".
>
> On Sat, Aug 15, 2015 at 1:59 PM, Mike Hammett <nanog at ics-il.net> wrote:
>
>> Arrogance is the only reason I can think of why the incumbents think that
>> way. I'd be surprised if any competitive providers (regardless of their
>> market dominance) would expect free peering.
>>
>>
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>>
>>
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>>
>>
>> ----- Original Message -----
>>
>> From: "Owen DeLong" <owen at delong.com>
>> To: "Matthew Huff" <mhuff at ox.com>
>> Cc: nanog at nanog.org
>> Sent: Saturday, August 15, 2015 11:44:57 AM
>> Subject: Re: net neutrality peering dispute between CenturyTel/Qwest and
>> Cogent in Dallas
>>
>> This issue isn?t limited to Cogent.
>>
>> There is this bizarre belief by the larger eyeball networks (and CC, VZ,
>> and TW are the worst offenders, pretty much in that order) that they are
>> entitled to be paid by both the content provider _AND_ the eyeball user for
>> carrying bits between the two.
>>
>> In a healthy market, the eyeball providers would face competition and the
>> content providers would simply ignore these demands and the eyeballs would
>> buy from other eyeball providers.
>>
>> Unfortunately, especially in the US, we don?t have a healthy market. In
>> the best of circumstances, we have oligopolies and in the worst places, we
>> have effective (or even actual) monopolies.
>>
>> For example, in the area where I live, the claim you will hear is that
>> there is competition. With my usage patterns, that?s a choice between
>> Comcast (up to 30/7 $100/mo), AT&T DSL (1.5M/384k $40/mo+) and wireless (Up
>> to 30/15 $500+/month).
>>
>> I?m not in some rural backwater or even some second-tier metro. I?m within
>> 10 miles of the former MAE West and also within 10 miles of Equinix SV1 (11
>> Great Oaks). There?s major fiber bundles within 2 miles of my house. I?m
>> near US101 and Capitol Expressway in San Jose.
>>
>> The reason that things are this way, IMHO, is because we have allowed
>> ?facilities based carriers? to leverage the monopoly on physical
>> infrastructure into a monopoly for services over that infrastructure.
>>
>> The most viable solution, IMHO, is to require a separation between
>> physical infrastructure providers and those that provide services over that
>> infrastructure. Breaking the tight coupling between the two and requiring
>> physical infrastructure providers to lease facilities to operators on an
>> equal footing for all operators will reduce the barriers to competition in
>> the operator space. It will also make limited competition in the facilities
>> space possible, though unlikely.
>>
>> This model exists to some extent in a few areas that have municipal
>> residential fiber services, and in most of those localities, it is working
>> well.
>>
>> That?s one of the reasons that the incumbent facilities based carriers
>> have lobbied so hard to get laws in states where a city has done this that
>> prevent other cities from following suit.
>>
>> Fortunately, one of the big gains in recent FCC rulings is that these laws
>> are likely to be rendered null and void.
>>
>> Unfortunately, there is so much vested interest in the status quo that
>> achieving this sort of separation is unlikely without a really strong grass
>> roots movement. Sadly, the average sound-bite oriented citizen doesn?t know
>> (or want to learn) enough to facilitate such a grass-roots movement, so if
>> we want to build such a future, we have a long slog of public education and
>> recruitment ahead of us.
>>
>> In the mean time, we?ll get to continue to watch companies like CC, VZ, TW
>> screw over their customers and the content providers their customers want
>> to reach for the sake of extorting extra money from both sides of the
>> transaction.
>>
>> Owen
>>
>> > On Aug 15, 2015, at 06:40 , Matthew Huff <mhuff at ox.com> wrote:
>> >
>> > It's only partially about net neutrality. Cogent provides cheap
>> bandwidth for content providers, and sends a lot of traffic to eyeball
>> networks. In the past, peering partners expected symmetrical load sharing.
>> Cogent feels that eyeball networks should be happy to carry their traffic
>> since the customers want their services, the eyeball networks want Cogent
>> to pay them extra. When there is congestion, neither side wants to upgrade
>> their peeing until this is resolved, so they haven't. This has been going
>> on for at least 5 years, and happens all over the cogent peering map.
>> >
>> > Depending on what protocol you are using, it can be an issue or not. Our
>> end users on eyeball networks had difficulty maintaining VPN connections.
>> We had to drop our Cogent upstream and work with our remaining upstream
>> provides to traffic engineer around Cogent. YMMV.
>> >
>> >
>> >
>> > ----
>> > 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 Jordan
>> Hamilton
>> > Sent: Friday, August 14, 2015 5:31 PM
>> > To: nanog at nanog.org
>> > Subject: net neutrality peering dispute between CenturyTel/Qwest and
>> Cogent in Dallas
>> >
>> > I have several customers that are having packet loss issues, the packet
>> loss appears to be associated with a Cogent router interface of
>> 38.104.86.222. My upstream provider is telling me that the packet loss is
>> being caused by a net neutrality peering dispute between CenturyTel/Quest
>> and Cogent in Dallas. I did some quick googling to see if I could come up
>> with any articles or something like that I could provide to my customers
>> and did not see anything. Anyone know any details?
>> >
>> > Thanks
>> >
>> > Jordan Hamilton
>> > Senior Telecommunications Engineer
>> >
>> > Empire District Electric Co.
>> > 720 Schifferdecker
>> > PO Box 127
>> > Joplin, MO 64802
>> >
>> > Ph: 417-625-4223
>> > Cell: 417-388-3351
>> >
>> >
>> > --
>> > Note: To protect against computer viruses, e-mail programs may prevent
>> sending or receiving certain types of file attachments. Check your e-mail
>> security settings to determine how attachments are handled.
>> >
>> > --
>> > This e-mail and any files transmitted with it are the property of THE
>> EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely
>> for the use of the individual or entity to whom this email is addressed. If
>> you are not one of the named recipients or otherwise have reason to believe
>> that you have received this message in error, please delete this message
>> immediately from your computer and contact the sender by telephone at
>> (417)-625-5100.
>> > Any other use, retention, dissemination, forwarding, printing or copying
>> of this email is strictly prohibited.
>>
>>
>>
>

From sean at donelan.com  Sat Aug 15 19:59:38 2015
From: sean at donelan.com (Sean Donelan)
Date: Sat, 15 Aug 2015 15:59:38 -0400 (EDT)
Subject: Drops in Core
In-Reply-To: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1508151532420.99291@cnex.qbaryna.pbz>

On Sat, 15 Aug 2015, Glen Kent wrote:
> bets are off on whether it will get dropped or not. However, the key point
> is that the core usually does not drop too many packets - the probability
> of drops are highest in the access side.
>
> Is this correct?

1. TCP (and most other IP protocols) depends on, and forces packet 
congestion and drops.  Packet drops alone are not necessarily a 
measure of network quality.  Other than some laboratory conditions,
there must always be some congestion somewhere.

2. Packet queuing and drops are most likely at network transition points. 
Usually speed or latency transition points, but also network 
administration transition points.

3. Packet queuing and drops are less likely between network transition 
points, i.e. across the same network (LAN, WAN, ISP, etc).

That's why some ISPs claim they have 0% packet loss on their network. They 
don't include network transition points in their statistics; but have 
worse end-to-end performance than another network which includes 0.1%
packet drops in their reported statistics.

Generally I don't believe ISPs that claim 100% uptime or 0% packet loss.

From owen at delong.com  Sat Aug 15 20:01:36 2015
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Aug 2015 13:01:36 -0700
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
References: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
 <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
Message-ID: <B82AA595-C765-4C81-9F0B-38E99EC1A451@delong.com>

Let me turn that on its head?

I don?t think anyone?s eyeballs are special.
I don?t think anyone?s content is special.

I think everyone should get free peering with any network whose customers 
expect to be able to reach that other network?s customers.

Ignoring for a moment the idea of maximizing effective avarice, think how
much better it would be for eyeballs and content providers alike if they
could all just peer directly settlement free and/or pay a single layer of
transit providers all of whom peered with each other
for free.

Time and time again we have repeatedly proven that increased interconnect
density and promiscuous settlement free peering reduce
costs, improve performance, and generally make the internet better for
all concerned.

Now, ask yourself? If everyone followed that model, would it actually reduce
the viability of any of the businesses in question?

IMHO, there?s only one yes answer here? If enough of the eyeball/content
providers are able to cooperate and peer with each other directly, you might
see a significant impact (reduction in need) on transit providers as their entire
business would become largely irrelevant.

That?s called cutting out the middle man. In almost every industry that has been
able to do so, it?s been considered a really good thing for everyone except the
middle man who rarely gets much sympathy.

Owen

> On Aug 15, 2015, at 10:32 , jim deleskie <deleskie at gmail.com> wrote:
> 
> In my 20+ yrs now of playing this game, "everyone" has had a turn thinking
> their content/eyeballs are special and should get free "peering".
> 
> On Sat, Aug 15, 2015 at 1:59 PM, Mike Hammett <nanog at ics-il.net> wrote:
> 
>> Arrogance is the only reason I can think of why the incumbents think that
>> way. I'd be surprised if any competitive providers (regardless of their
>> market dominance) would expect free peering.
>> 
>> 
>> 
>> 
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> 
>> 
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>> 
>> 
>> ----- Original Message -----
>> 
>> From: "Owen DeLong" <owen at delong.com>
>> To: "Matthew Huff" <mhuff at ox.com>
>> Cc: nanog at nanog.org
>> Sent: Saturday, August 15, 2015 11:44:57 AM
>> Subject: Re: net neutrality peering dispute between CenturyTel/Qwest and
>> Cogent in Dallas
>> 
>> This issue isn?t limited to Cogent.
>> 
>> There is this bizarre belief by the larger eyeball networks (and CC, VZ,
>> and TW are the worst offenders, pretty much in that order) that they are
>> entitled to be paid by both the content provider _AND_ the eyeball user for
>> carrying bits between the two.
>> 
>> In a healthy market, the eyeball providers would face competition and the
>> content providers would simply ignore these demands and the eyeballs would
>> buy from other eyeball providers.
>> 
>> Unfortunately, especially in the US, we don?t have a healthy market. In
>> the best of circumstances, we have oligopolies and in the worst places, we
>> have effective (or even actual) monopolies.
>> 
>> For example, in the area where I live, the claim you will hear is that
>> there is competition. With my usage patterns, that?s a choice between
>> Comcast (up to 30/7 $100/mo), AT&T DSL (1.5M/384k $40/mo+) and wireless (Up
>> to 30/15 $500+/month).
>> 
>> I?m not in some rural backwater or even some second-tier metro. I?m within
>> 10 miles of the former MAE West and also within 10 miles of Equinix SV1 (11
>> Great Oaks). There?s major fiber bundles within 2 miles of my house. I?m
>> near US101 and Capitol Expressway in San Jose.
>> 
>> The reason that things are this way, IMHO, is because we have allowed
>> ?facilities based carriers? to leverage the monopoly on physical
>> infrastructure into a monopoly for services over that infrastructure.
>> 
>> The most viable solution, IMHO, is to require a separation between
>> physical infrastructure providers and those that provide services over that
>> infrastructure. Breaking the tight coupling between the two and requiring
>> physical infrastructure providers to lease facilities to operators on an
>> equal footing for all operators will reduce the barriers to competition in
>> the operator space. It will also make limited competition in the facilities
>> space possible, though unlikely.
>> 
>> This model exists to some extent in a few areas that have municipal
>> residential fiber services, and in most of those localities, it is working
>> well.
>> 
>> That?s one of the reasons that the incumbent facilities based carriers
>> have lobbied so hard to get laws in states where a city has done this that
>> prevent other cities from following suit.
>> 
>> Fortunately, one of the big gains in recent FCC rulings is that these laws
>> are likely to be rendered null and void.
>> 
>> Unfortunately, there is so much vested interest in the status quo that
>> achieving this sort of separation is unlikely without a really strong grass
>> roots movement. Sadly, the average sound-bite oriented citizen doesn?t know
>> (or want to learn) enough to facilitate such a grass-roots movement, so if
>> we want to build such a future, we have a long slog of public education and
>> recruitment ahead of us.
>> 
>> In the mean time, we?ll get to continue to watch companies like CC, VZ, TW
>> screw over their customers and the content providers their customers want
>> to reach for the sake of extorting extra money from both sides of the
>> transaction.
>> 
>> Owen
>> 
>>> On Aug 15, 2015, at 06:40 , Matthew Huff <mhuff at ox.com> wrote:
>>> 
>>> It's only partially about net neutrality. Cogent provides cheap
>> bandwidth for content providers, and sends a lot of traffic to eyeball
>> networks. In the past, peering partners expected symmetrical load sharing.
>> Cogent feels that eyeball networks should be happy to carry their traffic
>> since the customers want their services, the eyeball networks want Cogent
>> to pay them extra. When there is congestion, neither side wants to upgrade
>> their peeing until this is resolved, so they haven't. This has been going
>> on for at least 5 years, and happens all over the cogent peering map.
>>> 
>>> Depending on what protocol you are using, it can be an issue or not. Our
>> end users on eyeball networks had difficulty maintaining VPN connections.
>> We had to drop our Cogent upstream and work with our remaining upstream
>> provides to traffic engineer around Cogent. YMMV.
>>> 
>>> 
>>> 
>>> ----
>>> 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 Jordan
>> Hamilton
>>> Sent: Friday, August 14, 2015 5:31 PM
>>> To: nanog at nanog.org
>>> Subject: net neutrality peering dispute between CenturyTel/Qwest and
>> Cogent in Dallas
>>> 
>>> I have several customers that are having packet loss issues, the packet
>> loss appears to be associated with a Cogent router interface of
>> 38.104.86.222. My upstream provider is telling me that the packet loss is
>> being caused by a net neutrality peering dispute between CenturyTel/Quest
>> and Cogent in Dallas. I did some quick googling to see if I could come up
>> with any articles or something like that I could provide to my customers
>> and did not see anything. Anyone know any details?
>>> 
>>> Thanks
>>> 
>>> Jordan Hamilton
>>> Senior Telecommunications Engineer
>>> 
>>> Empire District Electric Co.
>>> 720 Schifferdecker
>>> PO Box 127
>>> Joplin, MO 64802
>>> 
>>> Ph: 417-625-4223
>>> Cell: 417-388-3351
>>> 
>>> 
>>> --
>>> Note: To protect against computer viruses, e-mail programs may prevent
>> sending or receiving certain types of file attachments. Check your e-mail
>> security settings to determine how attachments are handled.
>>> 
>>> --
>>> This e-mail and any files transmitted with it are the property of THE
>> EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely
>> for the use of the individual or entity to whom this email is addressed. If
>> you are not one of the named recipients or otherwise have reason to believe
>> that you have received this message in error, please delete this message
>> immediately from your computer and contact the sender by telephone at
>> (417)-625-5100.
>>> Any other use, retention, dissemination, forwarding, printing or copying
>> of this email is strictly prohibited.
>> 
>> 
>> 


From mark.tinka at seacom.mu  Sat Aug 15 20:35:18 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 15 Aug 2015 22:35:18 +0200
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
References: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
 <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
Message-ID: <55CFA286.7040004@seacom.mu>



On 15/Aug/15 19:32, jim deleskie wrote:

> In my 20+ yrs now of playing this game, "everyone" has had a turn thinking
> their content/eyeballs are special and should get free "peering".

That's why those tired of playing the game build their own networks to
take out the middleman, for better or worse.

Mark.

From mark.tinka at seacom.mu  Sat Aug 15 20:45:34 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 15 Aug 2015 22:45:34 +0200
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <B82AA595-C765-4C81-9F0B-38E99EC1A451@delong.com>
References: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
 <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
 <B82AA595-C765-4C81-9F0B-38E99EC1A451@delong.com>
Message-ID: <55CFA4EE.8010202@seacom.mu>



On 15/Aug/15 22:01, Owen DeLong wrote:

>
> IMHO, there?s only one yes answer here? If enough of the eyeball/content
> providers are able to cooperate and peer with each other directly, you might
> see a significant impact (reduction in need) on transit providers as their entire
> business would become largely irrelevant.

This will work in a single market.

I've thought about this before too - when you start to cross nations or
continents, transit providers became a necessity; the eyeball networks
are typically not geared up to handle international or trans-continental
communications on their own.

The solution would be content providers deploying in each country to
remove the need for transit, but they still have to feed those clusters
somehow.

Ultimately, the big content players build and run their own networks,
completely bypassing the transit providers and peering with the eyeball
(and all) networks wherever they pitch tent. As it were, not all of them
have this muscle.

Mark.


From deleskie at gmail.com  Sat Aug 15 20:45:58 2015
From: deleskie at gmail.com (jim deleskie)
Date: Sat, 15 Aug 2015 17:45:58 -0300
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <55CFA286.7040004@seacom.mu>
References: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
 <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
 <55CFA286.7040004@seacom.mu>
Message-ID: <CAJL_ZMN=bi03d8FMWq9FugEHXk9KpUJCd0XeEYFB5JxFNF2J1g@mail.gmail.com>

There is more to it, then just being tired of it, it take, $$ and time and
bodies to build a network, even in 1 country.  Its not something everyone
can do.  I suspect the "game" and transit networks, will continue long
after most of us are no long "playing"


On Sat, Aug 15, 2015 at 5:35 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 15/Aug/15 19:32, jim deleskie wrote:
>
> > In my 20+ yrs now of playing this game, "everyone" has had a turn
> thinking
> > their content/eyeballs are special and should get free "peering".
>
> That's why those tired of playing the game build their own networks to
> take out the middleman, for better or worse.
>
> Mark.
>

From mark.tinka at seacom.mu  Sat Aug 15 20:48:05 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 15 Aug 2015 22:48:05 +0200
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <CAJL_ZMN=bi03d8FMWq9FugEHXk9KpUJCd0XeEYFB5JxFNF2J1g@mail.gmail.com>
References: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <598746933.8767.1439658026284.JavaMail.mhammett@ThunderFuck>
 <CAJL_ZMNd1d46d4Pqg70yYadrS6dnO9Vd3j+zyMkayNOTq+c9LA@mail.gmail.com>
 <55CFA286.7040004@seacom.mu>
 <CAJL_ZMN=bi03d8FMWq9FugEHXk9KpUJCd0XeEYFB5JxFNF2J1g@mail.gmail.com>
Message-ID: <55CFA585.6030309@seacom.mu>



On 15/Aug/15 22:45, jim deleskie wrote:

> There is more to it, then just being tired of it, it take, $$ and time
> and bodies to build a network, even in 1 country.  Its not something
> everyone can do.  I suspect the "game" and transit networks, will
> continue long after most of us are no long "playing"

I do not disagree.

Mark.

From hmcgregor at biggeeks.org  Sat Aug 15 22:50:54 2015
From: hmcgregor at biggeeks.org (Harry McGregor)
Date: Sat, 15 Aug 2015 15:50:54 -0700
Subject: net neutrality peering dispute between CenturyTel/Qwest and Cogent
 in Dallas
In-Reply-To: <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
References: <9E011DD002D07D44997466761AE668099F3468C9@SRV-EMPIRE183V.empiredistrict.com>
 <3579403fd04b4a5bbcbc6c232afae0ba@pur-vm-exch13n1.ox.com>
 <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
Message-ID: <55CFC24E.4090204@biggeeks.org>



On 08/15/2015 09:44 AM, Owen DeLong wrote:
<snip

> The most viable solution, IMHO, is to require a separation between physical infrastructure providers and those that provide services over that infrastructure. Breaking the tight coupling between the two and requiring physical infrastructure providers to lease facilities to operators on an equal footing for all operators will reduce the barriers to competition in the operator space. It will also make limited competition in the facilities space possible, though unlikely.
>
> This model exists to some extent in a few areas that have municipal residential fiber services, and in most of those localities, it is working well.
>
> That?s one of the reasons that the incumbent facilities based carriers have lobbied so hard to get laws in states where a city has done this that prevent other cities from following suit.
>
> Fortunately, one of the big gains in recent FCC rulings is that these laws are likely to be rendered null and void.
>
> Unfortunately, there is so much vested interest in the status quo that achieving this sort of separation is unlikely without a really strong grass roots movement. Sadly, the average sound-bite oriented citizen doesn?t know (or want to learn) enough to facilitate such a grass-roots movement, so if we want to build such a future, we have a long slog of public education and recruitment ahead of us.
>
> In the mean time, we?ll get to continue to watch companies like CC, VZ, TW screw over their customers and the content providers their customers want to reach for the sake of extorting extra money from both sides of the transaction.
>
> Owen

I have talked about this idea for years, but most places seem to have a 
difficult time understanding the difference between layer 0, layer 2, 
and layer 3 networks.

IMHO the should be one residential fiber network (either passive or 
active, depending on the deployment and the physical layout of the 
area), and it should be run by an "essential" utility, such as the 
city/county water department, or if necessary the local electric company 
(I far prefer the water department).  The access would be near 
universal, and the layer 0 and layer 2 network fees would be part of the 
"water" bill.  Apartment complexes may have to be serviced with G.fast 
or other technologies to make the deployment faster and easier.

Getting IP bandwidth, technical support, voice service, and video 
service would be a competitive service provider model, with local ISPs, 
and large Cable COs and TelCOs competing on top of this physical 
network.  You could even have providers that specialize in low income 
"life line" services, such as 5Mbit of IP bandwidth and local voice 
service with e911.

Historically services that have huge sunk costs, and high build out 
costs have been a natural monopoly and regulated.  You would not think 
of trying to build out a competitive water or sewer network, and most 
building codes prevent the installation of a septic system if a sewer 
connection is at all possible.   Why we are not going this way for a 
high cost of build out network (last mile) is beyond me.

Before this happens (ie when hell freezes over), I would like to see new 
home communities deploying fiber networks as part of the building of the 
"master plan" of the community.   That way the home owners association 
can go out for bid every year or few years for a service provider to 
operate the fiber network.   Around here (souther AZ) new communities 
tend to either alliance with CenturyLink, Cox, or Comcast depending on 
the location, and they DO NOT bring in the other providers.  If a 
builder goes with Cox, you can NOT get a CenturyLink (ILEC) landline or 
DSL, if a builder goes with CenturyLink, Cox will not run anything into 
the community.

-Harry

From alif.terranson at gmail.com  Sun Aug 16 02:18:21 2015
From: alif.terranson at gmail.com (alif.terranson (IMAP))
Date: Sat, 15 Aug 2015 21:18:21 -0500
Subject: Drops in Core
Message-ID: <i3g0ycgcivyv1mityr8nynxn.1439691501936@email.android.com>

Sean Donelan Opined Thusly,

"Generally I?don't?believe ISPs that claim 100% uptime or 0% packet loss."

I have seen a "perfect score" on a Keynote evaluation, while we had a rather nasty outage outside a preststed maintenance window. ?When we objected that the outages was a planned maintenance that somehow escaped publication, it was ignored by Keynote - how generous! ?I doubt anyone here would deny the difficulty of maintaining a five 9's record, going above and beyond to claim no packet loss just tells you who they really are...

--
Yours,
/s/

Alif

Sent from my 100% uptime, packet loss-free digital carrier pigeon.

From mark.tinka at seacom.mu  Sun Aug 16 05:59:47 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 16 Aug 2015 07:59:47 +0200
Subject: net neutrality peering dispute between CenturyTel/Qwest and
 Cogent in Dallas
In-Reply-To: <55CFC24E.4090204@biggeeks.org>
References: <9E011DD002D07D44997466761AE668099F3468C9@SRV-EMPIRE183V.empiredistrict.com>
 <3579403fd04b4a5bbcbc6c232afae0ba@pur-vm-exch13n1.ox.com>
 <8868CB3D-E35D-46EE-8434-0B70AD0A4F05@delong.com>
 <55CFC24E.4090204@biggeeks.org>
Message-ID: <55D026D3.2090903@seacom.mu>



On 16/Aug/15 00:50, Harry McGregor wrote:

>
>  
>
> Before this happens (ie when hell freezes over), I would like to see
> new home communities deploying fiber networks as part of the building
> of the "master plan" of the community.   That way the home owners
> association can go out for bid every year or few years for a service
> provider to operate the fiber network. 

This is exactly what communities in South Africa are starting to do.

In major suburbs around Johannesburg, neighborhoods are getting their
residents together and putting out bids for service providers to build
and operate FTTH networks on their behalf. In other parts of the
country, the local city or municipal councils are also getting involved.

In other neighborhoods, new and lean service providers are, by their own
volition, pulling fibre into various neighbors and deploying GPON FTTH
access nodes in homes regardless of whether you want a service or not.
If you want the service, ring them up and someone will come set you up.
You only pay for the setup fee, as the ONU remains theirs. This is what
happened in my neighborhood, which means I'm now sitting on a 25M/25M
FTTH service for about US$70/month. Big difference from when I had a
384k/3.2M ADSL service for about the same price.

The idea is that folk are taking matters into their own hands, as while
there is a national broadband strategy, its actual implementation is a
far cry.

Mark.


From patrick at ianai.net  Sun Aug 16 12:00:55 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sun, 16 Aug 2015 08:00:55 -0400
Subject: Drops in Core
In-Reply-To: <20150815174129.GJ72293@-.true.nl>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
 <20150815174129.GJ72293@-.true.nl>
Message-ID: <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>

On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
> On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:

>> Is there a paper or a presentation that discusses the drops in the core?
>> 
>> If i were to break the total path into three legs -- the first, middle
>> and the last, then are you saying that the probability of packet loss
>> is perhaps 1/3 in each leg (because the packet passes through
>> different IXes).
> 
> It is unlikely packets pass through an IXP more then once.

?Unlikely?? That?s putting it mildly.

Unless someone is selling transit over an IX, I do not see how it can happen. And I would characterize transit over IXes far more pessimistically than ?unlikely?.


[Combining responses]
On Aug 15, 2015, at 1:21 PM, Owen DeLong <owen at delong.com> wrote:
> 
> I would say that the probability of a packet drop at any particular peering
> point is less than the probability at one of the two edges.
> 
> However, given that most packets are likely to traverse multiple peering
> points between the two edges, the probability of a packet drop along
> the way at one of the several peering points overall is roughly equal
> to the probability of a drop at one of the two edges.

I?m a little confused why most packets are ?likely to traverse multiple peering points??

Most packets these days are sourced from one of three companies. (Which Owen should know well. :) At least one of those companies published stats saying the vast majority of packets are ?zero or one? AS hop from the destination. I cannot imagine Google or Netflix being 50% behind Akamai on that stat. Which clearly implies most packets traverse ?zero or one? AS hop - i.e. one or zero peering points.

Finally, I would love to see data backing up the statement that packets are more likely to drop at one edge (assuming the destination?) than at a peering point.

-- 
TTFN,
patrick


From job at instituut.net  Sun Aug 16 12:15:18 2015
From: job at instituut.net (Job Snijders)
Date: Sun, 16 Aug 2015 14:15:18 +0200
Subject: Drops in Core
In-Reply-To: <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
 <20150815174129.GJ72293@-.true.nl>
 <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
Message-ID: <20150816121518.GK72293@-.true.nl>

On Sun, Aug 16, 2015 at 08:00:55AM -0400, Patrick W. Gilmore wrote:
> On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
> > On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:
> 
> >> Is there a paper or a presentation that discusses the drops in the core?
> >> 
> >> If i were to break the total path into three legs -- the first, middle
> >> and the last, then are you saying that the probability of packet loss
> >> is perhaps 1/3 in each leg (because the packet passes through
> >> different IXes).
> > 
> > It is unlikely packets pass through an IXP more then once.
> 
> ?Unlikely?? That?s putting it mildly.
> 
> Unless someone is selling transit over an IX, I do not see how it can
> happen. And I would characterize transit over IXes far more
> pessimistically than ?unlikely?.

There is another scenario (which unfortunatly is not that uncommon)
where packets could traverse two IXPs, and no transit is sold over any
of those two IXs.

Imagine the following:

Network A purchases transit from network B & network C. Network B &
Network C peer with each other via an IXP. Network A announces a /16 to
network B but 2 x /17 to network C. Network D peers with B via an IX
(and not with C) and receives the /16 from B, but note that internally
network B has two more specifics covering the /16 received from C and
the /16 itself. Network B will export the /16 (received from customer)
but not the /17s (received over peering) to its peers.

Because of longest prefix matching, network B will route the packets
received from network D over an IXP, towards network C, again over an
IXP. 

This phenomenon is described extensively in the following
Internet-Draft:

    https://tools.ietf.org/html/draft-ietf-grow-filtering-threats-07

Kind regards,

Job

From patrick at ianai.net  Sun Aug 16 12:23:44 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sun, 16 Aug 2015 08:23:44 -0400
Subject: Drops in Core
In-Reply-To: <20150816121518.GK72293@-.true.nl>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
 <20150815174129.GJ72293@-.true.nl>
 <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
 <20150816121518.GK72293@-.true.nl>
Message-ID: <F26C4DF1-3F49-4A6E-AA10-B29AC39F689D@ianai.net>

On Aug 16, 2015, at 8:15 AM, Job Snijders <job at instituut.net> wrote:
> On Sun, Aug 16, 2015 at 08:00:55AM -0400, Patrick W. Gilmore wrote:
>> On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
>>> On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:
>> 
>>>> Is there a paper or a presentation that discusses the drops in the core?
>>>> 
>>>> If i were to break the total path into three legs -- the first, middle
>>>> and the last, then are you saying that the probability of packet loss
>>>> is perhaps 1/3 in each leg (because the packet passes through
>>>> different IXes).
>>> 
>>> It is unlikely packets pass through an IXP more then once.
>> 
>> ?Unlikely?? That?s putting it mildly.
>> 
>> Unless someone is selling transit over an IX, I do not see how it can
>> happen. And I would characterize transit over IXes far more
>> pessimistically than ?unlikely?.
> 
> There is another scenario (which unfortunatly is not that uncommon)
> where packets could traverse two IXPs, and no transit is sold over any
> of those two IXs.
> 
> Imagine the following:
> 
> Network A purchases transit from network B & network C. Network B &
> Network C peer with each other via an IXP. Network A announces a /16 to
> network B but 2 x /17 to network C. Network D peers with B via an IX
> (and not with C) and receives the /16 from B, but note that internally
> network B has two more specifics covering the /16 received from C and
> the /16 itself. Network B will export the /16 (received from customer)
> but not the /17s (received over peering) to its peers.
> 
> Because of longest prefix matching, network B will route the packets
> received from network D over an IXP, towards network C, again over an
> IXP. 
> 
> This phenomenon is described extensively in the following
> Internet-Draft:
> 
>    https://tools.ietf.org/html/draft-ietf-grow-filtering-threats-07

Good point.

Although I have trouble believing it is very common, in the sense that I do not believe it is a large number of packets or percent of traffic.

To be clear, I fully believe people are doing the more specifics to provider B but not C. Sometimes there is even a good reason for it (although probably not usually). However, most of the Internet will send traffic directly to B, or even A - especially since most packets are sourced from CDNs[*].

-- 
TTFN,
patrick

[*] I?m counting in-house CDNs like Google, Netflix, and Apple as ?CDNs? here. Before anyone bitches, trust me, I am probably more aware of the difference between those and a ?real? CDN than nearly anyone else. But those distinctions are orthogonal to the discussion at hand.


From bill at herrin.us  Sun Aug 16 12:44:50 2015
From: bill at herrin.us (William Herrin)
Date: Sun, 16 Aug 2015 08:44:50 -0400
Subject: Drops in Core
In-Reply-To: <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
 <20150815174129.GJ72293@-.true.nl>
 <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
Message-ID: <CAP-guGW=jPS8kB1VdYC5YTOLmRV6zedmn+hjXDMJ0FWa4DQUyA@mail.gmail.com>

On Sun, Aug 16, 2015 at 8:00 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
>> On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:
>
>>> Is there a paper or a presentation that discusses the drops in the core?
>>>
>>> If i were to break the total path into three legs -- the first, middle
>>> and the last, then are you saying that the probability of packet loss
>>> is perhaps 1/3 in each leg (because the packet passes through
>>> different IXes).
>>
>> It is unlikely packets pass through an IXP more then once.
>
> ?Unlikely?? That?s putting it mildly.
>
> Unless someone is selling transit over an IX, I do not see how it
> can happen. And I would characterize transit over IXes far more
> pessimistically than ?unlikely?.

Hi Patrick,

I'm told it happens relatively often in networks supporting a lot of
schools. Being an unpaid pass-through for schools paying other ISPs
functions as a loss-leader that attracts more schools as customers.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From cboyd at gizmopartners.com  Sun Aug 16 19:22:07 2015
From: cboyd at gizmopartners.com (Chris Boyd)
Date: Sun, 16 Aug 2015 14:22:07 -0500
Subject: Data Center operations mail list?
In-Reply-To: <CAMDXq5M9wvC15QkuMyzwx7c+cMcEqF2Y1FTT1dujhn3muVEfWA@mail.gmail.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
 <CAMDXq5M9wvC15QkuMyzwx7c+cMcEqF2Y1FTT1dujhn3muVEfWA@mail.gmail.com>
Message-ID: <16E423B8-7479-494E-AC08-F9A779BA11E0@gizmopartners.com>


> On Aug 15, 2015, at 12:13 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> 
> There is reasonable demand for a forum.  It might need a little marketing
> to get a list with traction going.

There seems to be some traction, with 268 members on the NADCOG list so far.

?Chris


From idafe.houghton at gmail.com  Sun Aug 16 19:33:23 2015
From: idafe.houghton at gmail.com (Idafe Houghton)
Date: Sun, 16 Aug 2015 21:33:23 +0200
Subject: Data Center operations mail list?
In-Reply-To: <16E423B8-7479-494E-AC08-F9A779BA11E0@gizmopartners.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
 <CAMDXq5M9wvC15QkuMyzwx7c+cMcEqF2Y1FTT1dujhn3muVEfWA@mail.gmail.com>
 <16E423B8-7479-494E-AC08-F9A779BA11E0@gizmopartners.com>
Message-ID: <1439753603.2269.0@smtp.gmail.com>

While I am recent incorporation, have you ever thought about organizing 
a few meetups? I am not from America, but there has been a boom 
recently, on a few cities around the world striving to make a global 
linked community network of techlabs.

Probably, it isn't suited for this community mailing-list, that is 
pretty specialized, but just saying. I have been lately interested in 
these forms of communication, knowledge and experience sharing.

My tips.

On dom, ago 16, 2015 at 9:22 , Chris Boyd <cboyd at gizmopartners.com> 
wrote:
> 
>>  On Aug 15, 2015, at 12:13 PM, Martin Hannigan <hannigan at gmail.com> 
>> wrote:
>> 
>>  There is reasonable demand for a forum.  It might need a little 
>> marketing
>>  to get a list with traction going.
> 
> There seems to be some traction, with 268 members on the NADCOG list 
> so far.
> 
> ?Chris
> 

From hannigan at gmail.com  Sun Aug 16 23:57:00 2015
From: hannigan at gmail.com (Martin Hannigan)
Date: Sun, 16 Aug 2015 19:57:00 -0400
Subject: Data Center operations mail list?
In-Reply-To: <16E423B8-7479-494E-AC08-F9A779BA11E0@gizmopartners.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
 <CAMDXq5M9wvC15QkuMyzwx7c+cMcEqF2Y1FTT1dujhn3muVEfWA@mail.gmail.com>
 <16E423B8-7479-494E-AC08-F9A779BA11E0@gizmopartners.com>
Message-ID: <CAMDXq5Oo2ZyoCOMur=dNo1ErEAcOyu7-6niX86GZExPUvjunOA@mail.gmail.com>

On Sun, Aug 16, 2015 at 3:22 PM, Chris Boyd <cboyd at gizmopartners.com> wrote:

>
> > On Aug 15, 2015, at 12:13 PM, Martin Hannigan <hannigan at gmail.com>
> wrote:
> >
> > There is reasonable demand for a forum.  It might need a little marketing
> > to get a list with traction going.
>
> There seems to be some traction, with 268 members on the NADCOG list so
> far.
>
>
>
Great! It's a little more complicated than list member count. Consider a
social media presence as well? While the Facebook isn't designed as mailing
list or collaboration media, it sort of works communication wise. If there
were some service like /. for mailing lists (that I knew about) I would
really like the community thumbs up/thumbs down approach so you can sift
through quality vs. quantity. The quality issue has been discussed for
literally years.

Good luck and I just joined. Looking forward to it!

Best,

-M<

From nanogml at Mail.DDoS-Mitigator.net  Mon Aug 17 00:22:01 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Sun, 16 Aug 2015 17:22:01 -0700
Subject: Data Center operations mail list?
In-Reply-To: <CAMDXq5Oo2ZyoCOMur=dNo1ErEAcOyu7-6niX86GZExPUvjunOA@mail.gmail.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
 <CAMDXq5M9wvC15QkuMyzwx7c+cMcEqF2Y1FTT1dujhn3muVEfWA@mail.gmail.com>
 <16E423B8-7479-494E-AC08-F9A779BA11E0@gizmopartners.com>
 <CAMDXq5Oo2ZyoCOMur=dNo1ErEAcOyu7-6niX86GZExPUvjunOA@mail.gmail.com>
Message-ID: <20150817002201.GA23549@Mail.DDoS-Mitigator.net>


hi ya martin

On 08/16/15 at 07:57pm, Martin Hannigan wrote:
> On Sun, Aug 16, 2015 at 3:22 PM, Chris Boyd <cboyd at gizmopartners.com> wrote:
> 
> > There seems to be some traction, with 268 members on the NADCOG list so
> > far.

good

> Great! It's a little more complicated than list member count. Consider a
> social media presence as well? While the Facebook isn't designed as mailing
> list or collaboration media, it sort of works communication wise. If there

what kind of "social media presence" is what keep bouncing off my empty head

i can't stand fb/twitter/other-selfie-stuff/utube/etc
( aka too many fake emails from people i dont know pretending to know me )

> were some service like /. for mailing lists (that I knew about) I would
> really like the community thumbs up/thumbs down approach so you can sift

/. seems to have tied itself with fb ... you'd need a major following
before /. accepts and publish your submissions

any comments on the "meetup.com" style ??? ( ?? too big ?? too broad ?? )

one can always create the media/methodology that one wants ??

> through quality vs. quantity. The quality issue has been discussed for
> literally years.

quality/quantify for "dc" content seems okay to start things rolling

magic pixie dust
alvin
#
# Sushi-Critics.net ... social stuff... if you're visiting in silicon valley 
# Food-Critics.net .... social stuff... sillicon beach, reno/lasvegas lemme know
#
# ITX-Blades.net ... 10 mini-itx blades in 4U chassis ...
# DDoS-Mitigator.net ..
#

From streiner at cluebyfour.org  Mon Aug 17 03:26:41 2015
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sun, 16 Aug 2015 23:26:41 -0400 (EDT)
Subject: Cogent revisited
In-Reply-To: <CAAWx_pWn1nXLkFcsNvBTf8BCOg_4gWvLs9v2nsZvQf9KP7-hEg@mail.gmail.com>
References: <01bb01d0d43e$0fd8c630$2f8a5290$@webjogger.net>
 <CAB2srOB6HQZGDrNx1xaM=x6b8OREu6x7yXadBcVwTwtCgmh_hA@mail.gmail.com>
 <011f01d0d476$eb8f4950$c2addbf0$@webjogger.net>
 <CAAWx_pWn1nXLkFcsNvBTf8BCOg_4gWvLs9v2nsZvQf9KP7-hEg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1508162319280.734@whammy.cluebyfour.org>

On Wed, 12 Aug 2015, James Bensley wrote:

> Perhaps that depends on were are you in the world and your traffic types.
>
> I have worked with two UK ISPs that have Cogent as one of their
> transit providers, neither have had any problems in the 5+ years
> they've both had the Cogent transit, it has always "just worked".

And for the most part, that will be the case.  If you're multi-homed, it's 
really not a major issue.  It's more when someone is:
1. single-homed to Cogent and they get into a peering/transit/pay-us spat 
with one of the DFZ carriers, and Cogent gets de-peered. Single-homed 
customers of $de-peering_carrier disappear from your view of the Internet.
2. single-homed to one of said DFZ carriers and a peering/transit/pay-us 
spat arises with Cogent, and Cogent gets de-peered.  Single-homed customers
of Cogent's disappear from your view of the Internet.

jms

From ramy.ihashish at gmail.com  Mon Aug 17 04:46:01 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Mon, 17 Aug 2015 07:46:01 +0300
Subject: A multi-tenant firewall for an MSSP
Message-ID: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>

Hello All,

We are planning to implement a multi-tenant FW/UTM and start providing
security as a service, I would like to hear if anybody had experience on
this, and if there are any recommendations for the UTM's vendor.

People/customers here are more familiar with the Fortigate, however, we
need to build a well-rounded solution that suits wide range of enterprises'
business needs.

Thanks,

Ramy

From raaki.88 at gmail.com  Mon Aug 17 04:56:22 2015
From: raaki.88 at gmail.com (Rakesh M)
Date: Mon, 17 Aug 2015 10:26:22 +0530
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
Message-ID: <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>

I have seen one of our customers using Sophos and they are relatively happy
about it. Not directly experienced though.

Thanks
Rakesh

On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com>
wrote:

> Hello All,
>
> We are planning to implement a multi-tenant FW/UTM and start providing
> security as a service, I would like to hear if anybody had experience on
> this, and if there are any recommendations for the UTM's vendor.
>
> People/customers here are more familiar with the Fortigate, however, we
> need to build a well-rounded solution that suits wide range of enterprises'
> business needs.
>
> Thanks,
>
> Ramy
>

From colinj at gt86car.org.uk  Mon Aug 17 06:47:15 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Mon, 17 Aug 2015 07:47:15 +0100
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
Message-ID: <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>

sophos utm works great :)

Colin

> On 17 Aug 2015, at 05:56, Rakesh M <raaki.88 at gmail.com> wrote:
> 
> I have seen one of our customers using Sophos and they are relatively happy
> about it. Not directly experienced though.
> 
> Thanks
> Rakesh
> 
> On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com>
> wrote:
> 
>> Hello All,
>> 
>> We are planning to implement a multi-tenant FW/UTM and start providing
>> security as a service, I would like to hear if anybody had experience on
>> this, and if there are any recommendations for the UTM's vendor.
>> 
>> People/customers here are more familiar with the Fortigate, however, we
>> need to build a well-rounded solution that suits wide range of enterprises'
>> business needs.
>> 
>> Thanks,
>> 
>> Ramy
>> 


From aj at jonesy.com.au  Mon Aug 17 07:14:57 2015
From: aj at jonesy.com.au (Andrew Jones)
Date: Mon, 17 Aug 2015 17:14:57 +1000
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
 <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
Message-ID: <c6af218bb1314f92cc86fcfb8a7cbd42@jonesy.com.au>

Is there a multi-tennant capable UTM from Sophos? Or are you using a vm 
instance per customer?
Thanks,
Andrew

On 17.08.2015 16:47, Colin Johnston wrote:
> sophos utm works great :)
>
> Colin
>
>> On 17 Aug 2015, at 05:56, Rakesh M <raaki.88 at gmail.com> wrote:
>>
>> I have seen one of our customers using Sophos and they are 
>> relatively happy
>> about it. Not directly experienced though.
>>
>> Thanks
>> Rakesh
>>
>> On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish 
>> <ramy.ihashish at gmail.com>
>> wrote:
>>
>>> Hello All,
>>>
>>> We are planning to implement a multi-tenant FW/UTM and start 
>>> providing
>>> security as a service, I would like to hear if anybody had 
>>> experience on
>>> this, and if there are any recommendations for the UTM's vendor.
>>>
>>> People/customers here are more familiar with the Fortigate, 
>>> however, we
>>> need to build a well-rounded solution that suits wide range of 
>>> enterprises'
>>> business needs.
>>>
>>> Thanks,
>>>
>>> Ramy
>>>


From nanogml at Mail.DDoS-Mitigator.net  Mon Aug 17 07:27:28 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Mon, 17 Aug 2015 00:27:28 -0700
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
 <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
Message-ID: <20150817072728.GA24988@Mail.DDoS-Mitigator.net>


hi 

> On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com>
> wrote:
> 
> We are planning to implement a multi-tenant FW/UTM and start providing
> security as a service, I would like to hear if anybody had experience on

that'd be a good thing ... but ...

> this, and if there are any recommendations for the UTM's vendor.

the possible vendors would depend on the answers to your idea of
what is "well rounded solution"

	# fortinet's (possible) competitors
	http://ddos-Mitigator.net/Competitors

> People/customers here are more familiar with the Fortigate, however, we
> need to build a well-rounded solution that suits wide range of enterprises'
> business needs.

# i doubt there is one product that provides the "well rounded solution"

in my world, "well rounded solution" would imply at least the following:
- anti virus solution  ( one or more products to resolve the virus issue )
- anti spam solution  ( one or more products to resolve the spam issue )
- iptables with tarpit ( protect against the free tcp-based script kiddies tests )
- udp limiting at isp ( part of iptables or your edge routers )
- icmp limiting at isp ( part of iptables or your edge routers )
- ingress/egress filters for your downlinks
- geographically distributed colo to mitigate small/medium sized ddos attacks
- regulatory compliance this and certified that vs "just anybody" ...
- good response time to fix problems reported by competent customer's IT folks
- other things you deem important to provide ..

pixie dust
alvin
#
# ddos-Mitigator.net
# ddos-Simulator.net


From ramy.ihashish at gmail.com  Mon Aug 17 07:29:47 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Mon, 17 Aug 2015 10:29:47 +0300
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
 <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
Message-ID: <CAOLsBOvYyUCyTVzLtEY125aKs5Eh1gP4MNxRZr1HtURrq9cxPg@mail.gmail.com>

Thank you Rakesh and Colin.

I just want to amend something, "FW as a service" rather than "security as
a service".

Are you sure sophos has such a solution?

Thanks,

Ramy

On Mon, Aug 17, 2015 at 9:47 AM, Colin Johnston <colinj at gt86car.org.uk>
wrote:

> sophos utm works great :)
>
> Colin
>
> > On 17 Aug 2015, at 05:56, Rakesh M <raaki.88 at gmail.com> wrote:
> >
> > I have seen one of our customers using Sophos and they are relatively
> happy
> > about it. Not directly experienced though.
> >
> > Thanks
> > Rakesh
> >
> > On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com>
> > wrote:
> >
> >> Hello All,
> >>
> >> We are planning to implement a multi-tenant FW/UTM and start providing
> >> security as a service, I would like to hear if anybody had experience on
> >> this, and if there are any recommendations for the UTM's vendor.
> >>
> >> People/customers here are more familiar with the Fortigate, however, we
> >> need to build a well-rounded solution that suits wide range of
> enterprises'
> >> business needs.
> >>
> >> Thanks,
> >>
> >> Ramy
> >>
>
>

From colinj at gt86car.org.uk  Mon Aug 17 08:17:20 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Mon, 17 Aug 2015 09:17:20 +0100
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <c6af218bb1314f92cc86fcfb8a7cbd42@jonesy.com.au>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
 <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
 <c6af218bb1314f92cc86fcfb8a7cbd42@jonesy.com.au>
Message-ID: <E6A8392A-B508-4CCA-9820-CFCFC4F8E1BC@gt86car.org.uk>

one vm per sophos utm per customer

works well even with low ram as well

Colin

> On 17 Aug 2015, at 08:14, Andrew Jones <aj at jonesy.com.au> wrote:
> 
> Is there a multi-tennant capable UTM from Sophos? Or are you using a vm instance per customer?
> Thanks,
> Andrew
> 
> On 17.08.2015 16:47, Colin Johnston wrote:
>> sophos utm works great :)
>> 
>> Colin
>> 
>>> On 17 Aug 2015, at 05:56, Rakesh M <raaki.88 at gmail.com> wrote:
>>> 
>>> I have seen one of our customers using Sophos and they are relatively happy
>>> about it. Not directly experienced though.
>>> 
>>> Thanks
>>> Rakesh
>>> 
>>> On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com>
>>> wrote:
>>> 
>>>> Hello All,
>>>> 
>>>> We are planning to implement a multi-tenant FW/UTM and start providing
>>>> security as a service, I would like to hear if anybody had experience on
>>>> this, and if there are any recommendations for the UTM's vendor.
>>>> 
>>>> People/customers here are more familiar with the Fortigate, however, we
>>>> need to build a well-rounded solution that suits wide range of enterprises'
>>>> business needs.
>>>> 
>>>> Thanks,
>>>> 
>>>> Ramy
>>>> 
> 


From raaki.88 at gmail.com  Mon Aug 17 08:57:04 2015
From: raaki.88 at gmail.com (Rakesh M)
Date: Mon, 17 Aug 2015 14:27:04 +0530
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <CAOLsBOvYyUCyTVzLtEY125aKs5Eh1gP4MNxRZr1HtURrq9cxPg@mail.gmail.com>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
 <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
 <CAOLsBOvYyUCyTVzLtEY125aKs5Eh1gP4MNxRZr1HtURrq9cxPg@mail.gmail.com>
Message-ID: <CAC2aK2qWQta8aVqHhOuMEdhxA0gXieVAhvPRRZUwKv_d7ZOApg@mail.gmail.com>

Have a look below Ramy pdf

https://www.sophos.com/en-us/medialibrary/PDFs/partners/sophos_complete_security_msps_dsna.pdf?la=en



On Mon, Aug 17, 2015 at 12:59 PM, Ramy Hashish <ramy.ihashish at gmail.com>
wrote:

> Thank you Rakesh and Colin.
>
> I just want to amend something, "FW as a service" rather than "security as
> a service".
>
> Are you sure sophos has such a solution?
>
> Thanks,
>
> Ramy
>
> On Mon, Aug 17, 2015 at 9:47 AM, Colin Johnston <colinj at gt86car.org.uk>
> wrote:
>
>> sophos utm works great :)
>>
>> Colin
>>
>> > On 17 Aug 2015, at 05:56, Rakesh M <raaki.88 at gmail.com> wrote:
>> >
>> > I have seen one of our customers using Sophos and they are relatively
>> happy
>> > about it. Not directly experienced though.
>> >
>> > Thanks
>> > Rakesh
>> >
>> > On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com
>> >
>> > wrote:
>> >
>> >> Hello All,
>> >>
>> >> We are planning to implement a multi-tenant FW/UTM and start providing
>> >> security as a service, I would like to hear if anybody had experience
>> on
>> >> this, and if there are any recommendations for the UTM's vendor.
>> >>
>> >> People/customers here are more familiar with the Fortigate, however, we
>> >> need to build a well-rounded solution that suits wide range of
>> enterprises'
>> >> business needs.
>> >>
>> >> Thanks,
>> >>
>> >> Ramy
>> >>
>>
>>
>

From patrick at ianai.net  Mon Aug 17 10:10:39 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 17 Aug 2015 06:10:39 -0400
Subject: Drops in Core
In-Reply-To: <CAP-guGW=jPS8kB1VdYC5YTOLmRV6zedmn+hjXDMJ0FWa4DQUyA@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
 <20150815174129.GJ72293@-.true.nl>
 <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
 <CAP-guGW=jPS8kB1VdYC5YTOLmRV6zedmn+hjXDMJ0FWa4DQUyA@mail.gmail.com>
Message-ID: <7759F94D-4836-4ED1-B43E-30EED667656D@ianai.net>

On Aug 16, 2015, at 8:44 AM, William Herrin <bill at herrin.us> wrote:
> On Sun, Aug 16, 2015 at 8:00 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
>> On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
>>> On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:

>>>> Is there a paper or a presentation that discusses the drops in the core?
>>>> 
>>>> If i were to break the total path into three legs -- the first, middle
>>>> and the last, then are you saying that the probability of packet loss
>>>> is perhaps 1/3 in each leg (because the packet passes through
>>>> different IXes).
>>> 
>>> It is unlikely packets pass through an IXP more then once.
>> 
>> ?Unlikely?? That?s putting it mildly.
>> 
>> Unless someone is selling transit over an IX, I do not see how it
>> can happen. And I would characterize transit over IXes far more
>> pessimistically than ?unlikely?.
> 
> Hi Patrick,
> 
> I'm told it happens relatively often in networks supporting a lot of
> schools. Being an unpaid pass-through for schools paying other ISPs
> functions as a loss-leader that attracts more schools as customers.

Lots of people have mentioned ?but XXX happens? to me. And you are all correct. XXX happens.

My point was not ?this never happens?. Just those other topologies are a tiny, tiny fraction of the packets flowing on the Internet.

Most packets flow from CDNs to broadband. And those packets flow mostly direct (on-net or PNI), or over a _single_ IXP. Corner cases exist, but they are just that - corner cases.

-- 
TTFN,
patrick


From james.braunegg at micron21.com  Mon Aug 17 12:10:25 2015
From: james.braunegg at micron21.com (James Braunegg)
Date: Mon, 17 Aug 2015 12:10:25 +0000
Subject: China Telecom / China Unicom IP Transit Pricing
Message-ID: <21de828c26ec4f4e829e3549a1cf9032@EX-01.m21.local>

Dear All

Just wondering if anyone can share with me target IP Transit pricing they have been able to achieve with China Telecom and China Unicom delivered to LA or AMS, after rounds of negations.

Capacity Required (1G to 10G)

Bonus points if you have contact information for someone who can provide competitive pricing

Kindest Regards

James Braunegg
P:  1300 769 972  |  M:  0488 997 207 |  D:  (03) 9751 7616
E:   james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>  |  ABN:  12 109 977 666
W:  www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection>   T: @micron21

Follow us on Twitter<http://www.twitter.com/micron21> for important service and system updates.

[M21.jpg]

This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.


From colinj at gt86car.org.uk  Mon Aug 17 12:30:35 2015
From: colinj at gt86car.org.uk (Colin Johnston)
Date: Mon, 17 Aug 2015 13:30:35 +0100
Subject: China Telecom / China Unicom IP Transit Pricing
In-Reply-To: <21de828c26ec4f4e829e3549a1cf9032@EX-01.m21.local>
References: <21de828c26ec4f4e829e3549a1cf9032@EX-01.m21.local>
Message-ID: <729855D0-25C9-45B3-B792-74C9A185EF15@gt86car.org.uk>

Is this based on 90% to 95% of the traffic is invalid/spam/scans/direct-attacks ?
If based on engagement with abuse teams then give a factor for engagement, otherwise don?t bother.


Colin

> On 17 Aug 2015, at 13:10, James Braunegg <james.braunegg at micron21.com> wrote:
> 
> Dear All
> 
> Just wondering if anyone can share with me target IP Transit pricing they have been able to achieve with China Telecom and China Unicom delivered to LA or AMS, after rounds of negations.
> 
> Capacity Required (1G to 10G)
> 
> Bonus points if you have contact information for someone who can provide competitive pricing
> 
> Kindest Regards
> 
> James Braunegg
> P:  1300 769 972  |  M:  0488 997 207 |  D:  (03) 9751 7616
> E:   james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>  |  ABN:  12 109 977 666
> W:  www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection>   T: @micron21
> 
> Follow us on Twitter<http://www.twitter.com/micron21> for important service and system updates.
> 
> [M21.jpg]
> 
> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
> 


From mhuff at ox.com  Mon Aug 17 13:02:13 2015
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 17 Aug 2015 13:02:13 +0000
Subject: Cogent revisited
In-Reply-To: <Pine.LNX.4.64.1508162319280.734@whammy.cluebyfour.org>
References: <01bb01d0d43e$0fd8c630$2f8a5290$@webjogger.net>
 <CAB2srOB6HQZGDrNx1xaM=x6b8OREu6x7yXadBcVwTwtCgmh_hA@mail.gmail.com>
 <011f01d0d476$eb8f4950$c2addbf0$@webjogger.net>
 <CAAWx_pWn1nXLkFcsNvBTf8BCOg_4gWvLs9v2nsZvQf9KP7-hEg@mail.gmail.com>
 <Pine.LNX.4.64.1508162319280.734@whammy.cluebyfour.org>
Message-ID: <1ee181b06d9d4cce80d412b7de1b1a30@pur-vm-exch13n1.ox.com>

There is also the problem with multi-homed customers where Cogent is in the mix. The dropped packets at Cogent's peering points to eyeball networks break certain protocols that are packet loss sensitive (VoIP, IPSEC, etc...).


----
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 Justin M. Streiner
Sent: Sunday, August 16, 2015 11:27 PM
To: nanog at nanog.org
Subject: Re: Cogent revisited

On Wed, 12 Aug 2015, James Bensley wrote:

> Perhaps that depends on were are you in the world and your traffic types.
>
> I have worked with two UK ISPs that have Cogent as one of their
> transit providers, neither have had any problems in the 5+ years
> they've both had the Cogent transit, it has always "just worked".

And for the most part, that will be the case.  If you're multi-homed, it's 
really not a major issue.  It's more when someone is:
1. single-homed to Cogent and they get into a peering/transit/pay-us spat 
with one of the DFZ carriers, and Cogent gets de-peered. Single-homed 
customers of $de-peering_carrier disappear from your view of the Internet.
2. single-homed to one of said DFZ carriers and a peering/transit/pay-us 
spat arises with Cogent, and Cogent gets de-peered.  Single-homed customers
of Cogent's disappear from your view of the Internet.

jms

From lists at mtin.net  Mon Aug 17 14:51:34 2015
From: lists at mtin.net (Justin Wilson - MTIN)
Date: Mon, 17 Aug 2015 10:51:34 -0400
Subject: Drops in Core
In-Reply-To: <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
 <20150815174129.GJ72293@-.true.nl>
 <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
Message-ID: <C6BC6229-2D9E-4A6C-BEFA-D0961160592F@mtin.net>

I could see it going through several private peering, but not through multiple exchanges.  


Justin Wilson
j2sw at mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting ? Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman
Internet Exchange - Peering - Distributed Fabric




> On Aug 16, 2015, at 8:00 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> 
> On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
>> On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:
> 
>>> Is there a paper or a presentation that discusses the drops in the core?
>>> 
>>> If i were to break the total path into three legs -- the first, middle
>>> and the last, then are you saying that the probability of packet loss
>>> is perhaps 1/3 in each leg (because the packet passes through
>>> different IXes).
>> 
>> It is unlikely packets pass through an IXP more then once.
> 
> ?Unlikely?? That?s putting it mildly.
> 
> Unless someone is selling transit over an IX, I do not see how it can happen. And I would characterize transit over IXes far more pessimistically than ?unlikely?.
> 
> 
> [Combining responses]
> On Aug 15, 2015, at 1:21 PM, Owen DeLong <owen at delong.com> wrote:
>> 
>> I would say that the probability of a packet drop at any particular peering
>> point is less than the probability at one of the two edges.
>> 
>> However, given that most packets are likely to traverse multiple peering
>> points between the two edges, the probability of a packet drop along
>> the way at one of the several peering points overall is roughly equal
>> to the probability of a drop at one of the two edges.
> 
> I?m a little confused why most packets are ?likely to traverse multiple peering points??
> 
> Most packets these days are sourced from one of three companies. (Which Owen should know well. :) At least one of those companies published stats saying the vast majority of packets are ?zero or one? AS hop from the destination. I cannot imagine Google or Netflix being 50% behind Akamai on that stat. Which clearly implies most packets traverse ?zero or one? AS hop - i.e. one or zero peering points.
> 
> Finally, I would love to see data backing up the statement that packets are more likely to drop at one edge (assuming the destination?) than at a peering point.
> 
> -- 
> TTFN,
> patrick
> 

Justin Wilson
j2sw at mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting ? Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman
Internet Exchange - Peering - Distributed Fabric


From patrick at ianai.net  Mon Aug 17 15:47:28 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 17 Aug 2015 11:47:28 -0400
Subject: Drops in Core
In-Reply-To: <C6BC6229-2D9E-4A6C-BEFA-D0961160592F@mtin.net>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <CAP-guGW9r-sZwzxcOipcYEqmjcy_Y+qpf3kFPdJagerA9jMwyA@mail.gmail.com>
 <CAPLq3UNDsmXwooDjY7RaGJa8SqQ1b-PsO7V8W8W3ujs2LmgKsg@mail.gmail.com>
 <670F4AB7-F65B-4FA4-A2C3-C866B6EC8773@delong.com>
 <CAPLq3UMofQomwiWBZcgvnaEb1qfkRN=CPfrj7wZPUEiemvHGWg@mail.gmail.com>
 <20150815174129.GJ72293@-.true.nl>
 <571A31DB-4295-4872-AF6F-BA4280CD39A7@ianai.net>
 <C6BC6229-2D9E-4A6C-BEFA-D0961160592F@mtin.net>
Message-ID: <2FEE24EE-593F-4221-930A-B8353BD299A3@ianai.net>

Terms get over-used & overloaded in many cases. So it is difficult to tell if this is just a miscommunication, but I think I disagree with this statement.

?Private Peering? in the strictest sense is still peering. You do not have ?private peering? with your transit provider, even though the traffic goes over a dedicated link. As such, I do not see how a packet would go over multiple private peering - public or private - links except in a few corner cases such as the ones stated earlier in the thread.


Let?s consider a more general case. Assume a packet traverses several ASes:

      A -- B -- C -- D -- E

There should be no more than one peering relationship in that whole chain, if any. (Zero is a valid number as well.) If, for instance, B peers with C and C peers with D, then who is paying C to do ?work?, i.e. to transport packets through fibers & routers inside C's network? It doesn?t even work if B peers with C and D peers with E. Why would C pay D or vice versa when they are not paid on the other side?

The reason peering works is because each peer is paid, either by their own user or a downstream. When traffic goes over a network without being paid at either source or destination, something is wrong. Or worse, when a network pays to send traffic without being paid to receive it, or the reverse, things are very broken.

Even the corner cases still have people paying in some sense. In Bill?s example, networks giving free transit to schools, there is value traded. The ISP providing the service is either expecting more revenue from the school or revenue from others because they transit the school. In the case of a transit provider providing free transit to eyeballs in order to balance ratios, the value is the inbound demand. In Job?s example, you are paying both providers. Even though one has a de-aggregate link, the other is still getting paid. Etc., etc.

If each case, if the expected value does not materialize, the ISP will stop providing the service.


In summary: While there are exceptions to many (all?) rules, we are discussing generalities. And in general, companies who perform work without being paid tend not to last very long.

-- 
TTFN,
patrick

> On Aug 17, 2015, at 10:51 AM, Justin Wilson - MTIN <lists at mtin.net> wrote:
> 
> I could see it going through several private peering, but not through multiple exchanges.  
> 
> 
> Justin Wilson
> j2sw at mtin.net
> 
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting ? Data Centers - Bandwidth
> 
> http://www.midwest-ix.com  COO/Chairman
> Internet Exchange - Peering - Distributed Fabric
> 
> 
> 
> 
>> On Aug 16, 2015, at 8:00 AM, Patrick W. Gilmore <patrick at ianai.net> wrote:
>> 
>> On Aug 15, 2015, at 1:41 PM, Job Snijders <job at instituut.net> wrote:
>>> On Sat, Aug 15, 2015 at 11:01:56PM +0530, Glen Kent wrote:
>> 
>>>> Is there a paper or a presentation that discusses the drops in the core?
>>>> 
>>>> If i were to break the total path into three legs -- the first, middle
>>>> and the last, then are you saying that the probability of packet loss
>>>> is perhaps 1/3 in each leg (because the packet passes through
>>>> different IXes).
>>> 
>>> It is unlikely packets pass through an IXP more then once.
>> 
>> ?Unlikely?? That?s putting it mildly.
>> 
>> Unless someone is selling transit over an IX, I do not see how it can happen. And I would characterize transit over IXes far more pessimistically than ?unlikely?.
>> 
>> 
>> [Combining responses]
>> On Aug 15, 2015, at 1:21 PM, Owen DeLong <owen at delong.com> wrote:
>>> 
>>> I would say that the probability of a packet drop at any particular peering
>>> point is less than the probability at one of the two edges.
>>> 
>>> However, given that most packets are likely to traverse multiple peering
>>> points between the two edges, the probability of a packet drop along
>>> the way at one of the several peering points overall is roughly equal
>>> to the probability of a drop at one of the two edges.
>> 
>> I?m a little confused why most packets are ?likely to traverse multiple peering points??
>> 
>> Most packets these days are sourced from one of three companies. (Which Owen should know well. :) At least one of those companies published stats saying the vast majority of packets are ?zero or one? AS hop from the destination. I cannot imagine Google or Netflix being 50% behind Akamai on that stat. Which clearly implies most packets traverse ?zero or one? AS hop - i.e. one or zero peering points.
>> 
>> Finally, I would love to see data backing up the statement that packets are more likely to drop at one edge (assuming the destination?) than at a peering point.
>> 
>> -- 
>> TTFN,
>> patrick
>> 
> 
> Justin Wilson
> j2sw at mtin.net
> 
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting ? Data Centers - Bandwidth
> 
> http://www.midwest-ix.com  COO/Chairman
> Internet Exchange - Peering - Distributed Fabric


From morrowc.lists at gmail.com  Mon Aug 17 15:56:47 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 17 Aug 2015 11:56:47 -0400
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <CAC2aK2qWQta8aVqHhOuMEdhxA0gXieVAhvPRRZUwKv_d7ZOApg@mail.gmail.com>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
 <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
 <CAOLsBOvYyUCyTVzLtEY125aKs5Eh1gP4MNxRZr1HtURrq9cxPg@mail.gmail.com>
 <CAC2aK2qWQta8aVqHhOuMEdhxA0gXieVAhvPRRZUwKv_d7ZOApg@mail.gmail.com>
Message-ID: <CAL9jLaaC0+dMbFUpJLQPr1tdEbPLvzSR53=odagy=hc0gEAqmA@mail.gmail.com>

of course checkpoint.

On Mon, Aug 17, 2015 at 4:57 AM, Rakesh M <raaki.88 at gmail.com> wrote:
> Have a look below Ramy pdf
>
> https://www.sophos.com/en-us/medialibrary/PDFs/partners/sophos_complete_security_msps_dsna.pdf?la=en
>
>
>
> On Mon, Aug 17, 2015 at 12:59 PM, Ramy Hashish <ramy.ihashish at gmail.com>
> wrote:
>
>> Thank you Rakesh and Colin.
>>
>> I just want to amend something, "FW as a service" rather than "security as
>> a service".
>>
>> Are you sure sophos has such a solution?
>>
>> Thanks,
>>
>> Ramy
>>
>> On Mon, Aug 17, 2015 at 9:47 AM, Colin Johnston <colinj at gt86car.org.uk>
>> wrote:
>>
>>> sophos utm works great :)
>>>
>>> Colin
>>>
>>> > On 17 Aug 2015, at 05:56, Rakesh M <raaki.88 at gmail.com> wrote:
>>> >
>>> > I have seen one of our customers using Sophos and they are relatively
>>> happy
>>> > about it. Not directly experienced though.
>>> >
>>> > Thanks
>>> > Rakesh
>>> >
>>> > On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com
>>> >
>>> > wrote:
>>> >
>>> >> Hello All,
>>> >>
>>> >> We are planning to implement a multi-tenant FW/UTM and start providing
>>> >> security as a service, I would like to hear if anybody had experience
>>> on
>>> >> this, and if there are any recommendations for the UTM's vendor.
>>> >>
>>> >> People/customers here are more familiar with the Fortigate, however, we
>>> >> need to build a well-rounded solution that suits wide range of
>>> enterprises'
>>> >> business needs.
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Ramy
>>> >>
>>>
>>>
>>

From dave.taht at gmail.com  Mon Aug 17 16:53:34 2015
From: dave.taht at gmail.com (Dave Taht)
Date: Mon, 17 Aug 2015 18:53:34 +0200
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <20150817072728.GA24988@Mail.DDoS-Mitigator.net>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CAC2aK2o7666GsOcGd+zNFyKDadsrw4pZ5M=0oc3zwNMn-ght0Q@mail.gmail.com>
 <6E922826-DB47-4735-8099-D6D3037EA469@gt86car.org.uk>
 <20150817072728.GA24988@Mail.DDoS-Mitigator.net>
Message-ID: <CAA93jw7inN1DyH1tGqyV5j90siom9yqVznd3DP3LoR=_XnH0GQ@mail.gmail.com>

On Mon, Aug 17, 2015 at 9:27 AM, alvin nanog
<nanogml at mail.ddos-mitigator.net> wrote:
>
> hi
>
>> On Mon, Aug 17, 2015 at 10:16 AM, Ramy Hashish <ramy.ihashish at gmail.com>
>> wrote:
>>
>> We are planning to implement a multi-tenant FW/UTM and start providing
>> security as a service, I would like to hear if anybody had experience on
>
> that'd be a good thing ... but ...
>
>> this, and if there are any recommendations for the UTM's vendor.
>
> the possible vendors would depend on the answers to your idea of
> what is "well rounded solution"
>
>         # fortinet's (possible) competitors
>         http://ddos-Mitigator.net/Competitors
>
>> People/customers here are more familiar with the Fortigate, however, we
>> need to build a well-rounded solution that suits wide range of enterprises'
>> business needs.
>
> # i doubt there is one product that provides the "well rounded solution"
>
> in my world, "well rounded solution" would imply at least the following:
> - anti virus solution  ( one or more products to resolve the virus issue )
> - anti spam solution  ( one or more products to resolve the spam issue )
> - iptables with tarpit ( protect against the free tcp-based script kiddies tests )
> - udp limiting at isp ( part of iptables or your edge routers )
> - icmp limiting at isp ( part of iptables or your edge routers )
> - ingress/egress filters for your downlinks
> - geographically distributed colo to mitigate small/medium sized ddos attacks
> - regulatory compliance this and certified that vs "just anybody" ...
> - good response time to fix problems reported by competent customer's IT folks
> - other things you deem important to provide ..

+ Good AQM and queue management

Sophos has fq_codel. /me happy.
> pixie dust
> alvin
> #
> # ddos-Mitigator.net
> # ddos-Simulator.net
>



-- 
Dave T?ht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

From swhyte at gmail.com  Mon Aug 17 17:44:43 2015
From: swhyte at gmail.com (Scott Whyte)
Date: Mon, 17 Aug 2015 10:44:43 -0700
Subject: Drops in Core
In-Reply-To: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
Message-ID: <55D21D8B.9040205@gmail.com>



On 8/15/15 09:47, Glen Kent wrote:
> Hi,
>
> Is it fair to say that most traffic drops happen in the access layers, or
> the first and the last miles, and the % of packet drops in the core are
> minimal? So, if the packet has made it past the first mile and has
> "entered" the core then chances are high that the packet will safely get
> across till the exit in the core. Sure once it gets off the core, then all
> bets are off on whether it will get dropped or not. However, the key point
> is that the core usually does not drop too many packets - the probability
> of drops are highest in the access side.

What do these terms mean in a world where my EC2 VM talks to my GCE VM? 
  It doesn't seem unreasonable that the DC bandwidth on either end 
dwarfs the "core" capacity between the two.

>
> Is this correct?
>
> Glen
>

From morrowc.lists at gmail.com  Tue Aug 18 02:38:47 2015
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 17 Aug 2015 22:38:47 -0400
Subject: Drops in Core
In-Reply-To: <55D21D8B.9040205@gmail.com>
References: <CAPLq3UNEG+CNEns8Ciu35j5UMtp=LDHJ2RnaQM2qkv6WXqdLzg@mail.gmail.com>
 <55D21D8B.9040205@gmail.com>
Message-ID: <CAL9jLab3HLg6npzi4tkh-+DS=4hXJgEd=pWwyg60DPJokdmruw@mail.gmail.com>

On Mon, Aug 17, 2015 at 1:44 PM, Scott Whyte <swhyte at gmail.com> wrote:
>
>
> On 8/15/15 09:47, Glen Kent wrote:
>>
>> Hi,
>>
>> Is it fair to say that most traffic drops happen in the access layers, or
>> the first and the last miles, and the % of packet drops in the core are
>> minimal? So, if the packet has made it past the first mile and has
>> "entered" the core then chances are high that the packet will safely get
>> across till the exit in the core. Sure once it gets off the core, then all
>> bets are off on whether it will get dropped or not. However, the key point
>> is that the core usually does not drop too many packets - the probability
>> of drops are highest in the access side.
>
>
> What do these terms mean in a world where my EC2 VM talks to my GCE VM?  It
> doesn't seem unreasonable that the DC bandwidth on either end dwarfs the
> "core" capacity between the two.

there's some other work going on:
  <http://www.bitag.org/documents/BITAG_Press_Release_-_Announcing_Prioritization_and_Differential_Treatment_Topic.pdf>

which pokes a bit at this idea of packet drops (from the 'what if I
prioritize traffic? or differentiate between traffic types?'
perspective). I imagine that a topic of conversation is that: "hey, do
we get meaningful drop numbers, or does prioritization/differentiation
matter, in the core of a network or only at the network edges?"

mostly bitag is focused on 'consumer' edges, so they may not look at
'inside a a datacenter' problems.

From tdurack at gmail.com  Tue Aug 18 12:29:31 2015
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 18 Aug 2015 08:29:31 -0400
Subject: Peering + Transit Circuits
Message-ID: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>

Question: What is the preferred practice for separating peering and transit
circuits?

1. Terminate peering and transit on separate routers.
2. Terminate peering and transit circuits in separate VRFs.
3. QoS/QPPB (
https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
)
4. Don't worry about peers stealing transit.
5. What is peering?

Your comments are appreciated.

-- 
Tim:>

From jared at puck.nether.net  Tue Aug 18 13:01:53 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 18 Aug 2015 09:01:53 -0400
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <20150818124747.GG34798@greenie.muc.de>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <20150818124747.GG34798@greenie.muc.de>
Message-ID: <7D87295B-88AC-47E7-85FE-CFB6BFB12923@puck.nether.net>


> On Aug 18, 2015, at 8:47 AM, Gert Doering <gert at greenie.muc.de> wrote:
> 
> XR doesn't do it at all,
> hrmph)
> 

We have been asking about this as well, it might be worth revisiting.

- Jared

From tdurack at gmail.com  Tue Aug 18 13:31:03 2015
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 18 Aug 2015 09:31:03 -0400
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <20150818124747.GG34798@greenie.muc.de>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <20150818124747.GG34798@greenie.muc.de>
Message-ID: <CAE_ug16-UwTedYV63K=6QY4VtMyPRCUZgd3MeVUTDRqprpMQiA@mail.gmail.com>

On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering <gert at greenie.muc.de> wrote:

> Hi,
>
> On Tue, Aug 18, 2015 at 08:29:31AM -0400, Tim Durack wrote:
> > 4. Don't worry about peers stealing transit.
> > 5. What is peering?
>
> I'm afraid that the majority of answers will be 4./5., mixed with
> "6. what? how can peers stell my transit?!"
>
> We're somewhat into the "we'll notice if there is surprisingly high
> inbound traffic on peering, and then we'll find the peer, and apply
> appropriate measures" camp... (since we're a hosting shop, we have mostly
> outgoing traffic, so "significant" amounts of incomnig traffic stick
> out).
>
> But yeah, something more strict might be in order.
>

Thanks for the response. This is what I was guessing.

We currently do "2. Terminate peering and transit circuits in separate
VRFs." which works well when everything is a VRF but comes at the cost of
higher resource usage (RIB & FIB.)

I was thinking a creative solution might be:

"7. DSCP mark packets on peering ingress, police on transit egress."

Not sure if I really want to get into using DSCP bits for basic IP service
though.


> (It would be cool if Cisco would understand that hardware forwarding
> platforms need useful netflow with MAC-addresses in there...  ASR9k at
> least got working MAC-accounting, but more fine grained telemetry would
> certainly be appreciated.  Software IOS can do it, Sup720 cannot do it
> due to hardware constraints, Sup2T exports MAC addresses taken from random
> caches in the system but not the inbound packets, XR doesn't do it at all,
> hrmph)


> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
>                                                            //
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> gert at greenie.muc.de
> fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
>



-- 
Tim:>

From tdurack at gmail.com  Tue Aug 18 13:32:53 2015
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 18 Aug 2015 09:32:53 -0400
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <20150818124747.GG34798@greenie.muc.de>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <20150818124747.GG34798@greenie.muc.de>
Message-ID: <CAE_ug14LM_Ev_MkK_OAO_MtY8A==BY7Goa=02+oYSvi2n8d=yw@mail.gmail.com>

On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering <gert at greenie.muc.de> wrote:

> Hi,
>
> (It would be cool if Cisco would understand that hardware forwarding
> platforms need useful netflow with MAC-addresses in there...  ASR9k at
> least got working MAC-accounting, but more fine grained telemetry would
> certainly be appreciated.  Software IOS can do it, Sup720 cannot do it
> due to hardware constraints, Sup2T exports MAC addresses taken from random
> caches in the system but not the inbound packets, XR doesn't do it at all,
> hrmph)
>

At the risk of introducing religion, I will mention sFlow...

-- 
Tim:>

From rsk at gsp.org  Tue Aug 18 13:41:59 2015
From: rsk at gsp.org (Rich Kulawiec)
Date: Tue, 18 Aug 2015 09:41:59 -0400
Subject: Data Center operations mail list?
In-Reply-To: <55CBE688.20802@daa.com.au>
References: <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <ximss-516184@mail.ropeguru.com>
 <CAJB2g-GiaBNFS6gqKRppZ8hBzL5NvtTAD60Sz7bsk-3WR3krUg@mail.gmail.com>
 <55CBE688.20802@daa.com.au>
Message-ID: <20150818134159.GA26130@gsp.org>

On Thu, Aug 13, 2015 at 08:36:24AM +0800, Phill Twiss wrote:
> 	You should really have captcha's configured for your mailman lists

No.  In fact: hell no.  Captchas have zero security value and serve only
to annoy and waste the time of legitimate users.  Far less intrusive
and more effective measures suffice nicely, e.g., deploying the DROP
list in the firewall defending the Mailman instance.

---rsk

From tdurack at gmail.com  Tue Aug 18 13:44:34 2015
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 18 Aug 2015 09:44:34 -0400
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <20150818133817.GH34798@greenie.muc.de>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <20150818124747.GG34798@greenie.muc.de>
 <CAE_ug14LM_Ev_MkK_OAO_MtY8A==BY7Goa=02+oYSvi2n8d=yw@mail.gmail.com>
 <20150818133817.GH34798@greenie.muc.de>
Message-ID: <CAE_ug16LTaJZGAarxTo3-_Xz8hyf21Od2obD-3PmPDD_w4hj4w@mail.gmail.com>

On Tue, Aug 18, 2015 at 9:38 AM, Gert Doering <gert at greenie.muc.de> wrote:

> Hi,
>
> On Tue, Aug 18, 2015 at 09:32:53AM -0400, Tim Durack wrote:
> > > (It would be cool if Cisco would understand that hardware forwarding
> > > platforms need useful netflow with MAC-addresses in there...  ASR9k at
> [..]
> > At the risk of introducing religion, I will mention sFlow...
>
> Yes... and this is helping exactly why...?  Given the overwhelming
> support for sFlow in (Cisco-) hardware routers used as peering edge?  :-)


I ask Cisco for sFlow support on a regular basis. Cisco typically respond
with some variation of NIH syndrome. Anyway, back to my question :-)

-- 
Tim:>

From tdurack at gmail.com  Tue Aug 18 13:58:17 2015
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 18 Aug 2015 09:58:17 -0400
Subject: Fwd: [c-nsp] Peering + Transit Circuits
In-Reply-To: <CAE_ug17=W=ho-GGtv9de+BT3Vg2sqEJku55LvYVgj3ni1EQ6kg@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <6ef38e16adf6865dae7ce5da0e9cea91.squirrel@mail.tawp.de>
 <CAE_ug17=W=ho-GGtv9de+BT3Vg2sqEJku55LvYVgj3ni1EQ6kg@mail.gmail.com>
Message-ID: <CAE_ug17kC48rmPmLKi-mX0Te5wha881GrqkxXTNArxq0dm3z9g@mail.gmail.com>

---------- Forwarded message ----------
From: Tim Durack <tdurack at gmail.com>
Date: Tue, Aug 18, 2015 at 9:53 AM
Subject: Re: [c-nsp] Peering + Transit Circuits
To: Rolf Han?en <nsp at rhanssen.de>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>


On Tue, Aug 18, 2015 at 9:45 AM, "Rolf Han?en" <nsp at rhanssen.de> wrote:

> Hi,
>
> you forgot "do some interface-ACL-magic that drops peer-traffic that does
> not have a destination IP in my cool-networks-whitelist".
>

Yup, valid option. I am trying to avoid anything that involves maintaining
lists.

-- 
Tim:>

From tdurack at gmail.com  Tue Aug 18 16:02:48 2015
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 18 Aug 2015 12:02:48 -0400
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <7029C38A-B3D9-4D23-A876-5266EE63B309@granados-llc.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <7029C38A-B3D9-4D23-A876-5266EE63B309@granados-llc.net>
Message-ID: <CAE_ug15tWxr_wE4SnGxoqiTec9brG_xqDLbjzakXy1fqB5aM8A@mail.gmail.com>

On Tue, Aug 18, 2015 at 11:25 AM, Scott Granados <scott at granados-llc.net>
wrote:

> So in our case we terminate peering and transit on different routers.
> Peering routers have well flow enabled (the one that starts with a J that?s
> inline).  With NFSEN / NFDUMP we?re able to collect that flow data and look
> for anomalous flows or other issues. We pretty much detect and then deal
> with peering issues rather than prevent them with whitelists and so forth
> but then again we?ve been lucky and not experienced to many issues other
> than the occasional leakage of prefixes and such which maxprefix handles
> nicely.
>
>
Can I ask why you terminate peering and transit on different routers? (Not
suggesting that is bad, just trying to understand the reason.)

Tim:>

From jlmcgraw at gmail.com  Tue Aug 18 17:04:36 2015
From: jlmcgraw at gmail.com (Jesse McGraw)
Date: Tue, 18 Aug 2015 13:04:36 -0400
Subject: A perl script to find IP and network addresses in a text file (config, 
 ACL, etc) and annotate them with various bits of information
Message-ID: <55D365A4.8050308@gmail.com>

(This is me scratching an itch of my own and hoping that it might be 
useful to others on this list.  Apologies if it isn't)

All,
    I was working my way through a very long ACL, trying to clean out 
old cruft, and I found myself thinking that surely I could make this 
somewhat easier.

So, I wrote a small script that will go through a text file(or files), 
find anything that looks like a host IP or subnet (with subnet mask, 
wildcard mask, or mask length), dig up information about them (DNS name, 
ping responsiveness, host count etc) and then spit out an HTML version 
of the input file with color coded info.

General info is blue
Hosts that are reachable and networks that have a specific route are 
GREEN (see networks note below)
Hosts that are non-responsive and networks that use default route are RED

Individual script is: 
https://github.com/jlmcgraw/networkUtilities/blob/master/annotate_hosts_and_networks_in_file.pl
Repository is:  https://github.com/jlmcgraw/networkUtilities

To get the whole repository:

     git clone https://github.com/jlmcgraw/networkUtilities.git

This repository includes the necessary modules for this script and some 
other small utilities that network folks might be interested in

(If for some reason included modules don't work for you see setup.sh for 
easy ways to install them under Debian-derived Linux. I've tested the 
script under Linux and Windows, but not OS X)

Please let me know if you use this utility and encounter anything that 
doesn't work right.  I'm also interested in incorporating any 
changes/improvements so feel free to send a pull request!

-Jesse


Note:
     If you've got a BGP speaking router that you can query via SNMP, 
you should be able to use bgp_asn_path_via_snmp.pl 
<https://github.com/jlmcgraw/networkUtilities/blob/master/bgp_asn_path_via_snmp.pl> 
to create a table of known routes to use along with this utility

From mel at beckman.org  Tue Aug 18 17:09:31 2015
From: mel at beckman.org (Mel Beckman)
Date: Tue, 18 Aug 2015 17:09:31 +0000
Subject: A perl script to find IP and network addresses in a text file
 (config,  ACL, etc) and annotate them with various bits of information
In-Reply-To: <55D365A4.8050308@gmail.com>
References: <55D365A4.8050308@gmail.com>
Message-ID: <BN1PR07MB950BB871843FC8BFEC78B24A7780@BN1PR07MB950.namprd07.prod.outlook.com>

Sweet! Ill try this out this week for a similar router migration project I have.

________________________________________
From: NANOG <nanog-bounces at nanog.org> on behalf of Jesse McGraw <jlmcgraw at gmail.com>
Sent: Tuesday, August 18, 2015 10:04 AM
To: nanog at nanog.org
Subject: A perl script to find IP and network addresses in a text file (config,  ACL, etc) and annotate them with various bits of information

(This is me scratching an itch of my own and hoping that it might be
useful to others on this list.  Apologies if it isn't)

All,
    I was working my way through a very long ACL, trying to clean out
old cruft, and I found myself thinking that surely I could make this
somewhat easier.

So, I wrote a small script that will go through a text file(or files),
find anything that looks like a host IP or subnet (with subnet mask,
wildcard mask, or mask length), dig up information about them (DNS name,
ping responsiveness, host count etc) and then spit out an HTML version
of the input file with color coded info.

General info is blue
Hosts that are reachable and networks that have a specific route are
GREEN (see networks note below)
Hosts that are non-responsive and networks that use default route are RED

Individual script is:
https://github.com/jlmcgraw/networkUtilities/blob/master/annotate_hosts_and_networks_in_file.pl
Repository is:  https://github.com/jlmcgraw/networkUtilities

To get the whole repository:

     git clone https://github.com/jlmcgraw/networkUtilities.git

This repository includes the necessary modules for this script and some
other small utilities that network folks might be interested in

(If for some reason included modules don't work for you see setup.sh for
easy ways to install them under Debian-derived Linux. I've tested the
script under Linux and Windows, but not OS X)

Please let me know if you use this utility and encounter anything that
doesn't work right.  I'm also interested in incorporating any
changes/improvements so feel free to send a pull request!

-Jesse


Note:
     If you've got a BGP speaking router that you can query via SNMP,
you should be able to use bgp_asn_path_via_snmp.pl
<https://github.com/jlmcgraw/networkUtilities/blob/master/bgp_asn_path_via_snmp.pl>
to create a table of known routes to use along with this utility

From bill at herrin.us  Tue Aug 18 17:24:12 2015
From: bill at herrin.us (William Herrin)
Date: Tue, 18 Aug 2015 13:24:12 -0400
Subject: Peering + Transit Circuits
In-Reply-To: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
Message-ID: <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>

On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack <tdurack at gmail.com> wrote:
> Question: What is the preferred practice for separating peering and transit
> circuits?
>
> 1. Terminate peering and transit on separate routers.
> 2. Terminate peering and transit circuits in separate VRFs.
> 3. QoS/QPPB (
> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
> )
> 4. Don't worry about peers stealing transit.
> 5. What is peering?
>
> Your comments are appreciated.


If you have a small number of peers, a separate router carrying a
partial table works really well.



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From patrick at ianai.net  Tue Aug 18 17:29:35 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 18 Aug 2015 13:29:35 -0400
Subject: Peering + Transit Circuits
In-Reply-To: <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
Message-ID: <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>

On Aug 18, 2015, at 1:24 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack <tdurack at gmail.com> wrote:

>> Question: What is the preferred practice for separating peering and transit
>> circuits?
>> 
>> 1. Terminate peering and transit on separate routers.
>> 2. Terminate peering and transit circuits in separate VRFs.
>> 3. QoS/QPPB (
>> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
>> )
>> 4. Don't worry about peers stealing transit.
>> 5. What is peering?
>> 
>> Your comments are appreciated.
> 
> 
> If you have a small number of peers, a separate router carrying a
> partial table works really well.

To expand on this, and answer Tim?s question one post up in the thread:

Putting all peer routes on a dedicated router with a partial table avoids the ?steal transit? question. The Peering router can only speak to peers and your own network. Anyone dumping traffic on it will get !N (unless they are going to a peer, which is a pretty minimal risk).

It has lots of other useful features such as network management and monitoring. It lets you do maintenance much easier. Etc., etc.

But mostly, it lets you avoid joining an IX and having people use you as a backup transit provider.

-- 
TTFN,
patrick


From eugen at imacandi.net  Tue Aug 18 17:38:34 2015
From: eugen at imacandi.net (Eugeniu Patrascu)
Date: Tue, 18 Aug 2015 20:38:34 +0300
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
Message-ID: <CALgc3C6gtwvXWTuaCxg2wOnwEwZPKbnNF8zDyAa_xfqNfo1gVA@mail.gmail.com>

On Mon, Aug 17, 2015 at 7:46 AM, Ramy Hashish <ramy.ihashish at gmail.com>
wrote:

> Hello All,
>
> We are planning to implement a multi-tenant FW/UTM and start providing
> security as a service, I would like to hear if anybody had experience on
> this, and if there are any recommendations for the UTM's vendor.
>

Check Point VS might be a good fit. Also there is McAfee NGFW that can be
used as a multi-tenant solution.

Other solutions are Fortigate (what you mentioned), ASA w/ contexts (not
sure about UTM support in contexts though).


> People/customers here are more familiar with the Fortigate, however, we
> need to build a well-rounded solution that suits wide range of enterprises'
> business needs.
>

I think that you first define what the most wanted needs of your clients
are and work from that.

From shawnl at up.net  Tue Aug 18 17:39:28 2015
From: shawnl at up.net (Shawn L)
Date: Tue, 18 Aug 2015 13:39:28 -0400 (EDT)
Subject: Google Apps for ISPs -- Lingering fallout
Message-ID: <1439919568.192219773@upnet.mymailsrvr.com>


I know there are others on this list who used Google Apps for ISPs and recently migrated off (as the service was discontinued).
 
We have had several cases where the user had a YouTube channel or Picasa photo albums, etc. that they created with their Google Apps for ISPs credentials.  Now that the service is gone, those channels and albums still exist but the users are unable to login to them or manage them in any way because it tells them that their account has been disabled.
 
Of course, Google had been un-responsive to all of our (and the customer's) inquiries about how to fix this.
 
Has anyone else run into this and found a way around it?
 
thanks
 
 
Shawn
 

From tdurack at gmail.com  Tue Aug 18 19:22:48 2015
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 18 Aug 2015 15:22:48 -0400
Subject: Peering + Transit Circuits
In-Reply-To: <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
 <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
Message-ID: <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>

On Tue, Aug 18, 2015 at 1:29 PM, Patrick W. Gilmore <patrick at ianai.net>
wrote:

> On Aug 18, 2015, at 1:24 PM, William Herrin <bill at herrin.us> wrote:
> > On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack <tdurack at gmail.com> wrote:
>
> >> Question: What is the preferred practice for separating peering and
> transit
> >> circuits?
> >>
> >> 1. Terminate peering and transit on separate routers.
> >> 2. Terminate peering and transit circuits in separate VRFs.
> >> 3. QoS/QPPB (
> >>
> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
> >> )
> >> 4. Don't worry about peers stealing transit.
> >> 5. What is peering?
> >>
> >> Your comments are appreciated.
> >
> >
> > If you have a small number of peers, a separate router carrying a
> > partial table works really well.
>
> To expand on this, and answer Tim?s question one post up in the thread:
>
> Putting all peer routes on a dedicated router with a partial table avoids
> the ?steal transit? question. The Peering router can only speak to peers
> and your own network. Anyone dumping traffic on it will get !N (unless they
> are going to a peer, which is a pretty minimal risk).
>
> It has lots of other useful features such as network management and
> monitoring. It lets you do maintenance much easier. Etc., etc.
>
> But mostly, it lets you avoid joining an IX and having people use you as a
> backup transit provider.
>

This has always been my understanding - thanks for confirming. I'm weighing
cost-benefit, and looking to see if there are any other smart ideas. As
usual, it looks like simplest is best.

-- 
Tim:>

p.s. Perhaps I should be relieved no one tried to sell me an SDN peering
transit theft controller...

From ikiris at gmail.com  Tue Aug 18 19:32:09 2015
From: ikiris at gmail.com (Blake Dunlap)
Date: Tue, 18 Aug 2015 12:32:09 -0700
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <CALgc3C6gtwvXWTuaCxg2wOnwEwZPKbnNF8zDyAa_xfqNfo1gVA@mail.gmail.com>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CALgc3C6gtwvXWTuaCxg2wOnwEwZPKbnNF8zDyAa_xfqNfo1gVA@mail.gmail.com>
Message-ID: <CAJvB4tn2rjN+DzFnAiBjTrRjNG_+No9DS=eYbwWSObvaKUREYQ@mail.gmail.com>

Since no one else has mentioned it, I'll dive on that fire.

Be careful when setting up a multi-tenant security solution that you
are not accidentally selling "DoS as a Service" to your clients. State
is evil, and state sharing with other targets is dangerous. Target
sharing with other targets that are outsourcing their security can get
increasingly scary especially if one of these clients is a juicy
target. Make sure you have the infrastructure in place to quickly
isolate your clients so that they do not fate share if they become in
the focus of DoS attacks. This can mean isolated infrastructure for
those you wish to keep up, or sacrificial infrastructure for those you
are willing to let drop for the greater good.

-Blake

On Tue, Aug 18, 2015 at 10:38 AM, Eugeniu Patrascu <eugen at imacandi.net> wrote:
> On Mon, Aug 17, 2015 at 7:46 AM, Ramy Hashish <ramy.ihashish at gmail.com>
> wrote:
>
>> Hello All,
>>
>> We are planning to implement a multi-tenant FW/UTM and start providing
>> security as a service, I would like to hear if anybody had experience on
>> this, and if there are any recommendations for the UTM's vendor.
>>
>
> Check Point VS might be a good fit. Also there is McAfee NGFW that can be
> used as a multi-tenant solution.
>
> Other solutions are Fortigate (what you mentioned), ASA w/ contexts (not
> sure about UTM support in contexts though).
>
>
>> People/customers here are more familiar with the Fortigate, however, we
>> need to build a well-rounded solution that suits wide range of enterprises'
>> business needs.
>>
>
> I think that you first define what the most wanted needs of your clients
> are and work from that.

From dave-nanog at pooserville.com  Tue Aug 18 19:50:17 2015
From: dave-nanog at pooserville.com (Dave Pooser)
Date: Tue, 18 Aug 2015 15:50:17 -0400
Subject: rDNS delegation process question
Message-ID: <D1F904B9.3442BD%dave-nanog@pooserville.com>

At $DAYJOB we have a /24 of PA space that we were allocated by Airband,
and when the account was set up they delegated authoritative reverse DNS
to our DNS hosting provider. This is 69.26.223.0/24, in ARIN address space.

Now, almost a decade later Airband has been acquired by somebody or other
who was in turn acquired by GTT.net; we're trying to move our rDNS to
Route53 and nobody at GTT.net seems to know how they would go about
changing that rDNS delegation. My involvement with the process back in the
day was limited to "provide Airband with the name servers we would like to
be authoritative for the reverse DNS and wait about 12 hours for them to
handle the ticket." Now I'm trying to help my GTT contact get pointed in
the right direction, and any assistance would be appreciated.
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com



From joquendo at e-fensive.net  Tue Aug 18 19:48:36 2015
From: joquendo at e-fensive.net (J. Oquendo)
Date: Tue, 18 Aug 2015 14:48:36 -0500
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <CAJvB4tn2rjN+DzFnAiBjTrRjNG_+No9DS=eYbwWSObvaKUREYQ@mail.gmail.com>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CALgc3C6gtwvXWTuaCxg2wOnwEwZPKbnNF8zDyAa_xfqNfo1gVA@mail.gmail.com>
 <CAJvB4tn2rjN+DzFnAiBjTrRjNG_+No9DS=eYbwWSObvaKUREYQ@mail.gmail.com>
Message-ID: <20150818194836.GA74875@e-fensive.net>

On Tue, 18 Aug 2015, Blake Dunlap wrote:

> Since no one else has mentioned it, I'll dive on that fire.
> 
> Be careful when setting up a multi-tenant security solution that you
> are not accidentally selling "DoS as a Service" to your clients. State
> is evil, and state sharing with other targets is dangerous. Target
> sharing with other targets that are outsourcing their security can get
> increasingly scary especially if one of these clients is a juicy
> target. Make sure you have the infrastructure in place to quickly
> isolate your clients so that they do not fate share if they become in
> the focus of DoS attacks. This can mean isolated infrastructure for
> those you wish to keep up, or sacrificial infrastructure for those you
> are willing to let drop for the greater good.
> 
> -Blake
> 

Unsure what you meant by this. In a multi-tenant firewall
implementation (as far as I envision it), all tenants would
occupy different IP space so I don't get how any of the
state sessions would be affected. I'd be more concerned
with not enough sockets. 

Palo Alto has a virtual system set up built specifically
for this:

https://www.paloaltonetworks.com/products/features/virtual-systems.html

Now if only they'd send me free firewalls for marketing
them.

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama

0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

From jake at nobistech.net  Tue Aug 18 19:53:07 2015
From: jake at nobistech.net (Jake Mertel)
Date: Tue, 18 Aug 2015 12:53:07 -0700
Subject: rDNS delegation process question
In-Reply-To: <D1F904B9.3442BD%dave-nanog@pooserville.com>
References: <D1F904B9.3442BD%dave-nanog@pooserville.com>
Message-ID: <CAOhg=RzfoS=Dtzs5zyLc4a=saJ15OD8XXze_2taNt=kcetN6hA@mail.gmail.com>

Someone needs to update the delegation at ARIN since they are the
authoritative root for 69/8.
http://whois.arin.net/rest/rdns/223.26.69.in-addr.arpa shows that the
current nameservers are OAK.FOREST.NET and WILLOW.FOREST.NET. If I recall
correctly, the ARIN Online interface allows the registered administrative
and technical POC to make these adjustments directly from the interface. As
it stands right now, it would appear that whomever has access to
netops at alfordmedia.com,. noc at airband.com, or an associated POC would need
to use the appropriate ARIN template or interface to make the change.





--
Regards,

Jake Mertel
Nobis Technology Group, LLC



*Web: *http://www.nobistech.net
*Phone: *1-480-212-1710
*Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054



On Tue, Aug 18, 2015 at 12:50 PM, Dave Pooser <dave-nanog at pooserville.com>
wrote:

> At $DAYJOB we have a /24 of PA space that we were allocated by Airband,
> and when the account was set up they delegated authoritative reverse DNS
> to our DNS hosting provider. This is 69.26.223.0/24, in ARIN address
> space.
>
> Now, almost a decade later Airband has been acquired by somebody or other
> who was in turn acquired by GTT.net; we're trying to move our rDNS to
> Route53 and nobody at GTT.net seems to know how they would go about
> changing that rDNS delegation. My involvement with the process back in the
> day was limited to "provide Airband with the name servers we would like to
> be authoritative for the reverse DNS and wait about 12 hours for them to
> handle the ticket." Now I'm trying to help my GTT contact get pointed in
> the right direction, and any assistance would be appreciated.
> --
> Dave Pooser
> Cat-Herder-in-Chief, Pooserville.com
>
>
>

From nick at foobar.org  Tue Aug 18 20:43:47 2015
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 18 Aug 2015 21:43:47 +0100
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
 <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
 <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>
Message-ID: <55D39903.6050009@foobar.org>

On 18/08/2015 20:22, Tim Durack wrote:
> This has always been my understanding - thanks for confirming. I'm weighing
> cost-benefit, and looking to see if there are any other smart ideas. As
> usual, it looks like simplest is best.

i'd advise being careful with this approach: urpf at ixps is a nightmare.

If you're concerned about transit / peering theft on a shared l2 ixp style
fabric, you're far better to use bilateral-only peering with ingress l2
filters at the ixp interface to include or exclude other participants as
required.  This will stop the problem dead in the water with no side effects.

Nick


From dave-nanog at pooserville.com  Tue Aug 18 20:47:11 2015
From: dave-nanog at pooserville.com (Dave Pooser)
Date: Tue, 18 Aug 2015 16:47:11 -0400
Subject: rDNS delegation process question
In-Reply-To: <CAOhg=RzfoS=Dtzs5zyLc4a=saJ15OD8XXze_2taNt=kcetN6hA@mail.gmail.com>
References: <D1F904B9.3442BD%dave-nanog@pooserville.com>
 <CAOhg=RzfoS=Dtzs5zyLc4a=saJ15OD8XXze_2taNt=kcetN6hA@mail.gmail.com>
Message-ID: <D1F911BF.344304%dave-lists@pooserville.com>

On 8/18/15, 3:53 PM, "Jake Mertel" <jake at nobistech.net> wrote:

>Someone needs to update the delegation at ARIN since they are the
>authoritative root for 69/8.
>http://whois.arin.net/rest/rdns/223.26.69.in-addr.arpa shows that the
>current nameservers are OAK.FOREST.NET <http://OAK.FOREST.NET> and
>WILLOW.FOREST.NET <http://WILLOW.FOREST.NET>. If I recall correctly, the
>ARIN Online interface allows the registered administrative and technical
>POC to make these adjustments directly from the interface. As it stands
>right now, it would appear that whomever has access to
>netops at alfordmedia.com,. noc at airband.com, or an associated POC would need
>to use the appropriate ARIN template or interface to make the change.

That definitely gets me pointed in the right direction. Tasty $BEVERAGE, I
owe you a few...
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com



From nick at foobar.org  Tue Aug 18 21:00:41 2015
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 18 Aug 2015 22:00:41 +0100
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <20150818205651.GK34798@greenie.muc.de>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
 <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
 <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>
 <55D39903.6050009@foobar.org> <20150818205651.GK34798@greenie.muc.de>
Message-ID: <55D39CF9.7040407@foobar.org>

On 18/08/2015 21:56, Gert Doering wrote:
> So how's that stopping one of your bilateral peers from sending you
> traffic destined elsewhere?

it doesn't: you detect it and depeer them.  If they force the situation
with static routes, the traffic will be dropped.

Nick




From bill at herrin.us  Tue Aug 18 21:10:00 2015
From: bill at herrin.us (William Herrin)
Date: Tue, 18 Aug 2015 17:10:00 -0400
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <55D39903.6050009@foobar.org>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
 <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
 <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>
 <55D39903.6050009@foobar.org>
Message-ID: <CAP-guGU54m5e_bb2UgKnbgiJk314V3VfNkD44vF3L5g_LTJMgg@mail.gmail.com>

On Tue, Aug 18, 2015 at 4:43 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 18/08/2015 20:22, Tim Durack wrote:
>> This has always been my understanding - thanks for confirming. I'm weighing
>> cost-benefit, and looking to see if there are any other smart ideas. As
>> usual, it looks like simplest is best.
>
> i'd advise being careful with this approach: urpf at ixps is a nightmare.

Hi Nick,

This technique described isn't URPF, it's simple destination routing.
The routes I offer you via BGP are the only routes in my table, hence
the only routes I'm capable of routing. If you send me a packet for a
_destination_ I didn't offer to you, I can't route it.

URPF is the opposite of that. I'll only accept packets from you with a
_source_ address which is included in the routes you sent to me.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From edward.dore at freethought-internet.co.uk  Tue Aug 18 21:30:28 2015
From: edward.dore at freethought-internet.co.uk (Edward Dore)
Date: Tue, 18 Aug 2015 22:30:28 +0100
Subject: A multi-tenant firewall for an MSSP
In-Reply-To: <20150818194836.GA74875@e-fensive.net>
References: <CAOLsBOsdjgGyfQG5AGkkm7QC8eUX-e5xbkwBc8rZLeYYjh7x_Q@mail.gmail.com>
 <CALgc3C6gtwvXWTuaCxg2wOnwEwZPKbnNF8zDyAa_xfqNfo1gVA@mail.gmail.com>
 <CAJvB4tn2rjN+DzFnAiBjTrRjNG_+No9DS=eYbwWSObvaKUREYQ@mail.gmail.com>
 <20150818194836.GA74875@e-fensive.net>
Message-ID: <A1C1C48C-FC2F-48D4-8C31-351FDD7EB11C@freethought-internet.co.uk>

On 18 Aug 2015, at 20:48, J. Oquendo <joquendo at e-fensive.net> wrote:

> On Tue, 18 Aug 2015, Blake Dunlap wrote:
> 
>> Since no one else has mentioned it, I'll dive on that fire.
>> 
>> Be careful when setting up a multi-tenant security solution that you
>> are not accidentally selling "DoS as a Service" to your clients. State
>> is evil, and state sharing with other targets is dangerous. Target
>> sharing with other targets that are outsourcing their security can get
>> increasingly scary especially if one of these clients is a juicy
>> target. Make sure you have the infrastructure in place to quickly
>> isolate your clients so that they do not fate share if they become in
>> the focus of DoS attacks. This can mean isolated infrastructure for
>> those you wish to keep up, or sacrificial infrastructure for those you
>> are willing to let drop for the greater good.
>> 
>> -Blake
>> 
> 
> Unsure what you meant by this. In a multi-tenant firewall
> implementation (as far as I envision it), all tenants would
> occupy different IP space so I don't get how any of the
> state sessions would be affected. I'd be more concerned
> with not enough sockets. 
> 
> Palo Alto has a virtual system set up built specifically
> for this:
> 
> https://www.paloaltonetworks.com/products/features/virtual-systems.html
> 
> Now if only they'd send me free firewalls for marketing
> them.
> 
> -- 
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
> 
> "Where ignorance is our master, there is no possibility of
> real peace" - Dalai Lama
> 
> 0B23 595C F07C 6092 8AEB  074B FC83 7AF5 9D8A 4463
> https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463

Back in my corporate days, the company that I was working for had persistent problems with a large UK ISP who insisted on providing a centralised "managed" firewall service for their multi-site internet connectivity (basically an L3VPN with a gateway for internet breakout), despite then setting the rules to allow everything as each site on the network had its own local firewall under our administrative control.

The ISP were using Cisco FWSM with each customer in their own context and the company I was working for would periodically stop receiving any responses to DNS lookups irrespective of the server queried. It eventually turned out that another customer on the same FWSM kept getting DoSed and when this happened it caused some form of resource exhaustion (I'm afraid I can't recall the exact details) which broke things in the other contexts - the most noticeable of which was the protocol inspection/fixup stuff that was looking at DNS traffic!

Of course, this may have been a configuration issue or a problem with the specific version of software that the ISP were running.

Edward Dore 
Freethought Internet 

From rafael at gav.ufsc.br  Tue Aug 18 21:51:25 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Tue, 18 Aug 2015 16:51:25 -0500
Subject: Data Center operations mail list?
In-Reply-To: <1439753603.2269.0@smtp.gmail.com>
References: <B2065502-CABA-43A7-B037-9DBE570338E2@puck.nether.net>
 <17197925.180.1439314528497.JavaMail.root@benjamin.baylink.com>
 <20150811192715.GB2558@dilbert.slimey.org>
 <CAMDXq5M9wvC15QkuMyzwx7c+cMcEqF2Y1FTT1dujhn3muVEfWA@mail.gmail.com>
 <16E423B8-7479-494E-AC08-F9A779BA11E0@gizmopartners.com>
 <1439753603.2269.0@smtp.gmail.com>
Message-ID: <CAJB2g-E4A7EfXmuBBRKxy0e6PGGmY7YpecLTaseu0hpUY4ZnHQ@mail.gmail.com>

I actually suggested this to Chris while discussing what to have in the
website, I definitely think it would be nice to have a platform to help
plan and schedule local events for social and networking purposes.

I am working with a few people on designing a website, so I am guessing
some time in September we will have this in place.


On Sun, Aug 16, 2015 at 2:33 PM, Idafe Houghton <idafe.houghton at gmail.com>
wrote:

> While I am recent incorporation, have you ever thought about organizing a
> few meetups? I am not from America, but there has been a boom recently, on
> a few cities around the world striving to make a global linked community
> network of techlabs.
>
> Probably, it isn't suited for this community mailing-list, that is pretty
> specialized, but just saying. I have been lately interested in these forms
> of communication, knowledge and experience sharing.
>
> My tips.
>
>
> On dom, ago 16, 2015 at 9:22 , Chris Boyd <cboyd at gizmopartners.com> wrote:
>
>>
>>  On Aug 15, 2015, at 12:13 PM, Martin Hannigan <hannigan at gmail.com>
>>> wrote:
>>>
>>>  There is reasonable demand for a forum.  It might need a little
>>> marketing
>>>  to get a list with traction going.
>>>
>>
>> There seems to be some traction, with 268 members on the NADCOG list so
>> far.
>>
>> ?Chris
>>
>>

From bmanning at karoshi.com  Tue Aug 18 22:01:57 2015
From: bmanning at karoshi.com (manning)
Date: Tue, 18 Aug 2015 15:01:57 -0700
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <7D87295B-88AC-47E7-85FE-CFB6BFB12923@puck.nether.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <20150818124747.GG34798@greenie.muc.de>
 <7D87295B-88AC-47E7-85FE-CFB6BFB12923@puck.nether.net>
Message-ID: <F6DCF370-9562-4A36-BBBF-D8CD6B17CF28@karoshi.com>

Why do I read this thread as  ?Peering + Transit Circus?


manning
bmanning at karoshi.com
PO Box 6151
Playa del Rey, CA 90296
310.322.8102






On 18August2015Tuesday, at 6:01, Jared Mauch <jared at puck.nether.net> wrote:

> 
>> On Aug 18, 2015, at 8:47 AM, Gert Doering <gert at greenie.muc.de> wrote:
>> 
>> XR doesn't do it at all,
>> hrmph)
>> 
> 
> We have been asking about this as well, it might be worth revisiting.
> 
> - Jared


From faisal at snappytelecom.net  Tue Aug 18 22:35:41 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Tue, 18 Aug 2015 22:35:41 +0000 (GMT)
Subject: Peering + Transit Circuits
In-Reply-To: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
Message-ID: <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>

Let me start backwards... 

To me 'peering' is sharing internal routes and downstream customer routes,and not external ones.
    IP transit is all of the external routes including internal routes & downstream customer routes


Having said that..... if one is control of what IP Prefixes get advertised to whom... how exactly someone (peers) 'steal' transit ?
(If one is not managing the filters well then yes it is possible, but that would be a configuration error ?)


Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships)

Based on above belief...

Then Item # 3, becomes the choice of the OP.... where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like.

Items # 1 & 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason..

I am open to learning and being corrected if any of the above is wrong !


Faisal Imtiaz
Snappy Internet & Telecom

----- Original Message -----
> From: "Tim Durack" <tdurack at gmail.com>
> To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
> Sent: Tuesday, August 18, 2015 8:29:31 AM
> Subject: Peering + Transit Circuits

> Question: What is the preferred practice for separating peering and transit
> circuits?
> 
> 1. Terminate peering and transit on separate routers.
> 2. Terminate peering and transit circuits in separate VRFs.
> 3. QoS/QPPB (
> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
> )
> 4. Don't worry about peers stealing transit.
> 5. What is peering?
> 
> Your comments are appreciated.
> 
> --
> Tim:>

From pshem.k at gmail.com  Tue Aug 18 23:00:35 2015
From: pshem.k at gmail.com (Pshem Kowalczyk)
Date: Tue, 18 Aug 2015 23:00:35 +0000
Subject: Peering + Transit Circuits
In-Reply-To: <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
Message-ID: <CAEaZiRW9N0WP_iqZHKzu3HN46HjZvVddy_sGOtPF5tD39LM7QQ@mail.gmail.com>

It's actually quite easy.
Provider1 is present at Exchange1 and Exchange2, so is Provider2. Provider2
doesn't want to pay for the traffic between Exchange1 and Exchange2, so it
points a static route for all prefixes it has in Exchange2 via Provider1's
IP address in Exchange1 and does the same in Exchange2. Provider1's router
receives traffic, checks where it should go (Exchange2) and it forwards the
traffic. So the traffic flows like this:

Provider2 (Exchange1) -> Provider1 -> (Exchange2) Provider2, all due to
static routes.

kind regards
Pshem


On Wed, 19 Aug 2015 at 10:38 Faisal Imtiaz <faisal at snappytelecom.net> wrote:

> Let me start backwards...
>
> To me 'peering' is sharing internal routes and downstream customer
> routes,and not external ones.
>     IP transit is all of the external routes including internal routes &
> downstream customer routes
>
>
> Having said that..... if one is control of what IP Prefixes get advertised
> to whom... how exactly someone (peers) 'steal' transit ?
> (If one is not managing the filters well then yes it is possible, but that
> would be a configuration error ?)
>
>
> Maybe I am naive, to my Peering routes (relationships) are a subset of IP
> Transit Routes (relationships)
>
> Based on above belief...
>
> Then Item # 3, becomes the choice of the OP.... where one can make one of
> two starting assumptions... We will trust everything coming in and change
> what we don't like... or We will not trust anything coming in, and change
> (accept) what we like.
>
> Items # 1 & 2, would be a function of network design, technical
> requirements (maintenance window) etc etc.. easier to deal with a
> distributed edge vs all in one when one has to bring anything down for any
> reason..
>
> I am open to learning and being corrected if any of the above is wrong !
>
>
> Faisal Imtiaz
> Snappy Internet & Telecom
>
> ----- Original Message -----
> > From: "Tim Durack" <tdurack at gmail.com>
> > To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
> > Sent: Tuesday, August 18, 2015 8:29:31 AM
> > Subject: Peering + Transit Circuits
>
> > Question: What is the preferred practice for separating peering and
> transit
> > circuits?
> >
> > 1. Terminate peering and transit on separate routers.
> > 2. Terminate peering and transit circuits in separate VRFs.
> > 3. QoS/QPPB (
> >
> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
> > )
> > 4. Don't worry about peers stealing transit.
> > 5. What is peering?
> >
> > Your comments are appreciated.
> >
> > --
> > Tim:>
>

From baldur.norddahl at gmail.com  Tue Aug 18 23:02:16 2015
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Wed, 19 Aug 2015 01:02:16 +0200
Subject: Peering + Transit Circuits
In-Reply-To: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
Message-ID: <CAPkb-7BLRWgqjRHpqiYcRmBEf3vu5PDPA+SU9LFq78x5mCRysQ@mail.gmail.com>

On 18 August 2015 at 14:29, Tim Durack <tdurack at gmail.com> wrote:

> 4. Don't worry about peers stealing transit.
>

Because both of our transit providers implement source filters. Any packets
received with a source IP not in the list of IP ranges registered by us
will be dropped by the transit provider. Stealing transit is not practical
giving the limitation that you need to use a source address from our ranges.

I use ACLs on our end too just to be sure. ACL on the transit to prevent
wrong source from leaving our network and ACL on the peering to prevent
wrong destination to enter the network. Actually both ACLs are used in both
places.

The prefix lists used for the ACL need to be maintained in any case. It is
the list of routes that we advertise.

Regards,

Baldur

From patrick at ianai.net  Tue Aug 18 23:12:23 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 18 Aug 2015 19:12:23 -0400
Subject: Peering + Transit Circuits
In-Reply-To: <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
Message-ID: <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>

Assume you and I are at an IX and peer. Suppose I send you traffic for Comcast. I can do this, even if you do not send me prefixes for Comcast. It requires me to manually configure things, but I can do it.

Put another way, you said "We will trust everything coming in?. I am saying that perhaps you should not.

As Comcast is not one of your customers, you will have to send the packets out your transit provider. You do not get paid when I give you the packets, and you probably pay your transit provider to get to Comcast. So I have gotten something for free, and you are paying for it - i.e. stealing.

Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc.

There are evil ways around this if you do not configure your router properly (e.g. send you a prefix for Comcast with next-hop set to inside your network). But standard network hygiene will stop those.

And as has been stated, this doesn?t have anything to do with URPF either. (Not sure why Nick brought that up, he?s smart enough to know what URPF is and runs an exchange himself, so I think he just brain-farted. Happens to us all.)

Hope that made it more clear.

-- 
TTFN,
patrick

> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal at snappytelecom.net> wrote:
> 
> Let me start backwards... 
> 
> To me 'peering' is sharing internal routes and downstream customer routes,and not external ones.
>    IP transit is all of the external routes including internal routes & downstream customer routes
> 
> 
> Having said that..... if one is control of what IP Prefixes get advertised to whom... how exactly someone (peers) 'steal' transit ?
> (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?)
> 
> 
> Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships)
> 
> Based on above belief...
> 
> Then Item # 3, becomes the choice of the OP.... where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like.
> 
> Items # 1 & 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason..
> 
> I am open to learning and being corrected if any of the above is wrong !
> 
> 
> Faisal Imtiaz
> Snappy Internet & Telecom
> 
> ----- Original Message -----
>> From: "Tim Durack" <tdurack at gmail.com>
>> To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
>> Sent: Tuesday, August 18, 2015 8:29:31 AM
>> Subject: Peering + Transit Circuits
> 
>> Question: What is the preferred practice for separating peering and transit
>> circuits?
>> 
>> 1. Terminate peering and transit on separate routers.
>> 2. Terminate peering and transit circuits in separate VRFs.
>> 3. QoS/QPPB (
>> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
>> )
>> 4. Don't worry about peers stealing transit.
>> 5. What is peering?
>> 
>> Your comments are appreciated.
>> 
>> --
>> Tim:>


From faisal at snappytelecom.net  Tue Aug 18 23:26:14 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Tue, 18 Aug 2015 23:26:14 +0000 (GMT)
Subject: Peering + Transit Circuits
In-Reply-To: <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
Message-ID: <612191981.42016.1439940374980.JavaMail.zimbra@snappytelecom.net>

Thank you for the explanation..

However wouldn't a few other other attributes of the traffic show up .
  e.g. you would have asymmetric traffic.. going out via us, but coming back via a totally another path ?

BTW, my comment "We will trust everything coming in" was in ref. to QOS tags.

>>>> However, if you have a router at the IX which has _only_ peer routes
>>>> and your routes, that solves the problem. If I send you a packet for Comcast,
>>>> your peering router will drop it and send an ICMP Network Unreachable.

In this scenario, the peering router is feeding routes to a Route Reflector ? 
and not taking in full routes from the route reflector ?

>>>But standard network hygiene will stop those.
If there are any resources you could point to for these, I would be much obliged..


Thanks

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

----- Original Message -----
> From: "Patrick W. Gilmore" <patrick at ianai.net>
> To: "nanog list" <nanog at nanog.org>
> Sent: Tuesday, August 18, 2015 7:12:23 PM
> Subject: Re: Peering + Transit Circuits

> Assume you and I are at an IX and peer. Suppose I send you traffic for Comcast.
> I can do this, even if you do not send me prefixes for Comcast. It requires me
> to manually configure things, but I can do it.
> 
> Put another way, you said "We will trust everything coming in?. I am saying that
> perhaps you should not.
> 
> As Comcast is not one of your customers, you will have to send the packets out
> your transit provider. You do not get paid when I give you the packets, and you
> probably pay your transit provider to get to Comcast. So I have gotten
> something for free, and you are paying for it - i.e. stealing.
> 
> Normally a router gets a packet and sends it on its way without looking at the
> source. However, if you have a router at the IX which has _only_ peer routes
> and your routes, that solves the problem. If I send you a packet for Comcast,
> your peering router will drop it and send an ICMP Network Unreachable. No
> filters to manage, no RIRs to sync, nothing to code, etc.
> 
> There are evil ways around this if you do not configure your router properly
> (e.g. send you a prefix for Comcast with next-hop set to inside your network).
> But standard network hygiene will stop those.
> 
> And as has been stated, this doesn?t have anything to do with URPF either. (Not
> sure why Nick brought that up, he?s smart enough to know what URPF is and runs
> an exchange himself, so I think he just brain-farted. Happens to us all.)
> 
> Hope that made it more clear.
> 
> --
> TTFN,
> patrick
> 
>> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal at snappytelecom.net> wrote:
>> 
>> Let me start backwards...
>> 
>> To me 'peering' is sharing internal routes and downstream customer routes,and
>> not external ones.
>>    IP transit is all of the external routes including internal routes & downstream
>>    customer routes
>> 
>> 
>> Having said that..... if one is control of what IP Prefixes get advertised to
>> whom... how exactly someone (peers) 'steal' transit ?
>> (If one is not managing the filters well then yes it is possible, but that would
>> be a configuration error ?)
>> 
>> 
>> Maybe I am naive, to my Peering routes (relationships) are a subset of IP
>> Transit Routes (relationships)
>> 
>> Based on above belief...
>> 
>> Then Item # 3, becomes the choice of the OP.... where one can make one of two
>> starting assumptions... We will trust everything coming in and change what we
>> don't like... or We will not trust anything coming in, and change (accept) what
>> we like.
>> 
>> Items # 1 & 2, would be a function of network design, technical requirements
>> (maintenance window) etc etc.. easier to deal with a distributed edge vs all in
>> one when one has to bring anything down for any reason..
>> 
>> I am open to learning and being corrected if any of the above is wrong !
>> 
>> 
>> Faisal Imtiaz
>> Snappy Internet & Telecom
>> 
>> ----- Original Message -----
>>> From: "Tim Durack" <tdurack at gmail.com>
>>> To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
>>> Sent: Tuesday, August 18, 2015 8:29:31 AM
>>> Subject: Peering + Transit Circuits
>> 
>>> Question: What is the preferred practice for separating peering and transit
>>> circuits?
>>> 
>>> 1. Terminate peering and transit on separate routers.
>>> 2. Terminate peering and transit circuits in separate VRFs.
>>> 3. QoS/QPPB (
>>> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
>>> )
>>> 4. Don't worry about peers stealing transit.
>>> 5. What is peering?
>>> 
>>> Your comments are appreciated.
>>> 
>>> --
> >> Tim:>

From faisal at snappytelecom.net  Tue Aug 18 23:27:53 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Tue, 18 Aug 2015 23:27:53 +0000 (GMT)
Subject: Peering + Transit Circuits
In-Reply-To: <CAEaZiRW9N0WP_iqZHKzu3HN46HjZvVddy_sGOtPF5tD39LM7QQ@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <CAEaZiRW9N0WP_iqZHKzu3HN46HjZvVddy_sGOtPF5tD39LM7QQ@mail.gmail.com>
Message-ID: <1038705341.42036.1439940473161.JavaMail.zimbra@snappytelecom.net>

Thanks for the explanation, 
I am still trying to figure out the realistic business case where doing something like this would make sense to any party. 
(unless purely malicious or in error). 

Regards 

Faisal Imtiaz 
Snappy Internet & Telecom 

> From: "Pshem Kowalczyk" <pshem.k at gmail.com>
> To: "Faisal Imtiaz" <faisal at snappytelecom.net>, "Tim Durack" <tdurack at gmail.com>
> Cc: "nanog list" <nanog at nanog.org>, cisco-nsp at puck.nether.net
> Sent: Tuesday, August 18, 2015 7:00:35 PM
> Subject: Re: Peering + Transit Circuits

> It's actually quite easy.
> Provider1 is present at Exchange1 and Exchange2, so is Provider2. Provider2
> doesn't want to pay for the traffic between Exchange1 and Exchange2, so it
> points a static route for all prefixes it has in Exchange2 via Provider1's IP
> address in Exchange1 and does the same in Exchange2. Provider1's router
> receives traffic, checks where it should go (Exchange2) and it forwards the
> traffic. So the traffic flows like this:

> Provider2 (Exchange1) -> Provider1 -> (Exchange2) Provider2, all due to static
> routes.

> kind regards
> Pshem

> On Wed, 19 Aug 2015 at 10:38 Faisal Imtiaz < faisal at snappytelecom.net > wrote:

>> Let me start backwards...

>> To me 'peering' is sharing internal routes and downstream customer routes,and
>> not external ones.
>> IP transit is all of the external routes including internal routes & downstream
>> customer routes

>> Having said that..... if one is control of what IP Prefixes get advertised to
>> whom... how exactly someone (peers) 'steal' transit ?
>> (If one is not managing the filters well then yes it is possible, but that would
>> be a configuration error ?)

>> Maybe I am naive, to my Peering routes (relationships) are a subset of IP
>> Transit Routes (relationships)

>> Based on above belief...

>> Then Item # 3, becomes the choice of the OP.... where one can make one of two
>> starting assumptions... We will trust everything coming in and change what we
>> don't like... or We will not trust anything coming in, and change (accept) what
>> we like.

>> Items # 1 & 2, would be a function of network design, technical requirements
>> (maintenance window) etc etc.. easier to deal with a distributed edge vs all in
>> one when one has to bring anything down for any reason..

>> I am open to learning and being corrected if any of the above is wrong !

>> Faisal Imtiaz
>> Snappy Internet & Telecom

>> ----- Original Message -----
>> > From: "Tim Durack" < tdurack at gmail.com >
>> > To: cisco-nsp at puck.nether.net , "nanog list" < nanog at nanog.org >
>> > Sent: Tuesday, August 18, 2015 8:29:31 AM
>> > Subject: Peering + Transit Circuits

>> > Question: What is the preferred practice for separating peering and transit
>> > circuits?

>> > 1. Terminate peering and transit on separate routers.
>> > 2. Terminate peering and transit circuits in separate VRFs.
>> > 3. QoS/QPPB (
>> > https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
>> > )
>> > 4. Don't worry about peers stealing transit.
>> > 5. What is peering?

>> > Your comments are appreciated.

>> > --
>> > Tim:>

From bob at FiberInternetCenter.com  Tue Aug 18 23:36:00 2015
From: bob at FiberInternetCenter.com (Bob Evans)
Date: Tue, 18 Aug 2015 16:36:00 -0700
Subject: Peering + Transit Circuits
In-Reply-To: <612191981.42016.1439940374980.JavaMail.zimbra@snappytelecom.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
 <612191981.42016.1439940374980.JavaMail.zimbra@snappytelecom.net>
Message-ID: <920473494c994e1a1be387f9b57c3bfb.squirrel@66.201.44.180>


Thank You
Bob Evans
CTO

> Thank you for the explanation..
>
> However wouldn't a few other other attributes of the traffic show up .
>   e.g. you would have asymmetric traffic.. going out via us, but coming
> back via a totally another path ?

Patrick is correct in the approach you should take. If you don't have much
traffic to being with - yes, you are correct that you'll notice a bounce.
However, you should build a network so that your average traffic level can
grow without having to check things manually. The more you automate the
more you and your network are worth. This way you can simply upgrade ports
at IX locations in a second without worrying about traffic levels and
having to establish new or change existing policies.

Thank You
Bob Evans
CTO

>
> BTW, my comment "We will trust everything coming in" was in ref. to QOS
> tags.
>
>>>>> However, if you have a router at the IX which has _only_ peer routes
>>>>> and your routes, that solves the problem. If I send you a packet for
>>>>> Comcast,
>>>>> your peering router will drop it and send an ICMP Network
>>>>> Unreachable.
>
> In this scenario, the peering router is feeding routes to a Route
> Reflector ?
> and not taking in full routes from the route reflector ?
>
>>>>But standard network hygiene will stop those.
> If there are any resources you could point to for these, I would be much
> obliged..
>
>
> Thanks
>
> 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
>
> ----- Original Message -----
>> From: "Patrick W. Gilmore" <patrick at ianai.net>
>> To: "nanog list" <nanog at nanog.org>
>> Sent: Tuesday, August 18, 2015 7:12:23 PM
>> Subject: Re: Peering + Transit Circuits
>
>> Assume you and I are at an IX and peer. Suppose I send you traffic for
>> Comcast.
>> I can do this, even if you do not send me prefixes for Comcast. It
>> requires me
>> to manually configure things, but I can do it.
>>
>> Put another way, you said "We will trust everything coming in???. I am
>> saying that
>> perhaps you should not.
>>
>> As Comcast is not one of your customers, you will have to send the
>> packets out
>> your transit provider. You do not get paid when I give you the packets,
>> and you
>> probably pay your transit provider to get to Comcast. So I have gotten
>> something for free, and you are paying for it - i.e. stealing.
>>
>> Normally a router gets a packet and sends it on its way without looking
>> at the
>> source. However, if you have a router at the IX which has _only_ peer
>> routes
>> and your routes, that solves the problem. If I send you a packet for
>> Comcast,
>> your peering router will drop it and send an ICMP Network Unreachable.
>> No
>> filters to manage, no RIRs to sync, nothing to code, etc.
>>
>> There are evil ways around this if you do not configure your router
>> properly
>> (e.g. send you a prefix for Comcast with next-hop set to inside your
>> network).
>> But standard network hygiene will stop those.
>>
>> And as has been stated, this doesn???t have anything to do with URPF
>> either. (Not
>> sure why Nick brought that up, he???s smart enough to know what URPF is
>> and runs
>> an exchange himself, so I think he just brain-farted. Happens to us
>> all.)
>>
>> Hope that made it more clear.
>>
>> --
>> TTFN,
>> patrick
>>
>>> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal at snappytelecom.net>
>>> wrote:
>>>
>>> Let me start backwards...
>>>
>>> To me 'peering' is sharing internal routes and downstream customer
>>> routes,and
>>> not external ones.
>>>    IP transit is all of the external routes including internal routes &
>>> downstream
>>>    customer routes
>>>
>>>
>>> Having said that..... if one is control of what IP Prefixes get
>>> advertised to
>>> whom... how exactly someone (peers) 'steal' transit ?
>>> (If one is not managing the filters well then yes it is possible, but
>>> that would
>>> be a configuration error ?)
>>>
>>>
>>> Maybe I am naive, to my Peering routes (relationships) are a subset of
>>> IP
>>> Transit Routes (relationships)
>>>
>>> Based on above belief...
>>>
>>> Then Item # 3, becomes the choice of the OP.... where one can make one
>>> of two
>>> starting assumptions... We will trust everything coming in and change
>>> what we
>>> don't like... or We will not trust anything coming in, and change
>>> (accept) what
>>> we like.
>>>
>>> Items # 1 & 2, would be a function of network design, technical
>>> requirements
>>> (maintenance window) etc etc.. easier to deal with a distributed edge
>>> vs all in
>>> one when one has to bring anything down for any reason..
>>>
>>> I am open to learning and being corrected if any of the above is wrong
>>> !
>>>
>>>
>>> Faisal Imtiaz
>>> Snappy Internet & Telecom
>>>
>>> ----- Original Message -----
>>>> From: "Tim Durack" <tdurack at gmail.com>
>>>> To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
>>>> Sent: Tuesday, August 18, 2015 8:29:31 AM
>>>> Subject: Peering + Transit Circuits
>>>
>>>> Question: What is the preferred practice for separating peering and
>>>> transit
>>>> circuits?
>>>>
>>>> 1. Terminate peering and transit on separate routers.
>>>> 2. Terminate peering and transit circuits in separate VRFs.
>>>> 3. QoS/QPPB (
>>>> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
>>>> )
>>>> 4. Don't worry about peers stealing transit.
>>>> 5. What is peering?
>>>>
>>>> Your comments are appreciated.
>>>>
>>>> --
>> >> Tim:>
>



From patrick at ianai.net  Tue Aug 18 23:38:18 2015
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Tue, 18 Aug 2015 19:38:18 -0400
Subject: Peering + Transit Circuits
In-Reply-To: <612191981.42016.1439940374980.JavaMail.zimbra@snappytelecom.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
 <612191981.42016.1439940374980.JavaMail.zimbra@snappytelecom.net>
Message-ID: <BAE8CE0C-1002-4AB5-A5D8-8427CD224C3C@ianai.net>

On Aug 18, 2015, at 7:26 PM, Faisal Imtiaz <faisal at snappytelecom.net> wrote:
> 
> Thank you for the explanation..
> 
> However wouldn't a few other other attributes of the traffic show up .
>  e.g. you would have asymmetric traffic.. going out via us, but coming back via a totally another path ?

So? If I am a content provider, my transit has more out than in. If I can push some of that outbound traffic through you for free, I?ll get the inbound over my transit provider for free since inbound is so low.

> BTW, my comment "We will trust everything coming in" was in ref. to QOS tags.
> 
>>>>> However, if you have a router at the IX which has _only_ peer routes
>>>>> and your routes, that solves the problem. If I send you a packet for Comcast,
>>>>> your peering router will drop it and send an ICMP Network Unreachable.
> 
> In this scenario, the peering router is feeding routes to a Route Reflector ? 
> and not taking in full routes from the route reflector ?

The peering router has routes from the peers (since it peers directly with them), and routes from your internal network. Not sure where a router reflector comes into this. You can use one, or not, but it?s not relevant to which routes the peering router has.


>>>> But standard network hygiene will stop those.
> If there are any resources you could point to for these, I would be much obliged..

There are lots, but don?t have my references with me. There?s 10K+ people on this list, I?m sure someone else has a list they like. :)

-- 
TTFN,
patrick


> ----- Original Message -----
>> From: "Patrick W. Gilmore" <patrick at ianai.net>
>> To: "nanog list" <nanog at nanog.org>
>> Sent: Tuesday, August 18, 2015 7:12:23 PM
>> Subject: Re: Peering + Transit Circuits
> 
>> Assume you and I are at an IX and peer. Suppose I send you traffic for Comcast.
>> I can do this, even if you do not send me prefixes for Comcast. It requires me
>> to manually configure things, but I can do it.
>> 
>> Put another way, you said "We will trust everything coming in?. I am saying that
>> perhaps you should not.
>> 
>> As Comcast is not one of your customers, you will have to send the packets out
>> your transit provider. You do not get paid when I give you the packets, and you
>> probably pay your transit provider to get to Comcast. So I have gotten
>> something for free, and you are paying for it - i.e. stealing.
>> 
>> Normally a router gets a packet and sends it on its way without looking at the
>> source. However, if you have a router at the IX which has _only_ peer routes
>> and your routes, that solves the problem. If I send you a packet for Comcast,
>> your peering router will drop it and send an ICMP Network Unreachable. No
>> filters to manage, no RIRs to sync, nothing to code, etc.
>> 
>> There are evil ways around this if you do not configure your router properly
>> (e.g. send you a prefix for Comcast with next-hop set to inside your network).
>> But standard network hygiene will stop those.
>> 
>> And as has been stated, this doesn?t have anything to do with URPF either. (Not
>> sure why Nick brought that up, he?s smart enough to know what URPF is and runs
>> an exchange himself, so I think he just brain-farted. Happens to us all.)
>> 
>> Hope that made it more clear.
>> 
>> --
>> TTFN,
>> patrick
>> 
>>> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal at snappytelecom.net> wrote:
>>> 
>>> Let me start backwards...
>>> 
>>> To me 'peering' is sharing internal routes and downstream customer routes,and
>>> not external ones.
>>>   IP transit is all of the external routes including internal routes & downstream
>>>   customer routes
>>> 
>>> 
>>> Having said that..... if one is control of what IP Prefixes get advertised to
>>> whom... how exactly someone (peers) 'steal' transit ?
>>> (If one is not managing the filters well then yes it is possible, but that would
>>> be a configuration error ?)
>>> 
>>> 
>>> Maybe I am naive, to my Peering routes (relationships) are a subset of IP
>>> Transit Routes (relationships)
>>> 
>>> Based on above belief...
>>> 
>>> Then Item # 3, becomes the choice of the OP.... where one can make one of two
>>> starting assumptions... We will trust everything coming in and change what we
>>> don't like... or We will not trust anything coming in, and change (accept) what
>>> we like.
>>> 
>>> Items # 1 & 2, would be a function of network design, technical requirements
>>> (maintenance window) etc etc.. easier to deal with a distributed edge vs all in
>>> one when one has to bring anything down for any reason..
>>> 
>>> I am open to learning and being corrected if any of the above is wrong !
>>> 
>>> 
>>> Faisal Imtiaz
>>> Snappy Internet & Telecom
>>> 
>>> ----- Original Message -----
>>>> From: "Tim Durack" <tdurack at gmail.com>
>>>> To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
>>>> Sent: Tuesday, August 18, 2015 8:29:31 AM
>>>> Subject: Peering + Transit Circuits
>>> 
>>>> Question: What is the preferred practice for separating peering and transit
>>>> circuits?
>>>> 
>>>> 1. Terminate peering and transit on separate routers.
>>>> 2. Terminate peering and transit circuits in separate VRFs.
>>>> 3. QoS/QPPB (
>>>> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
>>>> )
>>>> 4. Don't worry about peers stealing transit.
>>>> 5. What is peering?
>>>> 
>>>> Your comments are appreciated.
>>>> 
>>>> --
>>>> Tim:>


From faisal at snappytelecom.net  Wed Aug 19 00:16:13 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Wed, 19 Aug 2015 00:16:13 +0000 (GMT)
Subject: Peering + Transit Circuits
In-Reply-To: <920473494c994e1a1be387f9b57c3bfb.squirrel@66.201.44.180>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
 <612191981.42016.1439940374980.JavaMail.zimbra@snappytelecom.net>
 <920473494c994e1a1be387f9b57c3bfb.squirrel@66.201.44.180>
Message-ID: <733284324.42208.1439943373602.JavaMail.zimbra@snappytelecom.net>

Hi Bob,
Your point is completely understood...
so the next question becomes what are these best practices methods ?

:)

Faisal Imtiaz
Snappy Internet & Telecom

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net

----- Original Message -----
> From: "Bob Evans" <bob at FiberInternetCenter.com>
> To: "Faisal Imtiaz" <faisal at snappytelecom.net>
> Cc: "Patrick W. Gilmore" <patrick at ianai.net>, "nanog list" <nanog at nanog.org>
> Sent: Tuesday, August 18, 2015 7:36:00 PM
> Subject: Re: Peering + Transit Circuits

> Thank You
> Bob Evans
> CTO
> 
>> Thank you for the explanation..
>>
>> However wouldn't a few other other attributes of the traffic show up .
>>   e.g. you would have asymmetric traffic.. going out via us, but coming
>> back via a totally another path ?
> 
> Patrick is correct in the approach you should take. If you don't have much
> traffic to being with - yes, you are correct that you'll notice a bounce.
> However, you should build a network so that your average traffic level can
> grow without having to check things manually. The more you automate the
> more you and your network are worth. This way you can simply upgrade ports
> at IX locations in a second without worrying about traffic levels and
> having to establish new or change existing policies.
> 
> Thank You
> Bob Evans
> CTO
> 
>>
>> BTW, my comment "We will trust everything coming in" was in ref. to QOS
>> tags.
>>
>>>>>> However, if you have a router at the IX which has _only_ peer routes
>>>>>> and your routes, that solves the problem. If I send you a packet for
>>>>>> Comcast,
>>>>>> your peering router will drop it and send an ICMP Network
>>>>>> Unreachable.
>>
>> In this scenario, the peering router is feeding routes to a Route
>> Reflector ?
>> and not taking in full routes from the route reflector ?
>>
>>>>>But standard network hygiene will stop those.
>> If there are any resources you could point to for these, I would be much
>> obliged..
>>
>>
>> Thanks
>>
>> 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
>>
>> ----- Original Message -----
>>> From: "Patrick W. Gilmore" <patrick at ianai.net>
>>> To: "nanog list" <nanog at nanog.org>
>>> Sent: Tuesday, August 18, 2015 7:12:23 PM
>>> Subject: Re: Peering + Transit Circuits
>>
>>> Assume you and I are at an IX and peer. Suppose I send you traffic for
>>> Comcast.
>>> I can do this, even if you do not send me prefixes for Comcast. It
>>> requires me
>>> to manually configure things, but I can do it.
>>>
>>> Put another way, you said "We will trust everything coming in???. I am
>>> saying that
>>> perhaps you should not.
>>>
>>> As Comcast is not one of your customers, you will have to send the
>>> packets out
>>> your transit provider. You do not get paid when I give you the packets,
>>> and you
>>> probably pay your transit provider to get to Comcast. So I have gotten
>>> something for free, and you are paying for it - i.e. stealing.
>>>
>>> Normally a router gets a packet and sends it on its way without looking
>>> at the
>>> source. However, if you have a router at the IX which has _only_ peer
>>> routes
>>> and your routes, that solves the problem. If I send you a packet for
>>> Comcast,
>>> your peering router will drop it and send an ICMP Network Unreachable.
>>> No
>>> filters to manage, no RIRs to sync, nothing to code, etc.
>>>
>>> There are evil ways around this if you do not configure your router
>>> properly
>>> (e.g. send you a prefix for Comcast with next-hop set to inside your
>>> network).
>>> But standard network hygiene will stop those.
>>>
>>> And as has been stated, this doesn???t have anything to do with URPF
>>> either. (Not
>>> sure why Nick brought that up, he???s smart enough to know what URPF is
>>> and runs
>>> an exchange himself, so I think he just brain-farted. Happens to us
>>> all.)
>>>
>>> Hope that made it more clear.
>>>
>>> --
>>> TTFN,
>>> patrick
>>>
>>>> On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz <faisal at snappytelecom.net>
>>>> wrote:
>>>>
>>>> Let me start backwards...
>>>>
>>>> To me 'peering' is sharing internal routes and downstream customer
>>>> routes,and
>>>> not external ones.
>>>>    IP transit is all of the external routes including internal routes &
>>>> downstream
>>>>    customer routes
>>>>
>>>>
>>>> Having said that..... if one is control of what IP Prefixes get
>>>> advertised to
>>>> whom... how exactly someone (peers) 'steal' transit ?
>>>> (If one is not managing the filters well then yes it is possible, but
>>>> that would
>>>> be a configuration error ?)
>>>>
>>>>
>>>> Maybe I am naive, to my Peering routes (relationships) are a subset of
>>>> IP
>>>> Transit Routes (relationships)
>>>>
>>>> Based on above belief...
>>>>
>>>> Then Item # 3, becomes the choice of the OP.... where one can make one
>>>> of two
>>>> starting assumptions... We will trust everything coming in and change
>>>> what we
>>>> don't like... or We will not trust anything coming in, and change
>>>> (accept) what
>>>> we like.
>>>>
>>>> Items # 1 & 2, would be a function of network design, technical
>>>> requirements
>>>> (maintenance window) etc etc.. easier to deal with a distributed edge
>>>> vs all in
>>>> one when one has to bring anything down for any reason..
>>>>
>>>> I am open to learning and being corrected if any of the above is wrong
>>>> !
>>>>
>>>>
>>>> Faisal Imtiaz
>>>> Snappy Internet & Telecom
>>>>
>>>> ----- Original Message -----
>>>>> From: "Tim Durack" <tdurack at gmail.com>
>>>>> To: cisco-nsp at puck.nether.net, "nanog list" <nanog at nanog.org>
>>>>> Sent: Tuesday, August 18, 2015 8:29:31 AM
>>>>> Subject: Peering + Transit Circuits
>>>>
>>>>> Question: What is the preferred practice for separating peering and
>>>>> transit
>>>>> circuits?
>>>>>
>>>>> 1. Terminate peering and transit on separate routers.
>>>>> 2. Terminate peering and transit circuits in separate VRFs.
>>>>> 3. QoS/QPPB (
>>>>> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
>>>>> )
>>>>> 4. Don't worry about peers stealing transit.
>>>>> 5. What is peering?
>>>>>
>>>>> Your comments are appreciated.
>>>>>
>>>>> --
>>> >> Tim:>

From josmon at rigozsaurus.com  Wed Aug 19 00:30:45 2015
From: josmon at rigozsaurus.com (John Osmon)
Date: Tue, 18 Aug 2015 18:30:45 -0600
Subject: Peering + Transit Circuits
In-Reply-To: <1038705341.42036.1439940473161.JavaMail.zimbra@snappytelecom.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <CAEaZiRW9N0WP_iqZHKzu3HN46HjZvVddy_sGOtPF5tD39LM7QQ@mail.gmail.com>
 <1038705341.42036.1439940473161.JavaMail.zimbra@snappytelecom.net>
Message-ID: <20150819003045.GB24045@jeeves.rigozsaurus.com>

On Tue, Aug 18, 2015 at 11:27:53PM +0000, Faisal Imtiaz wrote:
> Thanks for the explanation, 
> I am still trying to figure out the realistic business case where
> doing something like this would make sense to any party. 
> (unless purely malicious or in error). 

I'm sure others will reply as well, but in case it helps someone
googling in years to come...


Let's look at ParasiteNet, a content heavy network with three BGP
peerings:
  - Transit provider A via 100Mbps
  - Transit provider B via 100Mbps
  - Peer P via 1GBps (who also buys from provider B at 10G)

If ParasiteNet needed to push more than 100Mbps to provider B, they
might be tempted to route the traffic to peer P, even though peer P
didn't advertise those routes.

ParasiteNet gets a free ride if peer P doesn't notice what is going on
(until they need more than 100Mbps inbound).


I've been told of an occurance of this when a private network started
peering with an edu network.  Once the link was up, an absurd amount of
traffic went across the link -- all destined for "the Internet" rather
than the edu network.

When the edu network shutdown the link, they were threatened with
lawsuits...

From faisal at snappytelecom.net  Wed Aug 19 04:29:47 2015
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Wed, 19 Aug 2015 04:29:47 +0000 (GMT)
Subject: Peering + Transit Circuits
In-Reply-To: <20150819003045.GB24045@jeeves.rigozsaurus.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <CAEaZiRW9N0WP_iqZHKzu3HN46HjZvVddy_sGOtPF5tD39LM7QQ@mail.gmail.com>
 <1038705341.42036.1439940473161.JavaMail.zimbra@snappytelecom.net>
 <20150819003045.GB24045@jeeves.rigozsaurus.com>
Message-ID: <1545545536.43866.1439958587721.JavaMail.zimbra@snappytelecom.net>

Thank you to everyone who has offered different explanations.. 

Yes, all it take is one party pooper to spoil a good party...

So now the question is (public or private) what is the best practices to protect the network ?

:)


Faisal Imtiaz
Snappy Internet & Telecom

----- Original Message -----
> From: "John Osmon" <josmon at rigozsaurus.com>
> To: "nanog list" <nanog at nanog.org>
> Sent: Tuesday, August 18, 2015 8:30:45 PM
> Subject: Re: Peering + Transit Circuits

> On Tue, Aug 18, 2015 at 11:27:53PM +0000, Faisal Imtiaz wrote:
>> Thanks for the explanation,
>> I am still trying to figure out the realistic business case where
>> doing something like this would make sense to any party.
>> (unless purely malicious or in error).
> 
> I'm sure others will reply as well, but in case it helps someone
> googling in years to come...
> 
> 
> Let's look at ParasiteNet, a content heavy network with three BGP
> peerings:
>  - Transit provider A via 100Mbps
>  - Transit provider B via 100Mbps
>  - Peer P via 1GBps (who also buys from provider B at 10G)
> 
> If ParasiteNet needed to push more than 100Mbps to provider B, they
> might be tempted to route the traffic to peer P, even though peer P
> didn't advertise those routes.
> 
> ParasiteNet gets a free ride if peer P doesn't notice what is going on
> (until they need more than 100Mbps inbound).
> 
> 
> I've been told of an occurance of this when a private network started
> peering with an edu network.  Once the link was up, an absurd amount of
> traffic went across the link -- all destined for "the Internet" rather
> than the edu network.
> 
> When the edu network shutdown the link, they were threatened with
> lawsuits...

From ggreene at minervanetworks.com  Tue Aug 18 18:17:55 2015
From: ggreene at minervanetworks.com (Gary Greene)
Date: Tue, 18 Aug 2015 18:17:55 +0000
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <1439919568.192219773@upnet.mymailsrvr.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
Message-ID: <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>

You?ll need to escalate this with Google. If the front-end support team cannot help, move up the chain as far as you can. It should eventually reach the PM that worked on the turn-down of that service and get some action.

--
Gary L. Greene, Jr.
Sr. Systems Administrator
IT Operations
Minerva Networks, Inc.
Cell: +1 (650) 704-6633




> On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
> 
> 
> I know there are others on this list who used Google Apps for ISPs and recently migrated off (as the service was discontinued).
> 
> We have had several cases where the user had a YouTube channel or Picasa photo albums, etc. that they created with their Google Apps for ISPs credentials.  Now that the service is gone, those channels and albums still exist but the users are unable to login to them or manage them in any way because it tells them that their account has been disabled.
> 
> Of course, Google had been un-responsive to all of our (and the customer's) inquiries about how to fix this.
> 
> Has anyone else run into this and found a way around it?
> 
> thanks
> 
> 
> Shawn
> 


From nick at foobar.org  Wed Aug 19 08:59:13 2015
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 19 Aug 2015 09:59:13 +0100
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <CAP-guGU54m5e_bb2UgKnbgiJk314V3VfNkD44vF3L5g_LTJMgg@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
 <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
 <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>
 <55D39903.6050009@foobar.org>
 <CAP-guGU54m5e_bb2UgKnbgiJk314V3VfNkD44vF3L5g_LTJMgg@mail.gmail.com>
Message-ID: <55D44561.7010809@foobar.org>

On 18/08/2015 22:10, William Herrin wrote:
> This technique described isn't URPF, it's simple destination routing.
> The routes I offer you via BGP are the only routes in my table, hence
> the only routes I'm capable of routing. If you send me a packet for a
> _destination_ I didn't offer to you, I can't route it.

yep, I hit send too soon.  The point I intended to make was that ixp
peering in a vrf will only protect you from transit theft, not clandestine
peering.  If you want to stop third party organisations at an ixp from
getting peering by installing static routes, then l2 filters are what you need.

Nick



From maxtul at netassist.ua  Wed Aug 19 16:36:35 2015
From: maxtul at netassist.ua (Max Tulyev)
Date: Wed, 19 Aug 2015 19:36:35 +0300
Subject: Peering + Transit Circuits
In-Reply-To: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
Message-ID: <55D4B093.3080900@netassist.ua>

My solution is:

1. Don't care.
2. If some peer steal your transit, and it is noticeable amount of
traffic causing some problems for you - investigate and terminate that peer.

On 18.08.15 15:29, Tim Durack wrote:
> Question: What is the preferred practice for separating peering and transit
> circuits?
> 
> 1. Terminate peering and transit on separate routers.
> 2. Terminate peering and transit circuits in separate VRFs.
> 3. QoS/QPPB (
> https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf
> )
> 4. Don't worry about peers stealing transit.
> 5. What is peering?
> 
> Your comments are appreciated.
> 


From jlewis at lewis.org  Wed Aug 19 17:28:31 2015
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 19 Aug 2015 13:28:31 -0400 (EDT)
Subject: Peering + Transit Circuits
In-Reply-To: <55D4B093.3080900@netassist.ua>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <55D4B093.3080900@netassist.ua>
Message-ID: <Pine.LNX.4.61.1508191325340.10544@soloth.lewis.org>

On Wed, 19 Aug 2015, Max Tulyev wrote:

> My solution is:
>
> 1. Don't care.
> 2. If some peer steal your transit, and it is noticeable amount of
> traffic causing some problems for you - investigate and terminate that peer.

You forgot 3. Publicly shame on NANOG so that others will think twice 
before peering or doing any business with them.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
                              |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From andy at nosignal.org  Wed Aug 19 17:54:48 2015
From: andy at nosignal.org (Andy Davidson)
Date: Wed, 19 Aug 2015 17:54:48 +0000
Subject: Peering + Transit Circuits
In-Reply-To: <55D4B093.3080900@netassist.ua>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <55D4B093.3080900@netassist.ua>
Message-ID: <B6D95AA4-DFA2-4FB9-B0CB-B33A93F2682E@nosignal.org>


Hi, Max --





On 19/08/2015 17:36, Max Tulyev <maxtul at netassist.ua> wrote:

>My solution is:
>
>1. Don't care.
>2. If some peer steal your transit, and it is noticeable amount of
>traffic causing some problems for you - investigate and terminate that peer.

Unless this bandwidth fraud is taking place over a public peering LAN (IX).  You could find that a non-peer is ?stealing bandwidth?.  In which case, tell the IX operator (they *do* care, and *do* want to stop abusive or fraudulent behaviour).  

You can, if paranoid, apply some l2/3 filters to only hear from expected peers at the IX (which prevents non-peers from pointing statics at you, but not peers though.)  How paranoid shall we take it ?  You can also - with a small enough customer footprint - perhaps put each peer into their own VRF and apply policies which prohibit forwarding except to customer prefixes.  

-a

From blair.trosper at gmail.com  Wed Aug 19 20:44:11 2015
From: blair.trosper at gmail.com (Blair Trosper)
Date: Wed, 19 Aug 2015 15:44:11 -0500
Subject: Suddenlink: Texas panhandle
Message-ID: <CAA5Ek4cbdyY+YPMCNxjwh_P8m+rExC0+y0zafP_NV68HydWczg@mail.gmail.com>

They apparently experienced massive fiber cuts last night and are still
100% down.  Anyone know anything about this?

From sean at donelan.com  Thu Aug 20 00:44:03 2015
From: sean at donelan.com (Sean Donelan)
Date: Wed, 19 Aug 2015 20:44:03 -0400 (EDT)
Subject: Cloud backups versus lightning strikes
Message-ID: <alpine.BSF.2.20.1508192037370.45862@cnex.qbaryna.pbz>


As the saying goes, cloud computing is just someone else's computer. 
Always backup your cloud backups... in your backup.

Google's spokesperson used the percentage statistic to avoid how
much data was lost.  Other cloud providers have also lost customer
data due to various problems.  While a well-run cloud service provider
is more reliable than keeping data under your mattress (just like a 
well-run bank is better than keeping cash under your mattress), its
not magic.

Nature is still more powerful than even Google.


http://www.bbc.com/news/technology-33989384

Google says data has been wiped from discs at one of its data centres in 
Belgium - after it was struck by lightning four times.

Some people have permanently lost access to their files as a result.


From mpalmer at hezmatt.org  Thu Aug 20 01:38:10 2015
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Thu, 20 Aug 2015 11:38:10 +1000
Subject: Cloud backups versus lightning strikes
In-Reply-To: <alpine.BSF.2.20.1508192037370.45862@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1508192037370.45862@cnex.qbaryna.pbz>
Message-ID: <20150820013810.GK1282@hezmatt.org>

On Wed, Aug 19, 2015 at 08:44:03PM -0400, Sean Donelan wrote:
> As the saying goes, cloud computing is just someone else's computer. Always
> backup your cloud backups... in your backup.

This was data loss on GCE "persistent disks" (equivalent to AWS EBS), not
archival storage.  Hopefully very few people are using persistent disks as
*backup* storage (if nothing else, it's more expensive).

The general point is still valid, though -- *any* single instance of data is
vulnerable to loss, whether it's on your computer, or someone else's. 
Backups are never optional.

- Matt


From kauer at biplane.com.au  Thu Aug 20 02:10:11 2015
From: kauer at biplane.com.au (Karl Auer)
Date: Thu, 20 Aug 2015 12:10:11 +1000
Subject: Cloud backups versus lightning strikes
In-Reply-To: <20150820013810.GK1282@hezmatt.org>
References: <alpine.BSF.2.20.1508192037370.45862@cnex.qbaryna.pbz>
 <20150820013810.GK1282@hezmatt.org>
Message-ID: <1440036611.17629.18.camel@karl>

On Thu, 2015-08-20 at 11:38 +1000, Matt Palmer wrote:
> Backups are never optional.

Love the phrasing too - "permanently lost access to their data". Their
data is not lost, not gone, not destroyed, oh no! It's still there,
somewhere, but they will just never, ever be able to access it again.

Maybe it's to leave a sliver of hope: "We'll meet again, don't know
where, don't know when, but I know we'll meet again (all together now,
customers!) some sunny daaaaay"...

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 george.herbert at gmail.com  Thu Aug 20 07:16:57 2015
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 20 Aug 2015 00:16:57 -0700
Subject: Cloud backups versus lightning strikes
In-Reply-To: <alpine.BSF.2.20.1508192037370.45862@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1508192037370.45862@cnex.qbaryna.pbz>
Message-ID: <135D4F54-BC6E-46A4-A8FC-E68BEC80D6F4@gmail.com>

My read on the situation is Yet Another Intermediate Cacheing Fail in storage, a well known problem.  Yes, do a pull the power test on your storage so you KNOW what's committed...

George William Herbert
Sent from my iPhone

> On Aug 19, 2015, at 5:44 PM, Sean Donelan <sean at donelan.com> wrote:
> 
> 
> As the saying goes, cloud computing is just someone else's computer. Always backup your cloud backups... in your backup.
> 
> Google's spokesperson used the percentage statistic to avoid how
> much data was lost.  Other cloud providers have also lost customer
> data due to various problems.  While a well-run cloud service provider
> is more reliable than keeping data under your mattress (just like a well-run bank is better than keeping cash under your mattress), its
> not magic.
> 
> Nature is still more powerful than even Google.
> 
> 
> http://www.bbc.com/news/technology-33989384
> 
> Google says data has been wiped from discs at one of its data centres in Belgium - after it was struck by lightning four times.
> 
> Some people have permanently lost access to their files as a result.
> 

From jb at forethought.net  Thu Aug 20 13:44:10 2015
From: jb at forethought.net (Jawaid Shell2)
Date: Thu, 20 Aug 2015 07:44:10 -0600
Subject: Production-scale NAT64
Message-ID: <55D5D9AA.2080203@forethought.net>

Who out there is using production-scale NAT64? What solution are you using?

Thanks,

Jawaid


From Valdis.Kletnieks at vt.edu  Thu Aug 20 15:00:04 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 20 Aug 2015 11:00:04 -0400
Subject: Production-scale NAT64
In-Reply-To: <55D5D9AA.2080203@forethought.net>
References: <55D5D9AA.2080203@forethought.net>
Message-ID: <3775.1440082804@turing-police.cc.vt.edu>

On Thu, 20 Aug 2015 07:44:10 -0600, Jawaid Shell2 said:
> Who out there is using production-scale NAT64? What solution are you using?

OK, I'll bite - what definition of "production-scale" are you using?
Production use for how many digits worth of simultaneous users?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150820/18e459eb/attachment.pgp>

From rsk at gsp.org  Thu Aug 20 15:43:09 2015
From: rsk at gsp.org (Rich Kulawiec)
Date: Thu, 20 Aug 2015 11:43:09 -0400
Subject: Data Center operations mail list?
In-Reply-To: <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
Message-ID: <20150820154309.GB19948@gsp.org>


It appears that this list is sending its outbound traffic via Amazon's
cloud operation.

This is a profoundly horrible idea, not through any fault of yours, but
because Amazon's cloud operation is a massive, non-stop fountain of spam
and Amazon personnel flatly refuse to lift a finger to do anything about it.
As a result of this incompetence/negligence, some folks out there have
taken defensive measures which may include firewalling, blocking, discarding,
rejecting, etc.  Thus this is not someplace that you want to try to send
mail from if you really care about having it delivered.

I recommend moving it elsewhere.  And I'm perfectly willing to assist with
that (either selecting another location or facilitating the move or both).

---rsk

From rafael at gav.ufsc.br  Thu Aug 20 15:51:39 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Thu, 20 Aug 2015 10:51:39 -0500
Subject: Data Center operations mail list?
In-Reply-To: <20150820154309.GB19948@gsp.org>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
 <20150820154309.GB19948@gsp.org>
Message-ID: <CAJB2g-HM7xCHEj--pz4YO-C0m+O+R=CQwqmHZSGOw3JHJSsOkA@mail.gmail.com>

Hi Rich,

Thank you for letting me know, I expected Amazon to actually take care of
spammers and not let it be a free for all. I can definitely switch it
elsewhere, so please let me know what you have in mind.

I can let the mailman server do deliveries as well, so that's a second
option.


Best regards,
Rafael



On Thu, Aug 20, 2015 at 10:43 AM, Rich Kulawiec <rsk at gsp.org> wrote:

>
> It appears that this list is sending its outbound traffic via Amazon's
> cloud operation.
>
> This is a profoundly horrible idea, not through any fault of yours, but
> because Amazon's cloud operation is a massive, non-stop fountain of spam
> and Amazon personnel flatly refuse to lift a finger to do anything about
> it.
> As a result of this incompetence/negligence, some folks out there have
> taken defensive measures which may include firewalling, blocking,
> discarding,
> rejecting, etc.  Thus this is not someplace that you want to try to send
> mail from if you really care about having it delivered.
>
> I recommend moving it elsewhere.  And I'm perfectly willing to assist with
> that (either selecting another location or facilitating the move or both).
>
> ---rsk
>

From alex at pssclabs.com  Thu Aug 20 15:55:19 2015
From: alex at pssclabs.com (Alex Lesser)
Date: Thu, 20 Aug 2015 08:55:19 -0700
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-HM7xCHEj--pz4YO-C0m+O+R=CQwqmHZSGOw3JHJSsOkA@mail.gmail.com>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
 <20150820154309.GB19948@gsp.org>
 <CAJB2g-HM7xCHEj--pz4YO-C0m+O+R=CQwqmHZSGOw3JHJSsOkA@mail.gmail.com>
Message-ID: <55D5F867.7060800@pssclabs.com>

HI Guys:

I must have missed this but where can I sign up for this new mailing list?

Thank you.

Alex


On 8/20/2015 8:51 AM, Rafael Possamai wrote:
> Hi Rich,
>
> Thank you for letting me know, I expected Amazon to actually take care of
> spammers and not let it be a free for all. I can definitely switch it
> elsewhere, so please let me know what you have in mind.
>
> I can let the mailman server do deliveries as well, so that's a second
> option.
>
>
> Best regards,
> Rafael
>
>
>
> On Thu, Aug 20, 2015 at 10:43 AM, Rich Kulawiec <rsk at gsp.org> wrote:
>
>> It appears that this list is sending its outbound traffic via Amazon's
>> cloud operation.
>>
>> This is a profoundly horrible idea, not through any fault of yours, but
>> because Amazon's cloud operation is a massive, non-stop fountain of spam
>> and Amazon personnel flatly refuse to lift a finger to do anything about
>> it.
>> As a result of this incompetence/negligence, some folks out there have
>> taken defensive measures which may include firewalling, blocking,
>> discarding,
>> rejecting, etc.  Thus this is not someplace that you want to try to send
>> mail from if you really care about having it delivered.
>>
>> I recommend moving it elsewhere.  And I'm perfectly willing to assist with
>> that (either selecting another location or facilitating the move or both).
>>
>> ---rsk
>>
> .
>


From clinton at scripty.com  Thu Aug 20 16:10:46 2015
From: clinton at scripty.com (Clinton Work)
Date: Thu, 20 Aug 2015 10:10:46 -0600
Subject: Production-scale NAT64
In-Reply-To: <55D5D9AA.2080203@forethought.net>
References: <55D5D9AA.2080203@forethought.net>
Message-ID: <1440087046.180796.361429465.445F6F60@webmail.messagingengine.com>

The ALU 7750 MS-ISA card can handle 10Gbps of NAT64 traffic and supports
464XLAT as well.  


On Thu, Aug 20, 2015, at 07:44 AM, Jawaid Shell2 wrote:
> Who out there is using production-scale NAT64? What solution are you
> using?

From bill at herrin.us  Thu Aug 20 16:36:09 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 20 Aug 2015 12:36:09 -0400
Subject: Production-scale NAT64
In-Reply-To: <55D5D9AA.2080203@forethought.net>
References: <55D5D9AA.2080203@forethought.net>
Message-ID: <CAP-guGV==1SoDR_PKXVo852+t0c+cojT-poMo5X+cz1PveoNjQ@mail.gmail.com>

On Thu, Aug 20, 2015 at 9:44 AM, Jawaid Shell2 <jb at forethought.net> wrote:
> Who out there is using production-scale NAT64? What solution are you using?

You used "NAT64" and "production" in the same sentence. Good one.

Seriously though, if you want to run a v6-only network and still
support access to IPv4 Internet resources, consider 464XLAT or
DS-Lite.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From cb.list6 at gmail.com  Thu Aug 20 17:22:23 2015
From: cb.list6 at gmail.com (Ca By)
Date: Thu, 20 Aug 2015 10:22:23 -0700
Subject: Production-scale NAT64
In-Reply-To: <CAP-guGV==1SoDR_PKXVo852+t0c+cojT-poMo5X+cz1PveoNjQ@mail.gmail.com>
References: <55D5D9AA.2080203@forethought.net>
 <CAP-guGV==1SoDR_PKXVo852+t0c+cojT-poMo5X+cz1PveoNjQ@mail.gmail.com>
Message-ID: <CAD6AjGT+GeBtwv3far3NJidr6bijQb=TJVB5gh+kkY3xcWg4Vw@mail.gmail.com>

On Thu, Aug 20, 2015 at 9:36 AM, William Herrin <bill at herrin.us> wrote:

> On Thu, Aug 20, 2015 at 9:44 AM, Jawaid Shell2 <jb at forethought.net> wrote:
> > Who out there is using production-scale NAT64? What solution are you
> using?
>
> You used "NAT64" and "production" in the same sentence. Good one.
>
> Seriously though, if you want to run a v6-only network and still
> support access to IPv4 Internet resources, consider 464XLAT or
> DS-Lite.
>
>
NAT64 is a required component of 464XLAT.

And, it runs at very meaningful production scale in non-trivial network
deployments.

CB


> Regards,
> Bill Herrin
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>

From bzs at world.std.com  Thu Aug 20 17:48:28 2015
From: bzs at world.std.com (Barry Shein)
Date: Thu, 20 Aug 2015 13:48:28 -0400
Subject: Data Center operations mail list?
In-Reply-To: <20150820154309.GB19948@gsp.org>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
 <20150820154309.GB19948@gsp.org>
Message-ID: <21974.4844.821770.695932@world.std.com>


FWIW I agree.


On August 20, 2015 at 11:43 rsk at gsp.org (Rich Kulawiec) wrote:
 > 
 > It appears that this list is sending its outbound traffic via Amazon's
 > cloud operation.
 > 
 > This is a profoundly horrible idea, not through any fault of yours, but
 > because Amazon's cloud operation is a massive, non-stop fountain of spam
 > and Amazon personnel flatly refuse to lift a finger to do anything about it.
 > As a result of this incompetence/negligence, some folks out there have
 > taken defensive measures which may include firewalling, blocking, discarding,
 > rejecting, etc.  Thus this is not someplace that you want to try to send
 > mail from if you really care about having it delivered.
 > 
 > I recommend moving it elsewhere.  And I'm perfectly willing to assist with
 > that (either selecting another location or facilitating the move or both).
 > 
 > ---rsk

-- 
        -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 jlmcgraw at gmail.com  Thu Aug 20 18:38:50 2015
From: jlmcgraw at gmail.com (Jesse McGraw)
Date: Thu, 20 Aug 2015 14:38:50 -0400
Subject: On Cisco gear, is it possible to retrieve communities associated
 with a recieved BGP route via SNMP?
Message-ID: <55D61EBA.6060900@gmail.com>

I'm looking through their MIB browser and I don't see anything about 
communities nor anything that sounds likely under bgp4PathAttrEntry

Can anyone point me in the right direction?

From bill at herrin.us  Thu Aug 20 18:49:12 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 20 Aug 2015 14:49:12 -0400
Subject: Production-scale NAT64
In-Reply-To: <CAD6AjGT+GeBtwv3far3NJidr6bijQb=TJVB5gh+kkY3xcWg4Vw@mail.gmail.com>
References: <55D5D9AA.2080203@forethought.net>
 <CAP-guGV==1SoDR_PKXVo852+t0c+cojT-poMo5X+cz1PveoNjQ@mail.gmail.com>
 <CAD6AjGT+GeBtwv3far3NJidr6bijQb=TJVB5gh+kkY3xcWg4Vw@mail.gmail.com>
Message-ID: <CAP-guGVjCZ=fn3bNp9BePfF=cb0CQR2pNwAZibZ99xMvqOffTA@mail.gmail.com>

On Thu, Aug 20, 2015 at 1:22 PM, Ca By <cb.list6 at gmail.com> wrote:
> On Thu, Aug 20, 2015 at 9:36 AM, William Herrin <bill at herrin.us> wrote:
>> Seriously though, if you want to run a v6-only network and still
>> support access to IPv4 Internet resources, consider 464XLAT or
>> DS-Lite.
>
> NAT64 is a required component of 464XLAT.

Sort of, technically, but not really.

NAT64 on its own implies DNS64 and IPv6 client software. Funky
gyrations in the DNS64 server cause the IPv6 software on the client to
originate with IPv6 addresses that the NAT64 server knows how to
convert to IPv4 addresses.

464XLAT does not require DNS64 and provides client software with an
IPv4 interface. IPv4 software that has no idea IPv6 exists sends IPv4
packets which get translated to IPv6 packets. Those packets are routed
to the carrier NAT box which then translates these specially crafted
IPv6 packets back to IPv4 packets.

Functionally, 464XLAT is an IPv6 VPN between your IPv4 client software
and an IPv4 carrier NAT box. Don't let the fact that it's
double-translating instead of encapsulating and decapsulating fool you
-- it's a VPN.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From saper at saper.info  Thu Aug 20 18:56:41 2015
From: saper at saper.info (Marcin Cieslak)
Date: Thu, 20 Aug 2015 18:56:41 +0000
Subject: On Cisco gear, is it possible to retrieve communities associated
 with a recieved BGP route via SNMP?
In-Reply-To: <55D61EBA.6060900@gmail.com>
References: <55D61EBA.6060900@gmail.com>
Message-ID: <alpine.BSF.2.11.1508201852220.52060@z.fncre.vasb>

On Thu, 20 Aug 2015, Jesse McGraw wrote:

> I'm looking through their MIB browser and I don't see anything about
> communities nor anything that sounds likely under bgp4PathAttrEntry
> 
> Can anyone point me in the right direction?

Doesn't seem to be there. Can you check if they
end up as strings with bgp4PathAttrUnknown ?
Although those should be "not understood
by this BGP4 speaker"

~Marcin

From vwittkop at nanog.org  Fri Aug 21 14:32:12 2015
From: vwittkop at nanog.org (Valerie Wittkop)
Date: Fri, 21 Aug 2015 10:32:12 -0400
Subject: [NANOG-announce] ARIN+NANOG On The Road Comes to Chicago!
Message-ID: <807B8BD8-828C-4AC5-B0F0-AE97474E8C04@nanog.org>

We are very excited to be holding the next A+NOTR event in Chicago, IL Tuesday, September 1, and we invite you to join us!

Are you interested in Internet networking/peering? Do you work at a colocation, hosting or data center facility? Are you a provider of hardware/software solutions for the Internet industry?  If so, the ARIN+NANOG On The Road <https://www.nanog.org/meetings/road8/home>NANOG On The Road <https://www.nanog.org/meetings/road7/home> Chicago event is perfect for you!

Date:  September 1, 2015
Time:  Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:30 PM
Location:  Crowne Plaza Downers Grove <https://www.nanog.org/meetings/road8/hotel>C <https://www.nanog.org/meetings/road7/hotel>rowne Plaza Downers Grove - 1250 Roosevelt Road, Glen Ellyn, IL 60137

The FREE to attend event is open for registration.  Register Now! <https://www.cvent.com/events/arin-nanog-on-the-road-chicago-il/registration-345b7b090c6b48e6b1a7a461ff54736f.aspx>

The agenda <https://www.nanog.org/meetings/road8/agenda> is posted - topics to be discussed include:
- Life after IPv4
- Moving to IPv6
- Deploying IPv6
- ARIN Overview and AC Update
- Optical Networking Tutorial
- DoS Tutorial
- BGP Tutorial
- MANRS

If you are, or will be, in the Chicago area, we invite you to attend.  And don?t forget to share the invitation with your colleagues or others you feel may benefit from attending.  Make ARIN+NANOG On The Road your first step toward learning how you can take the wheel and steer the future of the Internet.  

Learn more about On The Road events here <https://www.nanog.org/meetings/road/home>.  Feel free to contact us at nanog-support at nanog.org <mailto:nanog-support at nanog.org> if you have any questions.
Regards,

Valerie

Valerie Wittkop
NANOG Program Director
Tel: +1 866 902 1336, ext 103

-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

From cscora at apnic.net  Fri Aug 21 18:11:39 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 22 Aug 2015 04:11:39 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201508211811.t7LIBdna011688@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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 22 Aug, 2015

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

Analysis Summary
----------------

BGP routing table entries examined:                              556550
    Prefixes after maximum aggregation (per Origin AS):          210045
    Deaggregation factor:                                          2.65
    Unique aggregates announced (without unneeded subnets):      272089
Total ASes present in the Internet Routing Table:                 51223
    Prefixes per ASN:                                             10.87
Origin-only ASes present in the Internet Routing Table:           36684
Origin ASes announcing only one prefix:                           16128
Transit ASes present in the Internet Routing Table:                6359
Transit-only ASes present in the Internet Routing Table:            174
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      45
    Max AS path prepend of ASN ( 55644)                              41
Prefixes from unregistered ASNs in the Routing Table:              1142
    Unregistered ASNs in the Routing Table:                         420
Number of 32-bit ASNs allocated by the RIRs:                      10687
Number of 32-bit ASNs visible in the Routing Table:                8180
Prefixes from 32-bit ASNs in the Routing Table:                   30489
Number of bogon 32-bit ASNs visible in the Routing Table:            21
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            416
Number of addresses announced to Internet:                   2792259968
    Equivalent to 166 /8s, 110 /16s and 129 /24s
    Percentage of available address space announced:               75.4
    Percentage of allocated address space announced:               75.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.6
Total number of prefixes smaller than registry allocations:      185938

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   137303
    Total APNIC prefixes after maximum aggregation:               39854
    APNIC Deaggregation factor:                                    3.45
Prefixes being announced from the APNIC address blocks:          144551
    Unique aggregates announced from the APNIC address blocks:    59281
APNIC Region origin ASes present in the Internet Routing Table:    5084
    APNIC Prefixes per ASN:                                       28.43
APNIC Region origin ASes announcing only one prefix:               1193
APNIC Region transit ASes present in the Internet Routing Table:    890
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         45
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1608
Number of APNIC addresses announced to Internet:              752434240
    Equivalent to 44 /8s, 217 /16s and 60 /24s
    Percentage of available APNIC address space announced:         87.9

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:                    180661
    Total ARIN prefixes after maximum aggregation:                88267
    ARIN Deaggregation factor:                                     2.05
Prefixes being announced from the ARIN address blocks:           183496
    Unique aggregates announced from the ARIN address blocks:     85781
ARIN Region origin ASes present in the Internet Routing Table:    16583
    ARIN Prefixes per ASN:                                        11.07
ARIN Region origin ASes announcing only one prefix:                6064
ARIN Region transit ASes present in the Internet Routing Table:    1738
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          27
Number of ARIN region 32-bit ASNs visible in the Routing Table:     612
Number of ARIN addresses announced to Internet:              1102384576
    Equivalent to 65 /8s, 181 /16s and 13 /24s
    Percentage of available ARIN address space announced:          58.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, 64198-64296, 393216-395164
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:                    134734
    Total RIPE prefixes after maximum aggregation:                67259
    RIPE Deaggregation factor:                                     2.00
Prefixes being announced from the RIPE address blocks:           141525
    Unique aggregates announced from the RIPE address blocks:     87898
RIPE Region origin ASes present in the Internet Routing Table:    17969
    RIPE Prefixes per ASN:                                         7.88
RIPE Region origin ASes announcing only one prefix:                8059
RIPE Region transit ASes present in the Internet Routing Table:    2972
Average RIPE Region AS path length visible:                         4.5
    Max RIPE Region AS path length visible:                          28
Number of RIPE region 32-bit ASNs visible in the Routing Table:    3956
Number of RIPE addresses announced to Internet:               699011712
    Equivalent to 41 /8s, 170 /16s and 18 /24s
    Percentage of available RIPE address space announced:         101.6

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-204287
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:                   60890
    Total LACNIC prefixes after maximum aggregation:              11553
    LACNIC Deaggregation factor:                                   5.27
Prefixes being announced from the LACNIC address blocks:          72356
    Unique aggregates announced from the LACNIC address blocks:   33469
LACNIC Region origin ASes present in the Internet Routing Table:   2462
    LACNIC Prefixes per ASN:                                      29.39
LACNIC Region origin ASes announcing only one prefix:               614
LACNIC Region transit ASes present in the Internet Routing Table:   517
Average LACNIC Region AS path length visible:                       5.1
    Max LACNIC Region AS path length visible:                        28
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1858
Number of LACNIC addresses announced to Internet:             168859904
    Equivalent to 10 /8s, 16 /16s and 153 /24s
    Percentage of available LACNIC address space announced:       100.6

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:                  12280
    Total AfriNIC prefixes after maximum aggregation:              3064
    AfriNIC Deaggregation factor:                                  4.01
Prefixes being announced from the AfriNIC address blocks:         14206
    Unique aggregates announced from the AfriNIC address blocks:   5305
AfriNIC Region origin ASes present in the Internet Routing Table:   739
    AfriNIC Prefixes per ASN:                                     19.22
AfriNIC Region origin ASes announcing only one prefix:              198
AfriNIC Region transit ASes present in the Internet Routing Table:  162
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  146
Number of AfriNIC addresses announced to Internet:             69149696
    Equivalent to 4 /8s, 31 /16s and 36 /24s
    Percentage of available AfriNIC address space announced:       68.7

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     3013      11302         990   Korea Telecom
 7545     2752        339         134   TPG Telecom Limited
17974     2707        904          80   PT Telekomunikasi Indonesia
 4755     2036        426         224   TATA Communications formerly 
 4538     1949       4190          71   China Education and Research 
 9829     1866       1372         196   National Internet Backbone
 9808     1583       8635          17   Guangdong Mobile Communicatio
 9583     1528        121         571   Sify Limited
 4808     1525       2253         473   CNCGROUP IP network China169 
 9498     1379        335         110   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     3161       2960         137   Cox Communications Inc.
 6389     2702       3688          51   BellSouth.net Inc.
 3356     2566      10710         515   Level 3 Communications, Inc.
18566     2147        390         255   MegaPath Corporation
20115     1876       1855         397   Charter Communications
 6983     1738        851         243   EarthLink, Inc.
 4323     1589       1005         411   tw telecom holdings, inc.
30036     1574        319         455   Mediacom Communications Corp
  701     1406      11393         686   MCI Communications Services, 
22561     1373        415         256   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
20940     2075        817        1507   Akamai International B.V.
34984     2011        306         379   TELLCOM ILETISIM HIZMETLERI A
 6849     1207        355          21   JSC "Ukrtelecom"
13188     1068         97          77   TOV "Bank-Inform"
31148     1055         46          24   Freenet Ltd.
 8551      997        376          52   Bezeq International-Ltd
 8402      993        544          15   OJSC "Vimpelcom"
12479      981        933          77   France Telecom Espana SA
 6830      916       2680         469   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     3337        537         159   Telmex Colombia S.A.
28573     2283       2170         126   NET Servi?os de Comunica??o S
 8151     1684       3263         477   Uninet S.A. de C.V.
 7303     1566        931         238   Telecom Argentina S.A.
 6147     1444        374          30   Telefonica del Peru S.A.A.
 6503     1253        421          55   Axtel, S.A.B. de C.V.
26615     1104       2325          35   Tim Celular S.A.
 7738      996       1882          41   Telemar Norte Leste S.A.
 3816      953        436         163   COLOMBIA TELECOMUNICACIONES S
11830      920        364          15   Instituto Costarricense de El

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      909        280          26   Link Egypt (Link.NET)
 8452      873       1470          14   TE-AS
36903      512        258          99   Office National des Postes et
36992      442       1229          32   ETISALAT MISR
37492      315        191          72   Orange Tunisie
24835      308        146          12   Vodafone Data
 3741      252        857         208   Internet Solutions
29571      247         21          13   Cote d'Ivoire Telecom
37054      210         20           7   Data Telecom Service
36947      185        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     3337        537         159   Telmex Colombia S.A.
22773     3161       2960         137   Cox Communications Inc.
 4766     3013      11302         990   Korea Telecom
 7545     2752        339         134   TPG Telecom Limited
17974     2707        904          80   PT Telekomunikasi Indonesia
 6389     2702       3688          51   BellSouth.net Inc.
 3356     2566      10710         515   Level 3 Communications, Inc.
39891     2472        128           6   SaudiNet, Saudi Telecom Compa
28573     2283       2170         126   NET Servi?os de Comunica??o S
18566     2147        390         255   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      3161        3024      Cox Communications Inc.
 6389      2702        2651      BellSouth.net Inc.
17974      2707        2627      PT Telekomunikasi Indonesia
 7545      2752        2618      TPG Telecom Limited
39891      2472        2466      SaudiNet, Saudi Telecom Compa
28573      2283        2157      NET Servi?os de Comunica??o S
 3356      2566        2051      Level 3 Communications, Inc.
 4766      3013        2023      Korea Telecom
18566      2147        1892      MegaPath Corporation
 4538      1949        1878      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
47092   UNALLOCATED  8.8.204.0/24         16410       The Reynolds and Rey
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
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

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.1.0/24        9730     Bharti Telesonic Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
23.249.144.0/21      40430     colo4jax, LLC
23.249.152.0/21      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
31.170.96.0/23       23456     32bit Transition AS
31.217.248.0/21      44902     COVAGE NETWORKS SASU
36.50.0.0/16         23456     32bit Transition AS
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.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:17       /9:13      /10:36      /11:96      /12:263     
/13:504     /14:1003    /15:1732    /16:12892   /17:7238    /18:12394   
/19:25483   /20:35986   /21:38793   /22:61151   /23:53159   /24:302722  
/25:1134    /26:1160    /27:715     /28:14      /29:14      /30:9       
/31:0       /32:22      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2432          2472      SaudiNet, Saudi Telecom Compa
22773     2378          3161      Cox Communications Inc.
18566     2062          2147      MegaPath Corporation
 6389     1608          2702      BellSouth.net Inc.
30036     1395          1574      Mediacom Communications Corp
 6983     1385          1738      EarthLink, Inc.
34984     1331          2011      TELLCOM ILETISIM HIZMETLERI A
10620     1210          3337      Telmex Colombia S.A.
11492     1112          1195      CABLE ONE, INC.
22561     1046          1373      CenturyTel Internet Holdings,

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1540      2:690       4:97        5:1870      6:25        8:1393   
  12:1805     13:14       14:1405     15:16       16:2        17:43     
  18:22       20:49       23:1315     24:1739     27:2041     31:1583   
  32:37       33:2        34:4        35:3        36:164      37:2017   
  38:1037     39:14       40:70       41:2750     42:310      43:1463   
  44:30       45:1031     46:2381     47:53       49:932      50:787    
  52:19       54:84       55:7        56:27       57:42       58:1355   
  59:720      60:481      61:1755     62:1368     63:1900     64:4434   
  65:2254     66:4024     67:2062     68:1066     69:3221     70:1034   
  71:449      72:1973     74:2596     75:352      76:393      77:1309   
  78:1153     79:813      80:1345     81:1346     82:870      83:720    
  84:781      85:1389     86:451      87:1036     88:539      89:1946   
  90:149      91:5941     92:842      93:2275     94:2082     95:2192   
  96:414      97:347      98:980      99:55      100:75      101:845    
 103:8086    104:2020    105:72      106:348     107:1064    108:621    
 109:2131    110:1198    111:1462    112:817     113:1103    114:856    
 115:1298    116:1468    117:1080    118:1894    119:1467    120:457    
 121:1089    122:2163    123:1841    124:1528    125:1623    128:666    
 129:395     130:431     131:1250    132:522     133:171     134:409    
 135:103     136:338     137:312     138:1120    139:144     140:243    
 141:491     142:669     143:545     144:546     145:126     146:800    
 147:587     148:1260    149:429     150:553     151:801     152:528    
 153:253     154:496     155:874     156:423     157:424     158:344    
 159:1031    160:411     161:680     162:2026    163:457     164:693    
 165:708     166:299     167:856     168:1253    169:190     170:1474   
 171:255     172:248     173:1501    174:719     175:699     176:1428   
 177:3934    178:2183    179:991     180:1939    181:1666    182:1798   
 183:636     184:746     185:4109    186:2917    187:1811    188:2071   
 189:1607    190:7829    191:1152    192:8640    193:5661    194:4228   
 195:3650    196:1984    197:1051    198:5630    199:5508    200:6688   
 201:3302    202:9518    203:9158    204:4681    205:2881    206:3022   
 207:2984    208:4011    209:3920    210:3599    211:1919    212:2536   
 213:2307    214:861     215:75      216:5730    217:1825    218:733    
 219:466     220:1553    221:810     222:474     223:816    

End of report

From cidr-report at potaroo.net  Fri Aug 21 22:00:01 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 21 Aug 2015 22:00:01 GMT
Subject: The Cidr Report
Message-ID: <201508212200.t7LM01tx096031@wattle.apnic.net>

This report has been generated at Fri Aug 21 21:14:46 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
        14-08-15    564268      309611
        15-08-15    564430      309365
        16-08-15    564233      309614
        17-08-15    564542      307326
        18-08-15    564538      307667
        19-08-15    564899      306970
        20-08-15    565630      307293
        21-08-15    565311      307600


AS Summary
         51524  Number of ASes in routing system
         20434  Number of ASes announcing only one prefix
          3354  Largest number of prefixes announced by an AS
                AS10620: Telmex Colombia S.A.,CO
      120888576  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').

 --- 21Aug15 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     565515   307588   257927    45.6%   All ASes

AS22773     3163      167     2996    94.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS6389      2701       69     2632    97.4%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS17974     2707       80     2627    97.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS39891     2473       32     2441    98.7%   ALJAWWALSTC-AS Saudi Telecom
                                               Company JSC,SA
AS28573     2278      139     2139    93.9%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS7545      2898      809     2089    72.1%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS9394      2290      318     1972    86.1%   CTTNET China TieTong
                                               Telecommunications
                                               Corporation,CN
AS10620     3354     1614     1740    51.9%   Telmex Colombia S.A.,CO
AS4766      3013     1283     1730    57.4%   KIXS-AS-KR Korea Telecom,KR
AS4755      2034      408     1626    79.9%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS9808      1583       74     1509    95.3%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS6983      1737      246     1491    85.8%   ITCDELTA - Earthlink, Inc.,US
AS20115     1876      410     1466    78.1%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS9498      1379      120     1259    91.3%   BBIL-AP BHARTI Airtel Ltd.,IN
AS18566     2148      956     1192    55.5%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS4323      1596      413     1183    74.1%   TWTC - tw telecom holdings,
                                               inc.,US
AS6147      1444      278     1166    80.7%   Telefonica del Peru S.A.A.,PE
AS6849      1208       74     1134    93.9%   UKRTELNET JSC UKRTELECOM,UA
AS3356      2570     1521     1049    40.8%   LEVEL3 - Level 3
                                               Communications, Inc.,US
AS22561     1373      328     1045    76.1%   CENTURYLINK-LEGACY-LIGHTCORE -
                                               CenturyTel Internet Holdings,
                                               Inc.,US
AS7303      1566      527     1039    66.3%   Telecom Argentina S.A.,AR
AS4808      1543      513     1030    66.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network,CN
AS7552      1126      134      992    88.1%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS8151      1691      726      965    57.1%   Uninet S.A. de C.V.,MX
AS8402       977       21      956    97.9%   CORBINA-AS OJSC "Vimpelcom",RU
AS26615     1104      149      955    86.5%   Tim Celular S.A.,BR
AS7738       996       77      919    92.3%   Telemar Norte Leste S.A.,BR
AS38285      982      133      849    86.5%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU
AS18881      873       33      840    96.2%   Global Village Telecom,BR
AS4538      1967     1154      813    41.3%   ERX-CERNET-BKB China Education
                                               and Research Network
                                               Center,CN

Total      56650    12806    43844    77.4%   Top 30 total


Possible Bogus Routes

        23.226.112.0/20      AS62788 -Reserved AS-,ZZ
        23.249.144.0/20      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        23.249.144.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        23.249.152.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        27.100.7.0/24        AS56096 
        31.170.96.0/23       AS19798 YOUZEE-MAIN Manaslu Media Entertainment SL,ES
        31.217.248.0/21      AS44902 COV-ASN COVAGE NETWORKS SASU,FR
        36.50.0.0/16         AS20418 MOSMOG-AS OJSC TORGOVYJ DOM MOSKVA-MOGILEV,RU
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.3.0/24         AS37004 -Reserved AS-,ZZ
        41.73.4.0/24         AS37004 -Reserved AS-,ZZ
        41.73.5.0/24         AS37004 -Reserved AS-,ZZ
        41.73.6.0/24         AS37004 -Reserved AS-,ZZ
        41.73.7.0/24         AS37004 -Reserved AS-,ZZ
        41.73.8.0/24         AS37004 -Reserved AS-,ZZ
        41.73.9.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.14.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.17.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.126.0/24      AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        41.189.127.0/24      AS37000 -Reserved AS-,ZZ
        41.189.128.0/24      AS37000 -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
        43.246.188.0/22      AS38850 TIGC-AS-TW Taiwan International Gateway Corporation,TW
        45.254.196.0/24      AS31972 EMGINECONCEPT-01 - Emagine Concept, Inc.,US
        64.28.145.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.28.146.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.57.192.0/22       AS33321 -Reserved AS-,ZZ
        64.234.239.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.,US
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.,US
        66.11.224.0/21       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.234.0/24       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.236.0/22       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.59.192.0/19       AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.228.160.0/20      AS7233  YAHOO-US - Yahoo,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
        68.234.0.0/19        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.0.0/20        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.5.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.7.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.16.0/20       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.16.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.17.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.18.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.19.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.20.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.21.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.22.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.23.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.24.0/22       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.26.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.28.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.29.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        69.24.96.0/20        AS26804 -Reserved AS-,ZZ
        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.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
        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
        100.64.8.0/24        AS10620 Telmex Colombia S.A.,CO
        100.64.11.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.12.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.22.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.23.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.24.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.25.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.26.0/24       AS10620 Telmex Colombia S.A.,CO
        100.64.27.0/24       AS10620 Telmex Colombia S.A.,CO
        100.100.1.0/24       AS9730  BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN
        103.10.222.0/24      AS13189 
        103.11.16.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.13.1.0/24        AS58609 
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.44.0/24       AS18351 
        103.18.45.0/24       AS18351 
        103.18.47.0/24       AS18351 
        103.20.100.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.101.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.219.0/24      AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU
        103.22.212.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.23.148.0/23      AS13209 
        103.23.148.0/24      AS13209 
        103.23.149.0/24      AS13209 
        103.25.144.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.225.116.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.228.8.0/22       AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.229.152.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.232.142.0/23     AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG
        103.232.164.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.233.140.0/23     AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF
        103.234.8.0/22       AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.244.112.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.52.0/22      AS2519  VECTANT VECTANT Ltd.,JP
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.196.0/22     AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.250.220.0/24     AS58973 
        103.250.221.0/24     AS58973 
        103.253.164.0/23     AS13317 
        116.12.32.0/21       AS38555 
        116.12.32.0/24       AS38555 
        116.199.203.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.205.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.206.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.207.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        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
        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.221.64.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        162.221.64.0/22      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        162.221.68.0/22      AS40430 COLO4JAX-AS - colo4jax, 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.88.48.0/20       AS29927 -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
        173.249.191.0/24     AS45816 ISHK-AP I-Services Network Solution Limited,HK
        180.222.120.0/21     AS23818 JETINTERNET JETINTERNET Corporation,JP
        181.225.156.0/22     AS10834 Telefonica de Argentina,AR
        185.17.98.0/23       AS19798 HILF-AS Hilf Telecom B.V.,NL
        185.52.57.0/24       AS48039 KGT-AS KGT new media,DE
        185.52.58.0/24       AS48039 KGT-AS KGT new media,DE
        186.148.224.0/21     AS52302 Awknet International, S.A.,PA
        189.14.112.0/20      AS52720 WEBFOCO TELECOMUNICACOES LTDA,BR
        189.14.116.0/22      AS28282 -Reserved AS-,ZZ
        189.14.120.0/22      AS28282 -Reserved AS-,ZZ
        189.14.124.0/22      AS28282 -Reserved AS-,ZZ
        192.9.0.0/16         AS11479 BRM-SUN-AS - Oracle Corporation,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.67.160.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.67.161.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.67.162.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.75.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.46.0/23      AS17139 NETRANGE - Corporate Colocation 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.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.206.140.0/24     AS54926 -Reserved AS-,ZZ
        192.206.141.0/24     AS54926 -Reserved AS-,ZZ
        192.206.142.0/24     AS54926 -Reserved AS-,ZZ
        192.206.143.0/24     AS54926 -Reserved AS-,ZZ
        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.22.224.0/20      AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        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.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.56.203.0/24      AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR
        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.151.160.0/19     AS39906 COPROSYS CoProSys a.s.,CZ
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        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.130.0/24     AS21104 AM-NETSYS-AS Netsys JV LLC,AM
        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.8.0/21       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.9.9.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.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.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        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.180.0/24       AS37004 -Reserved AS-,ZZ
        196.3.181.0/24       AS37004 -Reserved AS-,ZZ
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        196.22.11.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        198.8.72.0/21        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.72.0/22        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.76.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.77.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.78.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.79.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,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.91.44.0/22       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.44.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.45.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.46.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.47.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,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.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.103.89.0/24      AS19523 -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.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
        201.131.5.0/24       AS28389 -Reserved AS-,ZZ
        201.131.88.0/24      AS8151  Uninet S.A. de C.V.,MX
        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.133.208.0/20     AS17440 IDNIC-ID Indonesia Network Information Center,ID
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom,SG
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK
        203.78.130.0/24      AS18222 
        203.142.219.0/24     AS45149 
        203.160.48.0/21      AS38008 
        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.153.206.0/23     AS3561  CENTURYLINK-LEGACY-SAVVIS - Savvis,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.44.0/24       AS11065 -Reserved AS-,ZZ
        208.67.45.0/24       AS11065 -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.74.12.0/23       AS209   CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.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.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 Aug 21 22:00:02 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 21 Aug 2015 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201508212200.t7LM02gK096046@wattle.apnic.net>

BGP Update Report
Interval: 13-Aug-15 -to- 20-Aug-15 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS38197          218503  3.7%     169.5 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK
 2 - AS9829           186659  3.2%     100.0 -- BSNL-NIB National Internet Backbone,IN
 3 - AS22059          129550  2.2%   18507.1 -- -Reserved AS-,ZZ
 4 - AS36947           83141  1.4%     386.7 -- ALGTEL-AS,DZ
 5 - AS3709            57957  1.0%    2146.6 -- NET-CITY-SA - City of San Antonio,US
 6 - AS13188           44407  0.8%      41.6 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA
 7 - AS39891           39019  0.7%      15.8 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA
 8 - AS38478           35395  0.6%     211.9 -- SUNNYVISION-AS-AP SunnyVision Limited,HK
 9 - AS8402            35278  0.6%      31.8 -- CORBINA-AS OJSC "Vimpelcom",RU
10 - AS25563           33157  0.6%    8289.2 -- WEBLAND-AS Webland AG,CH
11 - AS28573           30880  0.5%      12.6 -- NET Servi?os de Comunica??o S.A.,BR
12 - AS30295           30458  0.5%    3807.2 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
13 - AS2088            29944  0.5%    7486.0 -- FR-RENATER-MAYOTTE Reseau National de telecommunications pour la Technologie,EU
14 - AS56636           29237  0.5%   29237.0 -- ASVEDARU VEDA Ltd.,RU
15 - AS131090           29111  0.5%      76.8 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
16 - AS197068           28243  0.5%    1882.9 -- QRATOR HLL LLC,RU
17 - AS10620           24676  0.4%       7.4 -- Telmex Colombia S.A.,CO
18 - AS25438           20172  0.3%     190.3 -- ASN-ICCNET International Computer Company, Ltd.,SA
19 - AS1505            19071  0.3%    1733.7 -- DNIC-AS-01505 - Headquarters, USAISC,US
20 - AS8151            16892  0.3%       9.5 -- Uninet S.A. de C.V.,MX


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS56636           29237  0.5%   29237.0 -- ASVEDARU VEDA Ltd.,RU
 2 - AS22059          129550  2.2%   18507.1 -- -Reserved AS-,ZZ
 3 - AS40493           10663  0.2%   10663.0 -- FACILITYSOURCEINC - FacilitySource,US
 4 - AS393588            9571  0.2%    9571.0 -- MUBEA-FLO - Mubea,US
 5 - AS37590            8853  0.1%    8853.0 -- BCA-ASN,AO
 6 - AS25563           33157  0.6%    8289.2 -- WEBLAND-AS Webland AG,CH
 7 - AS2088            29944  0.5%    7486.0 -- FR-RENATER-MAYOTTE Reseau National de telecommunications pour la Technologie,EU
 8 - AS200671            4445  0.1%    4445.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL
 9 - AS25265            3815  0.1%    3815.0 -- VELTON-AS VELTON.TELECOM Ltd,UA
10 - AS30295           30458  0.5%    3807.2 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
11 - AS31357           14877  0.2%    2975.4 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
12 - AS197914            8421  0.1%    2807.0 -- STOCKHO-AS Stockho Hosting SARL,FR
13 - AS45606           12046  0.2%    2409.2 -- 
14 - AS327739            2268  0.0%    2268.0 -- Kili-io,KE
15 - AS3709            57957  1.0%    2146.6 -- NET-CITY-SA - City of San Antonio,US
16 - AS59219            2033  0.0%    2033.0 -- MOIC-BT Ministry of Information & Communications,BT
17 - AS200562            1911  0.0%    1911.0 -- WELLTEL-IE WELLTEL (IRELAND) LTD,IE
18 - AS197068           28243  0.5%    1882.9 -- QRATOR HLL LLC,RU
19 - AS1505            19071  0.3%    1733.7 -- DNIC-AS-01505 - Headquarters, USAISC,US
20 - AS60572            1681  0.0%    1681.0 -- ZENEXITY-AS Zenexity SARL,FR


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 105.96.0.0/22     80433  1.2%   AS36947 -- ALGTEL-AS,DZ
 2 - 64.34.125.0/24    64768  1.0%   AS22059 -- -Reserved AS-,ZZ
 3 - 76.191.107.0/24   64757  1.0%   AS22059 -- -Reserved AS-,ZZ
 4 - 195.128.159.0/24  29237  0.5%   AS56636 -- ASVEDARU VEDA Ltd.,RU
 5 - 185.65.148.0/24   28171  0.4%   AS197068 -- QRATOR HLL LLC,RU
 6 - 61.7.155.0/24     24683  0.4%   AS131090 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
 7 - 78.140.0.0/18     14816  0.2%   AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
 8 - 92.43.216.0/21    11332  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
 9 - 66.19.194.0/24    11257  0.2%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.,US
10 - 185.84.192.0/22   10991  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
11 - 178.174.96.0/19   10829  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
12 - 201.77.141.0/24   10726  0.2%   AS28654 -- Axtelecom Telecomunica??es Ltda,BR
13 - 8.17.26.0/24      10663  0.2%   AS40493 -- FACILITYSOURCEINC - FacilitySource,US
14 - 199.60.236.0/24   10639  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
15 - 199.60.234.0/23   10419  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
16 - 192.58.137.0/24    9571  0.1%   AS393588 -- MUBEA-FLO - Mubea,US
17 - 199.60.233.0/24    9376  0.1%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
18 - 196.6.255.0/24     8853  0.1%   AS37590 -- BCA-ASN,AO
19 - 94.73.56.0/21      8582  0.1%   AS42081 -- SPEEDY-NET-AS Speedy net AD,BG
20 - 130.0.192.0/21     8381  0.1%   AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR

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 rafael at gav.ufsc.br  Sat Aug 22 01:18:59 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Fri, 21 Aug 2015 20:18:59 -0500
Subject: Data Center operations mail list?
In-Reply-To: <20150820154309.GB19948@gsp.org>
References: <34F8A3E4-8527-49D4-940D-B4B058C86520@gizmopartners.com>
 <BY1PR0501MB1462AA81C6543FA794D97A87B47F0@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
 <20150820154309.GB19948@gsp.org>
Message-ID: <CAJB2g-H+5J-LwmDKX2gmdmDsrvXTq0ksAsu+tkazYjjic3Qexw@mail.gmail.com>

Quick update: I moved away from Amazon SES to a private smtp server
provided by Chris, who is also helping moderate the list.

I left Amazon SES configured as a backup since the bounce rate after
thousands of emails peaked at only 0.08%

Thanks!


Rafael



On Thu, Aug 20, 2015 at 10:43 AM, Rich Kulawiec <rsk at gsp.org> wrote:

>
> It appears that this list is sending its outbound traffic via Amazon's
> cloud operation.
>
> This is a profoundly horrible idea, not through any fault of yours, but
> because Amazon's cloud operation is a massive, non-stop fountain of spam
> and Amazon personnel flatly refuse to lift a finger to do anything about
> it.
> As a result of this incompetence/negligence, some folks out there have
> taken defensive measures which may include firewalling, blocking,
> discarding,
> rejecting, etc.  Thus this is not someplace that you want to try to send
> mail from if you really care about having it delivered.
>
> I recommend moving it elsewhere.  And I'm perfectly willing to assist with
> that (either selecting another location or facilitating the move or both).
>
> ---rsk
>

From rsk at gsp.org  Sat Aug 22 01:46:00 2015
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 21 Aug 2015 21:46:00 -0400
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-H+5J-LwmDKX2gmdmDsrvXTq0ksAsu+tkazYjjic3Qexw@mail.gmail.com>
References: <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
 <20150820154309.GB19948@gsp.org>
 <CAJB2g-H+5J-LwmDKX2gmdmDsrvXTq0ksAsu+tkazYjjic3Qexw@mail.gmail.com>
Message-ID: <20150822014600.GA26949@gsp.org>

On Fri, Aug 21, 2015 at 08:18:59PM -0500, Rafael Possamai wrote:
> Quick update: I moved away from Amazon SES to a private smtp server
> provided by Chris, who is also helping moderate the list.

That's a good idea.  I noticed.

> I left Amazon SES configured as a backup since the bounce rate after
> thousands of emails peaked at only 0.08%

The bounce rate is not an effective metric, for a number of reasons, not
the least of which is that some unknown and unknowable number of sites
are configured to quarantine email.  (This is a horrible idea that I've
railed against many times, but that notwithstanding, ignorant people do it
every day.)  Any site which quarantines mail will not generate a bounce
(or a reject) but will silently consign incoming traffic to a location
which may, or may not, be eventually seen by a human being.

The bounce rate yields precisely zero insight into the extent of this
problem.  Nor does it yield any insight into other similar (related)
problems which are not manifested via the SMTP transaction.

The best course here is to completely avoid any contact with the
horribly-mismanaged Amazon cloud operation until such time as those
running it demonstrate a bare minimum of professionalism -- which,
to date, they have unfortunately not.  In this particular case, it
would be preferable to defer/queue any outbound mail traffic instead of
attempting to deliver via Amazon: there is unlikely to be anything
traversing that mailing list which would suffer by being delayed
by an hour or a day.

---rsk


From nanog at ics-il.net  Sat Aug 22 01:49:10 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Fri, 21 Aug 2015 20:49:10 -0500 (CDT)
Subject: Data Center operations mail list?
In-Reply-To: <20150822014600.GA26949@gsp.org>
Message-ID: <1523913995.6611.1440208193405.JavaMail.mhammett@ThunderFuck>

I'm on a mailing list hosted at Amazon, uses their API, etc. Other than the bumps in the migration to Amazon, I haven't seen any real issues. Hundreds of people on the list posting hundreds (total, not each) of messages per day. No complaints. *shrugs* 




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

----- Original Message -----

From: "Rich Kulawiec" <rsk at gsp.org> 
To: "Rafael Possamai" <rafael at gav.ufsc.br> 
Cc: nanog at nanog.org 
Sent: Friday, August 21, 2015 8:46:00 PM 
Subject: Re: Data Center operations mail list? 

On Fri, Aug 21, 2015 at 08:18:59PM -0500, Rafael Possamai wrote: 
> Quick update: I moved away from Amazon SES to a private smtp server 
> provided by Chris, who is also helping moderate the list. 

That's a good idea. I noticed. 

> I left Amazon SES configured as a backup since the bounce rate after 
> thousands of emails peaked at only 0.08% 

The bounce rate is not an effective metric, for a number of reasons, not 
the least of which is that some unknown and unknowable number of sites 
are configured to quarantine email. (This is a horrible idea that I've 
railed against many times, but that notwithstanding, ignorant people do it 
every day.) Any site which quarantines mail will not generate a bounce 
(or a reject) but will silently consign incoming traffic to a location 
which may, or may not, be eventually seen by a human being. 

The bounce rate yields precisely zero insight into the extent of this 
problem. Nor does it yield any insight into other similar (related) 
problems which are not manifested via the SMTP transaction. 

The best course here is to completely avoid any contact with the 
horribly-mismanaged Amazon cloud operation until such time as those 
running it demonstrate a bare minimum of professionalism -- which, 
to date, they have unfortunately not. In this particular case, it 
would be preferable to defer/queue any outbound mail traffic instead of 
attempting to deliver via Amazon: there is unlikely to be anything 
traversing that mailing list which would suffer by being delayed 
by an hour or a day. 

---rsk 



From rafael at gav.ufsc.br  Sat Aug 22 02:03:42 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Fri, 21 Aug 2015 21:03:42 -0500
Subject: Data Center operations mail list?
In-Reply-To: <1523913995.6611.1440208193405.JavaMail.mhammett@ThunderFuck>
References: <20150822014600.GA26949@gsp.org>
 <1523913995.6611.1440208193405.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAJB2g-ESJZxqkyZZLBDhAzsgU0WW1kWn=Ga1=qrYdpJbGUD2Uw@mail.gmail.com>

My 2 cents: I use it for other services and haven't had any issues over the
past few months, but one problem I was having with SES + Mailman is that
even though my account was out of their sandbox, I still had some smtp
errors due to "email not verified" which is annoying. So I had to tell
mailman to wrap every message, hence the via NADCOG you probably seen
before. Now that option is back to default by using Chris' server.

Their support sent me a canned message so I decided not to waste too much
time there. As long as 99% of members get their emails I don't think it
really matters whose server they are going through.

Honestly, most things out there are designed to fit the 95th percentile
scale, so if you are on either extreme, one is better off figuring out how
to adapt than to require the whole system to change, that is, if your email
server is blocking more messages than it should, fix your email server,
don't try to fix the whole world wide web.







On Fri, Aug 21, 2015 at 8:49 PM, Mike Hammett <nanog at ics-il.net> wrote:

> I'm on a mailing list hosted at Amazon, uses their API, etc. Other than
> the bumps in the migration to Amazon, I haven't seen any real issues.
> Hundreds of people on the list posting hundreds (total, not each) of
> messages per day. No complaints. *shrugs*
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> ----- Original Message -----
>
> From: "Rich Kulawiec" <rsk at gsp.org>
> To: "Rafael Possamai" <rafael at gav.ufsc.br>
> Cc: nanog at nanog.org
> Sent: Friday, August 21, 2015 8:46:00 PM
> Subject: Re: Data Center operations mail list?
>
> On Fri, Aug 21, 2015 at 08:18:59PM -0500, Rafael Possamai wrote:
> > Quick update: I moved away from Amazon SES to a private smtp server
> > provided by Chris, who is also helping moderate the list.
>
> That's a good idea. I noticed.
>
> > I left Amazon SES configured as a backup since the bounce rate after
> > thousands of emails peaked at only 0.08%
>
> The bounce rate is not an effective metric, for a number of reasons, not
> the least of which is that some unknown and unknowable number of sites
> are configured to quarantine email. (This is a horrible idea that I've
> railed against many times, but that notwithstanding, ignorant people do it
> every day.) Any site which quarantines mail will not generate a bounce
> (or a reject) but will silently consign incoming traffic to a location
> which may, or may not, be eventually seen by a human being.
>
> The bounce rate yields precisely zero insight into the extent of this
> problem. Nor does it yield any insight into other similar (related)
> problems which are not manifested via the SMTP transaction.
>
> The best course here is to completely avoid any contact with the
> horribly-mismanaged Amazon cloud operation until such time as those
> running it demonstrate a bare minimum of professionalism -- which,
> to date, they have unfortunately not. In this particular case, it
> would be preferable to defer/queue any outbound mail traffic instead of
> attempting to deliver via Amazon: there is unlikely to be anything
> traversing that mailing list which would suffer by being delayed
> by an hour or a day.
>
> ---rsk
>
>
>

From nanog at ics-il.net  Sat Aug 22 02:10:12 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Fri, 21 Aug 2015 21:10:12 -0500 (CDT)
Subject: Data Center operations mail list?
In-Reply-To: <CAJB2g-ESJZxqkyZZLBDhAzsgU0WW1kWn=Ga1=qrYdpJbGUD2Uw@mail.gmail.com>
Message-ID: <1822010765.6631.1440209453396.JavaMail.mhammett@ThunderFuck>

AFMUG got that straightened out. I don't know the details of how. 




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

----- Original Message -----

From: "Rafael Possamai" <rafael at gav.ufsc.br> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: nanog at nanog.org 
Sent: Friday, August 21, 2015 9:03:42 PM 
Subject: Re: Data Center operations mail list? 


My 2 cents: I use it for other services and haven't had any issues over the past few months, but one problem I was having with SES + Mailman is that even though my account was out of their sandbox, I still had some smtp errors due to "email not verified" which is annoying. So I had to tell mailman to wrap every message, hence the via NADCOG you probably seen before. Now that option is back to default by using Chris' server. 



Their support sent me a canned message so I decided not to waste too much time there. As long as 99% of members get their emails I don't think it really matters whose server they are going through. 


Honestly, most things out there are designed to fit the 95th percentile scale, so if you are on either extreme, one is better off figuring out how to adapt than to require the whole system to change, that is, if your email server is blocking more messages than it should, fix your email server, don't try to fix the whole world wide web. 














On Fri, Aug 21, 2015 at 8:49 PM, Mike Hammett < nanog at ics-il.net > wrote: 


I'm on a mailing list hosted at Amazon, uses their API, etc. Other than the bumps in the migration to Amazon, I haven't seen any real issues. Hundreds of people on the list posting hundreds (total, not each) of messages per day. No complaints. *shrugs* 




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

----- Original Message ----- 

From: "Rich Kulawiec" < rsk at gsp.org > 
To: "Rafael Possamai" < rafael at gav.ufsc.br > 
Cc: nanog at nanog.org 
Sent: Friday, August 21, 2015 8:46:00 PM 
Subject: Re: Data Center operations mail list? 

On Fri, Aug 21, 2015 at 08:18:59PM -0500, Rafael Possamai wrote: 
> Quick update: I moved away from Amazon SES to a private smtp server 
> provided by Chris, who is also helping moderate the list. 

That's a good idea. I noticed. 

> I left Amazon SES configured as a backup since the bounce rate after 
> thousands of emails peaked at only 0.08% 

The bounce rate is not an effective metric, for a number of reasons, not 
the least of which is that some unknown and unknowable number of sites 
are configured to quarantine email. (This is a horrible idea that I've 
railed against many times, but that notwithstanding, ignorant people do it 
every day.) Any site which quarantines mail will not generate a bounce 
(or a reject) but will silently consign incoming traffic to a location 
which may, or may not, be eventually seen by a human being. 

The bounce rate yields precisely zero insight into the extent of this 
problem. Nor does it yield any insight into other similar (related) 
problems which are not manifested via the SMTP transaction. 

The best course here is to completely avoid any contact with the 
horribly-mismanaged Amazon cloud operation until such time as those 
running it demonstrate a bare minimum of professionalism -- which, 
to date, they have unfortunately not. In this particular case, it 
would be preferable to defer/queue any outbound mail traffic instead of 
attempting to deliver via Amazon: there is unlikely to be anything 
traversing that mailing list which would suffer by being delayed 
by an hour or a day. 

---rsk 







From nanog at ics-il.net  Sun Aug 23 20:57:44 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 23 Aug 2015 15:57:44 -0500 (CDT)
Subject: Quanta LB4M
In-Reply-To: <1457DAD1-A34C-41F5-B02C-6D992819FA2B@puck.nether.net>
Message-ID: <1197305683.171.1440363513455.JavaMail.mhammett@ThunderFuck>

I noticed that one I have already has the 1.1.0.8 firmware. Upon switching to it, I noticed that I gained SSH, but lost HTTP. Has anyone else seen that? 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Jared Mauch" <jared at puck.nether.net> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Sunday, June 28, 2015 2:56:17 PM 
Subject: Re: Quanta LB4M 


> On Jun 28, 2015, at 2:50 PM, Mike Hammett <nanog at ics-il.net> wrote: 
> 
> Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." 

I managed to brick one of these by loading the wrong firmware, or doing it at the wrong layer. 

I have gotten a few more and these are great switches for home or environment where you have a spare on hand. You can usually get them for around $100 on eBay. 

The firmware is *really* not designed for anything fancy but I?ve been able to drop in a variety of optics and have it work without issues in the 10G ports. 

Check the flash on them as there is a primary/secondary flash once you?re past the boot image. (Don?t try to flash it from that level, that?s how I killed it at least). 

I tossed a few different firmware versions I extracted here, as well as the flash0/flash1 images and the doc i found for it. 

http://puck.nether.net/~jared/lb4m/ 

- Jared 

From ryan at finnesey.com  Mon Aug 24 05:43:11 2015
From: ryan at finnesey.com (Ryan Finnesey)
Date: Mon, 24 Aug 2015 05:43:11 +0000
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
Message-ID: <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>

Was Google charging ISPs for this service?

Cheers
Ryan


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Greene
Sent: Tuesday, August 18, 2015 2:18 PM
To: Shawn L <shawnl at up.net>
Cc: nanog <nanog at nanog.org>
Subject: Re: Google Apps for ISPs -- Lingering fallout

You?ll need to escalate this with Google. If the front-end support team cannot help, move up the chain as far as you can. It should eventually reach the PM that worked on the turn-down of that service and get some action.

--
Gary L. Greene, Jr.
Sr. Systems Administrator
IT Operations
Minerva Networks, Inc.
Cell: +1 (650) 704-6633




> On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
> 
> 
> I know there are others on this list who used Google Apps for ISPs and recently migrated off (as the service was discontinued).
> 
> We have had several cases where the user had a YouTube channel or Picasa photo albums, etc. that they created with their Google Apps for ISPs credentials.  Now that the service is gone, those channels and albums still exist but the users are unable to login to them or manage them in any way because it tells them that their account has been disabled.
> 
> Of course, Google had been un-responsive to all of our (and the customer's) inquiries about how to fix this.
> 
> Has anyone else run into this and found a way around it?
> 
> thanks
> 
> 
> Shawn
> 


From josh at imaginenetworksllc.com  Mon Aug 24 12:33:23 2015
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Mon, 24 Aug 2015 08:33:23 -0400
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
Message-ID: <CAN9qwJ9uqcOrsy1dK98guinY-AYk76U=-2av+M3i7kN2Vvtp6w@mail.gmail.com>

Initially no.  After a while yes.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Aug 24, 2015 1:44 AM, "Ryan Finnesey" <ryan at finnesey.com> wrote:

> Was Google charging ISPs for this service?
>
> Cheers
> Ryan
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Greene
> Sent: Tuesday, August 18, 2015 2:18 PM
> To: Shawn L <shawnl at up.net>
> Cc: nanog <nanog at nanog.org>
> Subject: Re: Google Apps for ISPs -- Lingering fallout
>
> You?ll need to escalate this with Google. If the front-end support team
> cannot help, move up the chain as far as you can. It should eventually
> reach the PM that worked on the turn-down of that service and get some
> action.
>
> --
> Gary L. Greene, Jr.
> Sr. Systems Administrator
> IT Operations
> Minerva Networks, Inc.
> Cell: +1 (650) 704-6633
>
>
>
>
> > On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
> >
> >
> > I know there are others on this list who used Google Apps for ISPs and
> recently migrated off (as the service was discontinued).
> >
> > We have had several cases where the user had a YouTube channel or Picasa
> photo albums, etc. that they created with their Google Apps for ISPs
> credentials.  Now that the service is gone, those channels and albums still
> exist but the users are unable to login to them or manage them in any way
> because it tells them that their account has been disabled.
> >
> > Of course, Google had been un-responsive to all of our (and the
> customer's) inquiries about how to fix this.
> >
> > Has anyone else run into this and found a way around it?
> >
> > thanks
> >
> >
> > Shawn
> >
>
>

From khelms at zcorum.com  Mon Aug 24 12:34:48 2015
From: khelms at zcorum.com (Scott Helms)
Date: Mon, 24 Aug 2015 08:34:48 -0400
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
Message-ID: <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>

Ryan,

Most certainly, the charges varied some  because of size and other factors
but it was around 25 cents monthly per Gmail box.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey <ryan at finnesey.com> wrote:

> Was Google charging ISPs for this service?
>
> Cheers
> Ryan
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Greene
> Sent: Tuesday, August 18, 2015 2:18 PM
> To: Shawn L <shawnl at up.net>
> Cc: nanog <nanog at nanog.org>
> Subject: Re: Google Apps for ISPs -- Lingering fallout
>
> You?ll need to escalate this with Google. If the front-end support team
> cannot help, move up the chain as far as you can. It should eventually
> reach the PM that worked on the turn-down of that service and get some
> action.
>
> --
> Gary L. Greene, Jr.
> Sr. Systems Administrator
> IT Operations
> Minerva Networks, Inc.
> Cell: +1 (650) 704-6633
>
>
>
>
> > On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
> >
> >
> > I know there are others on this list who used Google Apps for ISPs and
> recently migrated off (as the service was discontinued).
> >
> > We have had several cases where the user had a YouTube channel or Picasa
> photo albums, etc. that they created with their Google Apps for ISPs
> credentials.  Now that the service is gone, those channels and albums still
> exist but the users are unable to login to them or manage them in any way
> because it tells them that their account has been disabled.
> >
> > Of course, Google had been un-responsive to all of our (and the
> customer's) inquiries about how to fix this.
> >
> > Has anyone else run into this and found a way around it?
> >
> > thanks
> >
> >
> > Shawn
> >
>
>

From mhoppes at indigowireless.com  Mon Aug 24 12:45:25 2015
From: mhoppes at indigowireless.com (Matt Hoppes)
Date: Mon, 24 Aug 2015 08:45:25 -0400
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
Message-ID: <48C76660-EA54-4AFF-85CA-06B64B9C4672@indigowireless.com>

Which is odd. Considering it was basically gmail on the back end and they still got ad revenue from it. 



> On Aug 24, 2015, at 08:34, Scott Helms <khelms at zcorum.com> wrote:
> 
> Ryan,
> 
> Most certainly, the charges varied some  because of size and other factors
> but it was around 25 cents monthly per Gmail box.
> 
> 
> Scott Helms
> Vice President of Technology
> ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
> 
>> On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey <ryan at finnesey.com> wrote:
>> 
>> Was Google charging ISPs for this service?
>> 
>> Cheers
>> Ryan
>> 
>> 
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Greene
>> Sent: Tuesday, August 18, 2015 2:18 PM
>> To: Shawn L <shawnl at up.net>
>> Cc: nanog <nanog at nanog.org>
>> Subject: Re: Google Apps for ISPs -- Lingering fallout
>> 
>> You?ll need to escalate this with Google. If the front-end support team
>> cannot help, move up the chain as far as you can. It should eventually
>> reach the PM that worked on the turn-down of that service and get some
>> action.
>> 
>> --
>> Gary L. Greene, Jr.
>> Sr. Systems Administrator
>> IT Operations
>> Minerva Networks, Inc.
>> Cell: +1 (650) 704-6633
>> 
>> 
>> 
>> 
>>> On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
>>> 
>>> 
>>> I know there are others on this list who used Google Apps for ISPs and
>> recently migrated off (as the service was discontinued).
>>> 
>>> We have had several cases where the user had a YouTube channel or Picasa
>> photo albums, etc. that they created with their Google Apps for ISPs
>> credentials.  Now that the service is gone, those channels and albums still
>> exist but the users are unable to login to them or manage them in any way
>> because it tells them that their account has been disabled.
>>> 
>>> Of course, Google had been un-responsive to all of our (and the
>> customer's) inquiries about how to fix this.
>>> 
>>> Has anyone else run into this and found a way around it?
>>> 
>>> thanks
>>> 
>>> 
>>> Shawn
>>> 
>> 
>> 

From khelms at zcorum.com  Mon Aug 24 12:48:58 2015
From: khelms at zcorum.com (Scott Helms)
Date: Mon, 24 Aug 2015 08:48:58 -0400
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <48C76660-EA54-4AFF-85CA-06B64B9C4672@indigowireless.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
 <48C76660-EA54-4AFF-85CA-06B64B9C4672@indigowireless.com>
Message-ID: <CAMrdfRwpE_g5QndQHxxYNmhffkPcwkMHQV_xRqh8LDTX20MGSg@mail.gmail.com>

Matt,

That's what I thought, but it was even more expensive if you decided you
wanted the ad free version.  The folks at Google I spoke with countered
with the costs for Google Apps for Business and placed Partner Edition (the
one for ISPs) between the direct consumer Gmail offering and the business
offerings in functionality and pricing.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Mon, Aug 24, 2015 at 8:45 AM, Matt Hoppes <mhoppes at indigowireless.com>
wrote:

> Which is odd. Considering it was basically gmail on the back end and they
> still got ad revenue from it.
>
>
>
> > On Aug 24, 2015, at 08:34, Scott Helms <khelms at zcorum.com> wrote:
> >
> > Ryan,
> >
> > Most certainly, the charges varied some  because of size and other
> factors
> > but it was around 25 cents monthly per Gmail box.
> >
> >
> > Scott Helms
> > Vice President of Technology
> > ZCorum
> > (678) 507-5000
> > --------------------------------
> > http://twitter.com/kscotthelms
> > --------------------------------
> >
> >> On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey <ryan at finnesey.com>
> wrote:
> >>
> >> Was Google charging ISPs for this service?
> >>
> >> Cheers
> >> Ryan
> >>
> >>
> >> -----Original Message-----
> >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Greene
> >> Sent: Tuesday, August 18, 2015 2:18 PM
> >> To: Shawn L <shawnl at up.net>
> >> Cc: nanog <nanog at nanog.org>
> >> Subject: Re: Google Apps for ISPs -- Lingering fallout
> >>
> >> You?ll need to escalate this with Google. If the front-end support team
> >> cannot help, move up the chain as far as you can. It should eventually
> >> reach the PM that worked on the turn-down of that service and get some
> >> action.
> >>
> >> --
> >> Gary L. Greene, Jr.
> >> Sr. Systems Administrator
> >> IT Operations
> >> Minerva Networks, Inc.
> >> Cell: +1 (650) 704-6633
> >>
> >>
> >>
> >>
> >>> On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
> >>>
> >>>
> >>> I know there are others on this list who used Google Apps for ISPs and
> >> recently migrated off (as the service was discontinued).
> >>>
> >>> We have had several cases where the user had a YouTube channel or
> Picasa
> >> photo albums, etc. that they created with their Google Apps for ISPs
> >> credentials.  Now that the service is gone, those channels and albums
> still
> >> exist but the users are unable to login to them or manage them in any
> way
> >> because it tells them that their account has been disabled.
> >>>
> >>> Of course, Google had been un-responsive to all of our (and the
> >> customer's) inquiries about how to fix this.
> >>>
> >>> Has anyone else run into this and found a way around it?
> >>>
> >>> thanks
> >>>
> >>>
> >>> Shawn
> >>>
> >>
> >>
>

From josh.hoppes at gmail.com  Mon Aug 24 12:59:03 2015
From: josh.hoppes at gmail.com (Josh Hoppes)
Date: Mon, 24 Aug 2015 07:59:03 -0500
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <48C76660-EA54-4AFF-85CA-06B64B9C4672@indigowireless.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
 <48C76660-EA54-4AFF-85CA-06B64B9C4672@indigowireless.com>
Message-ID: <CAMcDhomPEydhKUSNPrApqyXzmNx_uxoHn3Mq3JHkyfa5MjhT1A@mail.gmail.com>

When it comes to reasons for them to force everyone off I believe it
has to do with control. ISP accounts tend to be personal accounts, but
when you stop being a customer of the ISP they will deactivate the
account. Now that they tied purchases on the play store to the account
it made things very messy when a customers account was deactivated and
they suddenly lose all of this stuff they paid for.

On Mon, Aug 24, 2015 at 7:45 AM, Matt Hoppes <mhoppes at indigowireless.com> wrote:
> Which is odd. Considering it was basically gmail on the back end and they still got ad revenue from it.
>
>
>
>> On Aug 24, 2015, at 08:34, Scott Helms <khelms at zcorum.com> wrote:
>>
>> Ryan,
>>
>> Most certainly, the charges varied some  because of size and other factors
>> but it was around 25 cents monthly per Gmail box.
>>
>>
>> Scott Helms
>> Vice President of Technology
>> ZCorum
>> (678) 507-5000
>> --------------------------------
>> http://twitter.com/kscotthelms
>> --------------------------------
>>
>>> On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey <ryan at finnesey.com> wrote:
>>>
>>> Was Google charging ISPs for this service?
>>>
>>> Cheers
>>> Ryan
>>>
>>>
>>> -----Original Message-----
>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Greene
>>> Sent: Tuesday, August 18, 2015 2:18 PM
>>> To: Shawn L <shawnl at up.net>
>>> Cc: nanog <nanog at nanog.org>
>>> Subject: Re: Google Apps for ISPs -- Lingering fallout
>>>
>>> You?ll need to escalate this with Google. If the front-end support team
>>> cannot help, move up the chain as far as you can. It should eventually
>>> reach the PM that worked on the turn-down of that service and get some
>>> action.
>>>
>>> --
>>> Gary L. Greene, Jr.
>>> Sr. Systems Administrator
>>> IT Operations
>>> Minerva Networks, Inc.
>>> Cell: +1 (650) 704-6633
>>>
>>>
>>>
>>>
>>>> On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
>>>>
>>>>
>>>> I know there are others on this list who used Google Apps for ISPs and
>>> recently migrated off (as the service was discontinued).
>>>>
>>>> We have had several cases where the user had a YouTube channel or Picasa
>>> photo albums, etc. that they created with their Google Apps for ISPs
>>> credentials.  Now that the service is gone, those channels and albums still
>>> exist but the users are unable to login to them or manage them in any way
>>> because it tells them that their account has been disabled.
>>>>
>>>> Of course, Google had been un-responsive to all of our (and the
>>> customer's) inquiries about how to fix this.
>>>>
>>>> Has anyone else run into this and found a way around it?
>>>>
>>>> thanks
>>>>
>>>>
>>>> Shawn
>>>>
>>>
>>>

From ryan at finnesey.com  Mon Aug 24 13:15:49 2015
From: ryan at finnesey.com (Ryan Finnesey)
Date: Mon, 24 Aug 2015 13:15:49 +0000
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
Message-ID: <BY1PR0501MB1462A98BEDF65C942B7EAB40B4620@BY1PR0501MB1462.namprd05.prod.outlook.com>

I have been working on putting together a program to work with ISPs to offer Office 365 I was thinking the Google Apps for ISP shutdown would be an opportunity but it seem to be a very different price point.  I have done a large number of Google App to Office 365 migration but Google was charging  around $12 per user.    Also a lot within the nonprofit space  witch is a free license.  What system did most ISPs move to?

Cheers
Ryan


From: Scott Helms [mailto:khelms at zcorum.com]
Sent: Monday, August 24, 2015 8:35 AM
To: Ryan Finnesey <ryan at finnesey.com>
Cc: Gary Greene <ggreene at minervanetworks.com>; Shawn L <shawnl at up.net>; nanog <nanog at nanog.org>
Subject: Re: Google Apps for ISPs -- Lingering fallout

Ryan,

Most certainly, the charges varied some  because of size and other factors but it was around 25 cents monthly per Gmail box.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey <ryan at finnesey.com<mailto:ryan at finnesey.com>> wrote:
Was Google charging ISPs for this service?

Cheers
Ryan


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org<mailto:nanog-bounces at nanog.org>] On Behalf Of Gary Greene
Sent: Tuesday, August 18, 2015 2:18 PM
To: Shawn L <shawnl at up.net<mailto:shawnl at up.net>>
Cc: nanog <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: Google Apps for ISPs -- Lingering fallout

You?ll need to escalate this with Google. If the front-end support team cannot help, move up the chain as far as you can. It should eventually reach the PM that worked on the turn-down of that service and get some action.

--
Gary L. Greene, Jr.
Sr. Systems Administrator
IT Operations
Minerva Networks, Inc.
Cell: +1 (650) 704-6633<tel:%2B1%20%28650%29%20704-6633>




> On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net<mailto:shawnl at up.net>> wrote:
>
>
> I know there are others on this list who used Google Apps for ISPs and recently migrated off (as the service was discontinued).
>
> We have had several cases where the user had a YouTube channel or Picasa photo albums, etc. that they created with their Google Apps for ISPs credentials.  Now that the service is gone, those channels and albums still exist but the users are unable to login to them or manage them in any way because it tells them that their account has been disabled.
>
> Of course, Google had been un-responsive to all of our (and the customer's) inquiries about how to fix this.
>
> Has anyone else run into this and found a way around it?
>
> thanks
>
>
> Shawn
>


From josh at imaginenetworksllc.com  Mon Aug 24 13:23:16 2015
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Mon, 24 Aug 2015 09:23:16 -0400
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <BY1PR0501MB1462A98BEDF65C942B7EAB40B4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
 <BY1PR0501MB1462A98BEDF65C942B7EAB40B4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
Message-ID: <CAN9qwJ8o-vOK8vY+MrMbZ-xPvjj8pCwsuuNYSOu0wi+EAk03PA@mail.gmail.com>

Myself and others dropped the offering.  Customers simply got a free Gmail
(some Hotmail and Yahoo).

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Aug 24, 2015 9:17 AM, "Ryan Finnesey" <ryan at finnesey.com> wrote:

> I have been working on putting together a program to work with ISPs to
> offer Office 365 I was thinking the Google Apps for ISP shutdown would be
> an opportunity but it seem to be a very different price point.  I have done
> a large number of Google App to Office 365 migration but Google was
> charging  around $12 per user.    Also a lot within the nonprofit space
> witch is a free license.  What system did most ISPs move to?
>
> Cheers
> Ryan
>
>
> From: Scott Helms [mailto:khelms at zcorum.com]
> Sent: Monday, August 24, 2015 8:35 AM
> To: Ryan Finnesey <ryan at finnesey.com>
> Cc: Gary Greene <ggreene at minervanetworks.com>; Shawn L <shawnl at up.net>;
> nanog <nanog at nanog.org>
> Subject: Re: Google Apps for ISPs -- Lingering fallout
>
> Ryan,
>
> Most certainly, the charges varied some  because of size and other factors
> but it was around 25 cents monthly per Gmail box.
>
>
> Scott Helms
> Vice President of Technology
> ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
>
> On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey <ryan at finnesey.com<mailto:
> ryan at finnesey.com>> wrote:
> Was Google charging ISPs for this service?
>
> Cheers
> Ryan
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org<mailto:nanog-bounces at nanog.org>]
> On Behalf Of Gary Greene
> Sent: Tuesday, August 18, 2015 2:18 PM
> To: Shawn L <shawnl at up.net<mailto:shawnl at up.net>>
> Cc: nanog <nanog at nanog.org<mailto:nanog at nanog.org>>
> Subject: Re: Google Apps for ISPs -- Lingering fallout
>
> You?ll need to escalate this with Google. If the front-end support team
> cannot help, move up the chain as far as you can. It should eventually
> reach the PM that worked on the turn-down of that service and get some
> action.
>
> --
> Gary L. Greene, Jr.
> Sr. Systems Administrator
> IT Operations
> Minerva Networks, Inc.
> Cell: +1 (650) 704-6633<tel:%2B1%20%28650%29%20704-6633>
>
>
>
>
> > On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net<mailto:
> shawnl at up.net>> wrote:
> >
> >
> > I know there are others on this list who used Google Apps for ISPs and
> recently migrated off (as the service was discontinued).
> >
> > We have had several cases where the user had a YouTube channel or Picasa
> photo albums, etc. that they created with their Google Apps for ISPs
> credentials.  Now that the service is gone, those channels and albums still
> exist but the users are unable to login to them or manage them in any way
> because it tells them that their account has been disabled.
> >
> > Of course, Google had been un-responsive to all of our (and the
> customer's) inquiries about how to fix this.
> >
> > Has anyone else run into this and found a way around it?
> >
> > thanks
> >
> >
> > Shawn
> >
>
>

From khelms at zcorum.com  Mon Aug 24 13:33:41 2015
From: khelms at zcorum.com (Scott Helms)
Date: Mon, 24 Aug 2015 09:33:41 -0400
Subject: Google Apps for ISPs -- Lingering fallout
In-Reply-To: <BY1PR0501MB1462A98BEDF65C942B7EAB40B4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
References: <1439919568.192219773@upnet.mymailsrvr.com>
 <04E8F49E-733D-4C7B-8C8F-B733D9448C53@minervanetworks.com>
 <BY1PR0501MB1462CD4C372F9736031B078FB4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
 <CAMrdfRxGbp2reMYrZfVnF8mRmrZmU=Za58YZW7tkoCErOvRkSQ@mail.gmail.com>
 <BY1PR0501MB1462A98BEDF65C942B7EAB40B4620@BY1PR0501MB1462.namprd05.prod.outlook.com>
Message-ID: <CAMrdfRwwCZ_qWQFP6wmZSQa11kUVD3TbANg2rUtgdCxAtgQNiw@mail.gmail.com>

Ryan,

>From what I've seen a myriad of solutions.  A lot of the people I know that
wanted a full functionality replacement switched to Hyperoffice:
http://www.hyperoffice.com/sp/google-apps.php

Some others went to Zimbra:
https://www.zimbra.com/

Others went to a variety of less functional but also less expensive
solutions that look more like traditional ISP email.

It really depended on how much the ISP thought their end users wanted the
"Google like" functionality.


Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Mon, Aug 24, 2015 at 9:15 AM, Ryan Finnesey <ryan at finnesey.com> wrote:

> I have been working on putting together a program to work with ISPs to
> offer Office 365 I was thinking the Google Apps for ISP shutdown would be
> an opportunity but it seem to be a very different price point.  I have done
> a large number of Google App to Office 365 migration but Google was
> charging  around $12 per user.    Also a lot within the nonprofit space
>  witch is a free license.  What system did most ISPs move to?
>
>
>
> Cheers
>
> Ryan
>
>
>
>
>
> *From:* Scott Helms [mailto:khelms at zcorum.com]
> *Sent:* Monday, August 24, 2015 8:35 AM
> *To:* Ryan Finnesey <ryan at finnesey.com>
> *Cc:* Gary Greene <ggreene at minervanetworks.com>; Shawn L <shawnl at up.net>;
> nanog <nanog at nanog.org>
> *Subject:* Re: Google Apps for ISPs -- Lingering fallout
>
>
>
> Ryan,
>
>
>
> Most certainly, the charges varied some  because of size and other factors
> but it was around 25 cents monthly per Gmail box.
>
>
>
>
> Scott Helms
> Vice President of Technology
> ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
>
>
>
> On Mon, Aug 24, 2015 at 1:43 AM, Ryan Finnesey <ryan at finnesey.com> wrote:
>
> Was Google charging ISPs for this service?
>
> Cheers
> Ryan
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Gary Greene
> Sent: Tuesday, August 18, 2015 2:18 PM
> To: Shawn L <shawnl at up.net>
> Cc: nanog <nanog at nanog.org>
> Subject: Re: Google Apps for ISPs -- Lingering fallout
>
> You?ll need to escalate this with Google. If the front-end support team
> cannot help, move up the chain as far as you can. It should eventually
> reach the PM that worked on the turn-down of that service and get some
> action.
>
> --
> Gary L. Greene, Jr.
> Sr. Systems Administrator
> IT Operations
> Minerva Networks, Inc.
> Cell: +1 (650) 704-6633
>
>
>
>
> > On Aug 18, 2015, at 10:39 AM, Shawn L <shawnl at up.net> wrote:
> >
> >
> > I know there are others on this list who used Google Apps for ISPs and
> recently migrated off (as the service was discontinued).
> >
> > We have had several cases where the user had a YouTube channel or Picasa
> photo albums, etc. that they created with their Google Apps for ISPs
> credentials.  Now that the service is gone, those channels and albums still
> exist but the users are unable to login to them or manage them in any way
> because it tells them that their account has been disabled.
> >
> > Of course, Google had been un-responsive to all of our (and the
> customer's) inquiries about how to fix this.
> >
> > Has anyone else run into this and found a way around it?
> >
> > thanks
> >
> >
> > Shawn
> >
>
>
>

From matthias at leisi.net  Mon Aug 24 18:04:36 2015
From: matthias at leisi.net (Matthias Leisi)
Date: Mon, 24 Aug 2015 20:04:36 +0200
Subject: Data Center operations mail list?
In-Reply-To: <20150822014600.GA26949@gsp.org>
References: <CAJB2g-HB-zpfJh0b-JbzAEYbxX0-RZ-G3QHaoz-Fm+oNhNfS4w@mail.gmail.com>
 <2874E2F0-AB79-4F39-8BE2-F2BF7F9EECF1@egon.cc>
 <alpine.BSF.2.11.1508111514270.7491@z.fncre.vasb>
 <CALKLF0_VCh85uq63ue03W2pZ9-Tg4BHBYcP04UXFPwETLL0QQQ@mail.gmail.com>
 <55CAE8FC.6060405@seacom.mu>
 <CAJB2g-Ef8dZ4i0bOCiD8Fxj9ut6cOswErFV0_gq=W2zcwv6xYw@mail.gmail.com>
 <CAMOPTExSO1_HApkJ8WAYai94DJwjp5QLOx7=ntSnENAMDh6c-Q@mail.gmail.com>
 <E4186002-56D3-4BAD-8922-B03051DE712F@gizmopartners.com>
 <20150820154309.GB19948@gsp.org>
 <CAJB2g-H+5J-LwmDKX2gmdmDsrvXTq0ksAsu+tkazYjjic3Qexw@mail.gmail.com>
 <20150822014600.GA26949@gsp.org>
Message-ID: <C1658D3D-40E2-47E8-BEFD-D4B6A15E1431@leisi.net>


> The best course here is to completely avoid any contact with the
> horribly-mismanaged Amazon cloud operation until such time as those
> running it demonstrate a bare minimum of professionalism -- which,

Seconded. 

At dnswl.org <http://dnswl.org/>, most of Amazon IP space has a pretty bad reputation (for outbound SMTP traffic). Abuse desk is unresponsive and IPs mostly lack proper rDNS which would allow to identify responsible party. Amazon may be a good choice for some people for some use cases, but outbound SMTP is not such a use case.

? Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150824/c08c0bf6/attachment.bin>

From mkamal at noor.net  Mon Aug 24 19:07:45 2015
From: mkamal at noor.net (Mohamed Kamal)
Date: Mon, 24 Aug 2015 21:07:45 +0200
Subject: BGP advertise-best-external on RR
Message-ID: <55DB6B81.60908@noor.net>

Hi,

I have a classic network design with 3 gateways, each receive a default 
route from different upstream provider. Each gateway has a BGP session 
with a route-reflector, which in turns reflects the best BGP route to 
the other PE routers in the network. The route-reflectors are running 
the SRE train (12.2(33)SRE1) and here exist the problem.

I need to leak all the default routes (3 default routes) from the 
gateways into the PE routers. I have done this via bgp 
advertise-best-external on the gateways. So far, the default routes 
exist on the route-reflector, however it's suppressed as the RR will 
only send the best path.

I have configured bgp advertise-best-external also on the RR but it 
didn't work, because the RR didn't see that the different default routes 
received are of "external" type. Cisco didn't state that clearly and it 
only stated that bgp best external feature won't work on the RR unless 
you get an ASR loaded with an IOS-XE 3.4 or later!

Anyhow, do anyone here has a suggestion of how to get this done without 
replacing my RR sticking to this classical network design?

Thanks.

-- 
Mohamed Kamal
Core Network Sr. Engineer


From mkamal at noor.net  Mon Aug 24 19:31:51 2015
From: mkamal at noor.net (Mohamed Kamal)
Date: Mon, 24 Aug 2015 21:31:51 +0200
Subject: BGP advertise-best-external on RR
In-Reply-To: <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com>
References: <55DB6B81.60908@noor.net>
 <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com>
Message-ID: <55DB7127.20308@noor.net>

It's only supported on the 15.2(4)S and later not the SRE train. I might 
consider an upgrade.

One more question regarding this, can you configure the RR to be the 
main and shadow RR?

Mohamed Kamal
Core Network Sr. Engineer

On 8/24/2015 9:16 PM, Diptanshu Singh wrote:
> BGP Add-Path might be your friend . You can look at diverse-path as well .


From diptanshu.singh at gmail.com  Mon Aug 24 19:16:41 2015
From: diptanshu.singh at gmail.com (Diptanshu Singh)
Date: Mon, 24 Aug 2015 14:16:41 -0500
Subject: BGP advertise-best-external on RR
In-Reply-To: <55DB6B81.60908@noor.net>
References: <55DB6B81.60908@noor.net>
Message-ID: <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com>

BGP Add-Path might be your friend . You can look at diverse-path as well .

Sent from my iPhone

> On Aug 24, 2015, at 2:07 PM, Mohamed Kamal <mkamal at noor.net> wrote:
> 
> Hi,
> 
> I have a classic network design with 3 gateways, each receive a default route from different upstream provider. Each gateway has a BGP session with a route-reflector, which in turns reflects the best BGP route to the other PE routers in the network. The route-reflectors are running the SRE train (12.2(33)SRE1) and here exist the problem.
> 
> I need to leak all the default routes (3 default routes) from the gateways into the PE routers. I have done this via bgp advertise-best-external on the gateways. So far, the default routes exist on the route-reflector, however it's suppressed as the RR will only send the best path.
> 
> I have configured bgp advertise-best-external also on the RR but it didn't work, because the RR didn't see that the different default routes received are of "external" type. Cisco didn't state that clearly and it only stated that bgp best external feature won't work on the RR unless you get an ASR loaded with an IOS-XE 3.4 or later!
> 
> Anyhow, do anyone here has a suggestion of how to get this done without replacing my RR sticking to this classical network design?
> 
> Thanks.
> 
> -- 
> Mohamed Kamal
> Core Network Sr. Engineer
> 

From diptanshu.singh at gmail.com  Mon Aug 24 19:53:41 2015
From: diptanshu.singh at gmail.com (Diptanshu Singh)
Date: Mon, 24 Aug 2015 14:53:41 -0500
Subject: BGP advertise-best-external on RR
In-Reply-To: <55DB7127.20308@noor.net>
References: <55DB6B81.60908@noor.net>
 <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com> <55DB7127.20308@noor.net>
Message-ID: <C48DD837-5C34-4F9C-B249-70957526B944@gmail.com>

Yes . In the case of diverse path , shadow route reflector will be the one wherever  you enable commands to trigger diverse path computation.

Good thing with diverse path is that the RR-Clients don't have to have any support but bad thing is that it can only reflect One additional best-path( second best path ) .

Sent from my iPhone

> On Aug 24, 2015, at 2:31 PM, Mohamed Kamal <mkamal at noor.net> wrote:
> 
> It's only supported on the 15.2(4)S and later not the SRE train. I might consider an upgrade.
> 
> One more question regarding this, can you configure the RR to be the main and shadow RR?
> 
> Mohamed Kamal
> Core Network Sr. Engineer
> 
>> On 8/24/2015 9:16 PM, Diptanshu Singh wrote:
>> BGP Add-Path might be your friend . You can look at diverse-path as well .
> 

From nanog at ics-il.net  Mon Aug 24 20:01:42 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 24 Aug 2015 15:01:42 -0500 (CDT)
Subject: Quanta LB4M
In-Reply-To: <1197305683.171.1440363513455.JavaMail.mhammett@ThunderFuck>
Message-ID: <846038886.2808.1440446547772.JavaMail.mhammett@ThunderFuck>

Apparently the newer version of VxWorks doesn't have HTTP management. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message -----

From: "Mike Hammett" <nanog at ics-il.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Sunday, August 23, 2015 3:57:44 PM 
Subject: Re: Quanta LB4M 

I noticed that one I have already has the 1.1.0.8 firmware. Upon switching to it, I noticed that I gained SSH, but lost HTTP. Has anyone else seen that? 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


----- Original Message ----- 

From: "Jared Mauch" <jared at puck.nether.net> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "NANOG" <nanog at nanog.org> 
Sent: Sunday, June 28, 2015 2:56:17 PM 
Subject: Re: Quanta LB4M 


> On Jun 28, 2015, at 2:50 PM, Mike Hammett <nanog at ics-il.net> wrote: 
> 
> Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." 

I managed to brick one of these by loading the wrong firmware, or doing it at the wrong layer. 

I have gotten a few more and these are great switches for home or environment where you have a spare on hand. You can usually get them for around $100 on eBay. 

The firmware is *really* not designed for anything fancy but I?ve been able to drop in a variety of optics and have it work without issues in the 10G ports. 

Check the flash on them as there is a primary/secondary flash once you?re past the boot image. (Don?t try to flash it from that level, that?s how I killed it at least). 

I tossed a few different firmware versions I extracted here, as well as the flash0/flash1 images and the doc i found for it. 

http://puck.nether.net/~jared/lb4m/ 

- Jared 


From joly at punkcast.com  Tue Aug 25 06:58:26 2015
From: joly at punkcast.com (Joly MacFie)
Date: Tue, 25 Aug 2015 02:58:26 -0400
Subject: AfPIF 2015 Livestream
Message-ID: <CAM9VJk2LSQvjw9PyY-34ovs5Ver51mw6-Gv=g=2wY4C_b2h_Sg@mail.gmail.com>

Just about to start

https://livestream.com/internetsociety/afpif2015/

-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-

From jeff.tantsura at ericsson.com  Tue Aug 25 09:37:14 2015
From: jeff.tantsura at ericsson.com (Jeff Tantsura)
Date: Tue, 25 Aug 2015 09:37:14 +0000
Subject: BGP advertise-best-external on RR
In-Reply-To: <C48DD837-5C34-4F9C-B249-70957526B944@gmail.com>
References: <55DB6B81.60908@noor.net>
 <2411BC56-6BAC-433F-B96E-7761C021774A@gmail.com> <55DB7127.20308@noor.net>
 <C48DD837-5C34-4F9C-B249-70957526B944@gmail.com>
Message-ID: <D20210A6.A4C08%jeff.tantsura@ericsson.com>

Hi,

In your case I?d recommend to use diverse path, due to its simplicity and
non disruptive deployment characteristics.
As you know - diverse path requires additional BGP session per additional
(second, next, etc) path, in most cases not a problem, however mileage
might vary.

To my memory, in Cisco land - it has only been implemented in IOS, not XR,
please check.   

Cheers,
Jeff




-----Original Message-----
From: Diptanshu Singh <diptanshu.singh at gmail.com>
Date: Monday, August 24, 2015 at 10:53 PM
To: Mohamed Kamal <mkamal at noor.net>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: BGP advertise-best-external on RR

>Yes . In the case of diverse path , shadow route reflector will be the
>one wherever  you enable commands to trigger diverse path computation.
>
>Good thing with diverse path is that the RR-Clients don't have to have
>any support but bad thing is that it can only reflect One additional
>best-path( second best path ) .
>
>Sent from my iPhone
>
>> On Aug 24, 2015, at 2:31 PM, Mohamed Kamal <mkamal at noor.net> wrote:
>> 
>> It's only supported on the 15.2(4)S and later not the SRE train. I
>>might consider an upgrade.
>> 
>> One more question regarding this, can you configure the RR to be the
>>main and shadow RR?
>> 
>> Mohamed Kamal
>> Core Network Sr. Engineer
>> 
>>> On 8/24/2015 9:16 PM, Diptanshu Singh wrote:
>>> BGP Add-Path might be your friend . You can look at diverse-path as
>>>well .
>> 


From mark.tinka at seacom.mu  Tue Aug 25 11:49:12 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 13:49:12 +0200
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
Message-ID: <55DC5638.8090509@seacom.mu>



On 18/Aug/15 14:29, Tim Durack wrote:

> Question: What is the preferred practice for separating peering and transit
> circuits?
>
> 1. Terminate peering and transit on separate routers.

We do this.

Makes policy enforcement easier.

Mark.

From mark.tinka at seacom.mu  Tue Aug 25 11:50:43 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 13:50:43 +0200
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <CAE_ug16-UwTedYV63K=6QY4VtMyPRCUZgd3MeVUTDRqprpMQiA@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <20150818124747.GG34798@greenie.muc.de>
 <CAE_ug16-UwTedYV63K=6QY4VtMyPRCUZgd3MeVUTDRqprpMQiA@mail.gmail.com>
Message-ID: <55DC5693.2050505@seacom.mu>



On 18/Aug/15 15:31, Tim Durack wrote:

>
> Not sure if I really want to get into using DSCP bits for basic IP service
> though.

There are use-cases, but they would mostly be internal.

Mark.

From mark.tinka at seacom.mu  Tue Aug 25 11:54:21 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 13:54:21 +0200
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <CAE_ug15tWxr_wE4SnGxoqiTec9brG_xqDLbjzakXy1fqB5aM8A@mail.gmail.com>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <7029C38A-B3D9-4D23-A876-5266EE63B309@granados-llc.net>
 <CAE_ug15tWxr_wE4SnGxoqiTec9brG_xqDLbjzakXy1fqB5aM8A@mail.gmail.com>
Message-ID: <55DC576D.60103@seacom.mu>



On 18/Aug/15 18:02, Tim Durack wrote:

> Can I ask why you terminate peering and transit on different routers? (Not
> suggesting that is bad, just trying to understand the reason.)

Easier policy enforcement for us.

Lowers the chance of you dealing with traffic in ways you don't intend
(although that can always be fixed).

Spreading both commercial and technical risk, depending on whether you
value transit more than peering, or vice versa.

Avoiding kinky things with VRF's.

Mark.

From mark.tinka at seacom.mu  Tue Aug 25 11:56:31 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 13:56:31 +0200
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <55D39903.6050009@foobar.org>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
 <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
 <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>
 <55D39903.6050009@foobar.org>
Message-ID: <55DC57EF.5030606@seacom.mu>



On 18/Aug/15 22:43, Nick Hilliard wrote:

> i'd advise being careful with this approach: urpf at ixps is a nightmare.

We don't generally do uRPF at exchange points, for the simple reason
that the router is dedicated (meaning it does not carry a full table),
and peers leaking your routes to the Internet (which breaks uRPF in this
scenario) is a constant scenario.

    *sigh*

Mark.


From mark.tinka at seacom.mu  Tue Aug 25 12:05:47 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 14:05:47 +0200
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <8004F5EE-D64A-4837-8F14-5F01D6004F90@granados-llc.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <CAP-guGX2xx4X4jCzOzbVwQzYJLh7NPhdSMJ7qjKV18bTc-7mrg@mail.gmail.com>
 <78EDBDF9-D575-44EC-B08A-65D085946A64@ianai.net>
 <CAE_ug14M_otpVujdEfW5VLr9n0=BzmrVjs1gscw=maY54QK4DQ@mail.gmail.com>
 <55D39903.6050009@foobar.org> <55DC57EF.5030606@seacom.mu>
 <8004F5EE-D64A-4837-8F14-5F01D6004F90@granados-llc.net>
Message-ID: <55DC5A1B.60209@seacom.mu>



On 25/Aug/15 13:58, Scott Granados wrote:

> If you?re not enabling URPF at the peering routers and edges how do you handle things like RTBH?

D/RTBH still works fine.

S/RTBH would be an issue, but one could enable uRPF temporarily for that.

Mark.

From mark.tinka at seacom.mu  Tue Aug 25 12:32:07 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 14:32:07 +0200
Subject: [c-nsp] Peering + Transit Circuits
In-Reply-To: <00c9ad74c7.0001d0df30.000446dd79.0000001a4b@twt.it>
References: <00c9ad74c7.0001d0df30.000446dd79.0000001a4b@twt.it>
Message-ID: <55DC6047.6080504@seacom.mu>



On 25/Aug/15 14:23, Brian Turnbow wrote:

> Or use uRPF with an acl.
> You can specify what to block and what not to block and use S/RTBH as well.

Even though we're not receiving the full feed on dedicated peering
routers, you're talking at least 35% of it. Sometimes more...

Mark.


From mark.tinka at seacom.mu  Tue Aug 25 15:16:08 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 17:16:08 +0200
Subject: Peering + Transit Circuits
In-Reply-To: <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
References: <CAE_ug143GsMN3+CNz=AgTr+xjGWY2CrmXYW=jf36JQ3AAnukFw@mail.gmail.com>
 <1474463790.41603.1439937341410.JavaMail.zimbra@snappytelecom.net>
 <1971CB6C-0199-4E58-911E-D99C18450095@ianai.net>
Message-ID: <55DC86B8.8070505@seacom.mu>



On 19/Aug/15 01:12, Patrick W. Gilmore wrote:

>
> Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc.

This is what we do, and to make it more interesting, we have 0/0 and
::/0 on these dedicated peering routers pointing to Null0.

Mark.

From mark.tinka at seacom.mu  Tue Aug 25 15:25:14 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 25 Aug 2015 17:25:14 +0200
Subject: Production-scale NAT64
In-Reply-To: <55D5D9AA.2080203@forethought.net>
References: <55D5D9AA.2080203@forethought.net>
Message-ID: <55DC88DA.3090200@seacom.mu>



On 20/Aug/15 15:44, Jawaid Shell2 wrote:

> Who out there is using production-scale NAT64? What solution are you
> using?

NAT64/DNS64 on Cisco ASR1006's distributed across the network.

Boxes deployed, traffic minimal as we still have IPv4 addresses as well
(AFRINIC region).

Mark.

From nathana at fsr.com  Tue Aug 25 21:32:52 2015
From: nathana at fsr.com (Nathan Anderson)
Date: Tue, 25 Aug 2015 14:32:52 -0700
Subject: LTE
Message-ID: <C12CA40900F4E0448A2D4E66DFA6A59B20783A25D4@Demekin.FSI.local>

Is there anybody here who is fluent in LTE/3GPP networks and the standards that govern them?  I'm not sure where else to look.  I have a very specific question about UEs, UICCs, and the security negotiation (integrity & ciphers) that occurs during attachment both on the AS and NAS layers, and so far I have not found our vendor to be very helpful.  If there is somebody out there that knows something about this area, and is willing to chat with me about it, feel free to drop me a line off-list.

Thanks much,

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com


From bryan at ignatow.org  Tue Aug 25 21:38:57 2015
From: bryan at ignatow.org (Bryan Ignatow)
Date: Tue, 25 Aug 2015 21:38:57 +0000
Subject: LTE
In-Reply-To: <C12CA40900F4E0448A2D4E66DFA6A59B20783A25D4@Demekin.FSI.local>
References: <C12CA40900F4E0448A2D4E66DFA6A59B20783A25D4@Demekin.FSI.local>
Message-ID: <CAB1OdL5_qtK6QMyfVmOwuVodOd8MoUaJW1_SPK23cu-QBMHT-w@mail.gmail.com>

Nathan,

I know someone.  Contact me off list and I will get you and he connected.

Bryan

On Tue, Aug 25, 2015 at 4:33 PM Nathan Anderson <nathana at fsr.com> wrote:

> Is there anybody here who is fluent in LTE/3GPP networks and the standards
> that govern them?  I'm not sure where else to look.  I have a very specific
> question about UEs, UICCs, and the security negotiation (integrity &
> ciphers) that occurs during attachment both on the AS and NAS layers, and
> so far I have not found our vendor to be very helpful.  If there is
> somebody out there that knows something about this area, and is willing to
> chat with me about it, feel free to drop me a line off-list.
>
> Thanks much,
>
> --
> Nathan Anderson
> First Step Internet, LLC
> nathana at fsr.com
>
>

From tom+nanog at oneshoeco.com  Wed Aug 26 03:40:58 2015
From: tom+nanog at oneshoeco.com (Tom Lanyon)
Date: Wed, 26 Aug 2015 13:10:58 +0930
Subject: Production-scale NAT64
In-Reply-To: <55DC88DA.3090200@seacom.mu>
References: <55D5D9AA.2080203@forethought.net>
	<55DC88DA.3090200@seacom.mu>
Message-ID: <CA+b4KqdTgW9Nf1-PyNP8z2qR6=+xo80Ta8bA4XwLqSOJ1cV1LA@mail.gmail.com>

On 26 August 2015 at 00:55, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
> On 20/Aug/15 15:44, Jawaid Shell2 wrote:
>
>> Who out there is using production-scale NAT64? What solution are you
>> using?
>
> NAT64/DNS64 on Cisco ASR1006's distributed across the network.

We're doing NAT64/DNS64 with Cisco ASR1002s, although it's for a
IPv6-only server network, not for user eyeballs.  The biggest downside
has been the lack of SNMP (or similar) support for monitoring the
NAT64 traffic and pool usage, at least on the IOS XE versions we're
running.

-Tom

From tore at fud.no  Wed Aug 26 04:49:53 2015
From: tore at fud.no (Tore Anderson)
Date: Wed, 26 Aug 2015 06:49:53 +0200
Subject: Production-scale NAT64
In-Reply-To: <CAP-guGVjCZ=fn3bNp9BePfF=cb0CQR2pNwAZibZ99xMvqOffTA@mail.gmail.com>
References: <55D5D9AA.2080203@forethought.net>
 <CAP-guGV==1SoDR_PKXVo852+t0c+cojT-poMo5X+cz1PveoNjQ@mail.gmail.com>
 <CAD6AjGT+GeBtwv3far3NJidr6bijQb=TJVB5gh+kkY3xcWg4Vw@mail.gmail.com>
 <CAP-guGVjCZ=fn3bNp9BePfF=cb0CQR2pNwAZibZ99xMvqOffTA@mail.gmail.com>
Message-ID: <20150826064953.6bce50d7@envy.fud.no>

* William Herrin

> On Thu, Aug 20, 2015 at 1:22 PM, Ca By <cb.list6 at gmail.com> wrote:
> > On Thu, Aug 20, 2015 at 9:36 AM, William Herrin <bill at herrin.us> wrote:  
> >> Seriously though, if you want to run a v6-only network and still
> >> support access to IPv4 Internet resources, consider 464XLAT or
> >> DS-Lite.
> >
> > NAT64 is a required component of 464XLAT.
> 
> Sort of, technically, but not really.

Yes really. See below.

> 464XLAT does not require DNS64 and provides client software with an
> IPv4 interface. IPv4 software that has no idea IPv6 exists sends IPv4
> packets which get translated to IPv6 packets. Those packets are routed
> to the carrier NAT box which then translates these specially crafted
> IPv6 packets back to IPv4 packets.

What do you think the ?carrier NAT box? in 464XLAT is, exactly?

No need to guess, we can check the 464XLAT specification:

http://tools.ietf.org/html/rfc6877#section-2

>  PLAT:   PLAT is provider-side translator (XLAT) that complies with
>          [RFC6146].  It translates N:1 global IPv6 addresses to global
>          IPv4 addresses, and vice versa.

Let's check that reference:

http://tools.ietf.org/html/rfc6146#section-1

>  This document specifies stateful NAT64, a mechanism for IPv4-IPv6
>  transition and IPv4-IPv6 coexistence.

Lo and behold! Your 464XLAT ?carrier NAT box? (a.k.a. ?PLAT?) *is* a
NAT64 box. Thus, if you intend to deploy 464XLAT in production, you'll
going to need a production scale NAT64 implementation.

To answer the Jawaid's original question, I'm very happy with Jool
(http://jool.mx) for my NAT64 (and SIIT) needs, which is a open-source
Linux-based software solution. It has no problems handling several Gb/s
of traffic using a couple of years old x86 server without any tuning,
so if the capacity required is moderate this might be a cost-effective
alternative to a dedicated boxes from the one of the router/network
appliance vendors.

Tore

From ramy.ihashish at gmail.com  Wed Aug 26 12:40:23 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Wed, 26 Aug 2015 15:40:23 +0300
Subject: DDoS appliances reviews needed
Message-ID: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>

Good day all,

Anybody here has experienced a PoC for any anti DDoS appliance, or already
using a anti DDoS appliance in production and able to share his user
experience/review?

We need to collect good reviews from people whom got their hands dirty with
the configuration/attack mitigation, real experience.

Thanks,

Ramy

From list at satchell.net  Wed Aug 26 12:49:27 2015
From: list at satchell.net (Stephen Satchell)
Date: Wed, 26 Aug 2015 05:49:27 -0700
Subject: DDoS appliances reviews needed
In-Reply-To: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
Message-ID: <55DDB5D7.6010407@satchell.net>

On 08/26/2015 05:40 AM, Ramy Hashish wrote:
> Anybody here has experienced a PoC for any anti DDoS appliance, or already
> using a anti DDoS appliance in production and able to share his user
> experience/review?
>
> We need to collect good reviews from people whom got their hands dirty with
> the configuration/attack mitigation, real experience.

Is this for publication?  What are you paying for such reviews?  Who is 
the audience?


From aftab.siddiqui at gmail.com  Wed Aug 26 12:54:26 2015
From: aftab.siddiqui at gmail.com (Aftab Siddiqui)
Date: Wed, 26 Aug 2015 12:54:26 +0000
Subject: DDoS appliances reviews needed
In-Reply-To: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
Message-ID: <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>

Hi,


> Anybody here has experienced a PoC for any anti DDoS appliance, or already
> using a anti DDoS appliance in production and able to share his user
> experience/review?
>

only interested in appliance? why not scrubbing services? is it for own use
(industry reviews before purchase) or some article/publication/research?

Best Wishes,

Aftab A. Siddiqui

From izaac at setec.org  Wed Aug 26 14:13:35 2015
From: izaac at setec.org (Izaac)
Date: Wed, 26 Aug 2015 10:13:35 -0400
Subject: Production-scale NAT64
In-Reply-To: <55D5D9AA.2080203@forethought.net>
References: <55D5D9AA.2080203@forethought.net>
Message-ID: <20150826T141310Z@localhost>

On Thu, Aug 20, 2015 at 07:44:10AM -0600, Jawaid Shell2 wrote:
> Who out there is using production-scale NAT64? What solution are you using?

Yes, I'm curious about this too.  I'd like a solid list of providers to
avoid.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__

From mark.tinka at seacom.mu  Wed Aug 26 14:19:46 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 26 Aug 2015 16:19:46 +0200
Subject: Production-scale NAT64
In-Reply-To: <20150826T141310Z@localhost>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
Message-ID: <55DDCB02.8070904@seacom.mu>



On 26/Aug/15 16:13, Izaac wrote:

> Yes, I'm curious about this too.  I'd like a solid list of providers to
> avoid.

NAT64 is opt-in.

It will mostly be used for customers that can no longer obtain IPv4
addresses.

Service providers do not like NAT64 anymore than you do, but there needs
to be some way to bridge both protocols in the interim.

What you should be more interested in is which service providers have
deployed it at scale where it is not causing problems, as those are the
ones you want to be connected to when the IPv4-hell hiteth the faneth!

Mark.

From cb.list6 at gmail.com  Wed Aug 26 14:28:08 2015
From: cb.list6 at gmail.com (Ca By)
Date: Wed, 26 Aug 2015 07:28:08 -0700
Subject: Production-scale NAT64
In-Reply-To: <55DDCB02.8070904@seacom.mu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
Message-ID: <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>

On Wed, Aug 26, 2015 at 7:19 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 26/Aug/15 16:13, Izaac wrote:
>
> > Yes, I'm curious about this too.  I'd like a solid list of providers to
> > avoid.
>
> NAT64 is opt-in.
>
> It will mostly be used for customers that can no longer obtain IPv4
> addresses.
>
> Service providers do not like NAT64 anymore than you do, but there needs
> to be some way to bridge both protocols in the interim.
>
> What you should be more interested in is which service providers have
> deployed it at scale where it is not causing problems, as those are the
> ones you want to be connected to when the IPv4-hell hiteth the faneth!
>
> Mark.
>

>From largish deployment ...

Another relevant metric, less than 25% of my mobile subscribers traffic
require NAT64 translating.  75+% of bits flows through end-to-end IPv6
(thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).

From jared at puck.nether.net  Wed Aug 26 14:32:51 2015
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 26 Aug 2015 10:32:51 -0400
Subject: Production-scale NAT64
In-Reply-To: <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
Message-ID: <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>


> On Aug 26, 2015, at 10:28 AM, Ca By <cb.list6 at gmail.com> wrote:
> 
> 
>> From largish deployment ...
> 
> Another relevant metric, less than 25% of my mobile subscribers traffic
> require NAT64 translating.  75+% of bits flows through end-to-end IPv6
> (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).

This for me is an important note, because if your site only gives out an A address,
it?s going to be slowed by the NAT process.  I have noticed the IPv4 penalty getting
worse with many locations.

- Jared

From mark.tinka at seacom.mu  Wed Aug 26 14:35:57 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 26 Aug 2015 16:35:57 +0200
Subject: Production-scale NAT64
In-Reply-To: <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
Message-ID: <55DDCECD.4060403@seacom.mu>



On 26/Aug/15 16:28, Ca By wrote:

>
>
> From largish deployment ...
>
> Another relevant metric, less than 25% of my mobile subscribers
> traffic require NAT64 translating.  75+% of bits flows through
> end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo,
> Linkedin and so on ...). 

And trust me, Cameron knows what's on about...

And just in case it's not obvious, fewer and fewer bits will need to hit
the NAT64 gateways as more and more of the Internet turns up IPv6.

And the beauty of it all, NAT64-based service providers don't have to
decommission anything in the future; this is one of the key points
around using NAT64 as transition tech.

Mark.


From mark.tinka at seacom.mu  Wed Aug 26 14:39:11 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 26 Aug 2015 16:39:11 +0200
Subject: Production-scale NAT64
In-Reply-To: <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
Message-ID: <55DDCF8F.6020204@seacom.mu>



On 26/Aug/15 16:32, Jared Mauch wrote:
> This for me is an important note, because if your site only gives out an A address,
> it?s going to be slowed by the NAT process.  I have noticed the IPv4 penalty getting
> worse with many locations.

But you only need to hit the NAT64 gateway "if" you are IPv6-only.

If you're dual-stacked, your route to an A record will not hit the NAT64
gateway.

Mark.

From Valdis.Kletnieks at vt.edu  Wed Aug 26 15:16:11 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 26 Aug 2015 11:16:11 -0400
Subject: Production-scale NAT64
In-Reply-To: <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
Message-ID: <63682.1440602171@turing-police.cc.vt.edu>

On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:

> Another relevant metric, less than 25% of my mobile subscribers traffic
> require NAT64 translating.  75+% of bits flows through end-to-end IPv6
> (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).

So I'm guessing that 75% of the traffic flows with better latency than
the 25% IPvhorse-n-buggy traffic? ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150826/b5e2f5bd/attachment.pgp>

From ramy.ihashish at gmail.com  Wed Aug 26 15:20:32 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Wed, 26 Aug 2015 18:20:32 +0300
Subject: DDoS appliances reviews needed
In-Reply-To: <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
 <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>
Message-ID: <CAOLsBOumqcRU9t8rHF6PvtV2c2EgBBH0qRmGLS+GL35cs74ATA@mail.gmail.com>

Hello Aftab,

Sure we are interested in scrubbing centers, and we will have an on premise
appliance as well, but let's make the scope of this thread limited to the
on premise appliances.

If you want to discuss a certain scrubbing center subscription, let's have
this chat offline.

Thanks,

Ramy

On Wed, Aug 26, 2015 at 3:54 PM, Aftab Siddiqui <aftab.siddiqui at gmail.com>
wrote:

> Hi,
>
>
>> Anybody here has experienced a PoC for any anti DDoS appliance, or already
>> using a anti DDoS appliance in production and able to share his user
>> experience/review?
>>
>
> only interested in appliance? why not scrubbing services? is it for own
> use (industry reviews before purchase) or some
> article/publication/research?
>
> Best Wishes,
>
> Aftab A. Siddiqui
>

From cb.list6 at gmail.com  Wed Aug 26 15:23:45 2015
From: cb.list6 at gmail.com (Ca By)
Date: Wed, 26 Aug 2015 08:23:45 -0700
Subject: Production-scale NAT64
In-Reply-To: <63682.1440602171@turing-police.cc.vt.edu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <63682.1440602171@turing-police.cc.vt.edu>
Message-ID: <CAD6AjGTv0DCtmmdydmTDnFoZ7p2rU0HG4ai0JDew7ADkJAdhxw@mail.gmail.com>

On Wed, Aug 26, 2015 at 8:16 AM, <Valdis.Kletnieks at vt.edu> wrote:

> On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
>
> > Another relevant metric, less than 25% of my mobile subscribers traffic
> > require NAT64 translating.  75+% of bits flows through end-to-end IPv6
> > (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on
> ...).
>
> So I'm guessing that 75% of the traffic flows with better latency than
> the 25% IPvhorse-n-buggy traffic? ;)
>
>
Facebook says IPv6 is 20-40% faster

http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/

Another way to look at it, IPv4 is 20-40% slower than IPv6.

From mark.tinka at seacom.mu  Wed Aug 26 15:59:24 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 26 Aug 2015 17:59:24 +0200
Subject: Production-scale NAT64
In-Reply-To: <63682.1440602171@turing-police.cc.vt.edu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <63682.1440602171@turing-police.cc.vt.edu>
Message-ID: <55DDE25C.7060903@seacom.mu>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 26/Aug/15 17:16, Valdis.Kletnieks at vt.edu wrote:

>
> So I'm guessing that 75% of the traffic flows with better latency than
> the 25% IPvhorse-n-buggy traffic? ;)

Practically, when we've tested NAT64 at reasonable scale, it does not
add any noticeable slow-down provided your hardware is decent and you're
operating the forwarding plane within the limits supported by the vendor.

Yes, I know this can quickly become a cost run-away problem, but for
better or worse, that is what separates the wheat from the other thing...

The point is you need a transition tech. solution if you are serious
about providing a service to your customers. Assuming you don't is
living in denial.

Mark.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJV3eJcAAoJEGcZuYTeKm+G2nUP/14tVjKaorUddJPaIfa3qm5y
GQ7EGq343ssihW1Vy335xtmXwUX2ti/WelavXBZD8WEU/17wYdy0Yoq7PcnKVk/+
8NufD9Zp6dDjugIDMczjZbn6NQ/aQjwQ9TVk3SAH90iAgBMkT3SfE3NJE9CqK+LD
90+7wIwNUdY53z8x8xBfPqu6Mf1HSkbngifyJ9piDsAs3Pdki++k8IXJEjDeysop
5EPeCeQydgIMzj2v4dxLhbAI8BGYmPG5501eJbmyoehB3mWtFp3be0wE8RtAHwMY
ABUT6dyYAr/yu7lt52ALQUOyN9avodagZR5tRbAck/Ah/0hYpsOErvEo3ZiuUrPE
FV0t4Gp6hXcG4/7tgThaFMGWWYomZXCFvO9vSPzMd+CI30dVJ4qtCFLHYQy3PoM+
a9S9ZAvN6qrL+aPANbkg2IIUBv2EiSVQ8tdISf5urQtbyGByEd/31LCaMJZGRnRa
Rg38C9K/NtHimGXADR1NZ1KjfrN4tECFXydEYS59FNf29oR0F/jAD4lZPmTTXDXK
o5rmfXdLR37Llwr2MStPM41EOQB9tLY+rxwjHIxgl5ZVm6yv3727IAufXDG7gGVk
YZJBtVvH63wZEK6o+ki2HdAA2QLr4gdxcsN2KWzQtnwbA3E5tZeyd8jSdDe3Hfze
rNX7Ccr2hwkAEH65bLmx
=nQN9
-----END PGP SIGNATURE-----


From tomas.lynch at gmail.com  Wed Aug 26 16:29:04 2015
From: tomas.lynch at gmail.com (Tomas Lynch)
Date: Wed, 26 Aug 2015 12:29:04 -0400
Subject: LTE
In-Reply-To: <CAB1OdL5_qtK6QMyfVmOwuVodOd8MoUaJW1_SPK23cu-QBMHT-w@mail.gmail.com>
References: <C12CA40900F4E0448A2D4E66DFA6A59B20783A25D4@Demekin.FSI.local>
 <CAB1OdL5_qtK6QMyfVmOwuVodOd8MoUaJW1_SPK23cu-QBMHT-w@mail.gmail.com>
Message-ID: <CAGEujU_ENHjqOp5qfmfD-GdVLao+1py3HAOHaM+QKJvQDBvM0A@mail.gmail.com>

Ericsson SSR or SE.

On Tue, Aug 25, 2015 at 5:38 PM, Bryan Ignatow <bryan at ignatow.org> wrote:

> Nathan,
>
> I know someone.  Contact me off list and I will get you and he connected.
>
> Bryan
>
> On Tue, Aug 25, 2015 at 4:33 PM Nathan Anderson <nathana at fsr.com> wrote:
>
> > Is there anybody here who is fluent in LTE/3GPP networks and the
> standards
> > that govern them?  I'm not sure where else to look.  I have a very
> specific
> > question about UEs, UICCs, and the security negotiation (integrity &
> > ciphers) that occurs during attachment both on the AS and NAS layers, and
> > so far I have not found our vendor to be very helpful.  If there is
> > somebody out there that knows something about this area, and is willing
> to
> > chat with me about it, feel free to drop me a line off-list.
> >
> > Thanks much,
> >
> > --
> > Nathan Anderson
> > First Step Internet, LLC
> > nathana at fsr.com
> >
> >
>

From tomas.lynch at gmail.com  Wed Aug 26 16:33:39 2015
From: tomas.lynch at gmail.com (Tomas Lynch)
Date: Wed, 26 Aug 2015 12:33:39 -0400
Subject: LTE
In-Reply-To: <CAGEujU_ENHjqOp5qfmfD-GdVLao+1py3HAOHaM+QKJvQDBvM0A@mail.gmail.com>
References: <C12CA40900F4E0448A2D4E66DFA6A59B20783A25D4@Demekin.FSI.local>
 <CAB1OdL5_qtK6QMyfVmOwuVodOd8MoUaJW1_SPK23cu-QBMHT-w@mail.gmail.com>
 <CAGEujU_ENHjqOp5qfmfD-GdVLao+1py3HAOHaM+QKJvQDBvM0A@mail.gmail.com>
Message-ID: <CAGEujU8LiioPBRPGS9-SBsKyDBe0xpD9UySGrEuysB32_hUiFg@mail.gmail.com>

Sorry, wrong thread!

On Wed, Aug 26, 2015 at 12:29 PM, Tomas Lynch <tomas.lynch at gmail.com> wrote:

> Ericsson SSR or SE.
>
> On Tue, Aug 25, 2015 at 5:38 PM, Bryan Ignatow <bryan at ignatow.org> wrote:
>
>> Nathan,
>>
>> I know someone.  Contact me off list and I will get you and he connected.
>>
>> Bryan
>>
>> On Tue, Aug 25, 2015 at 4:33 PM Nathan Anderson <nathana at fsr.com> wrote:
>>
>> > Is there anybody here who is fluent in LTE/3GPP networks and the
>> standards
>> > that govern them?  I'm not sure where else to look.  I have a very
>> specific
>> > question about UEs, UICCs, and the security negotiation (integrity &
>> > ciphers) that occurs during attachment both on the AS and NAS layers,
>> and
>> > so far I have not found our vendor to be very helpful.  If there is
>> > somebody out there that knows something about this area, and is willing
>> to
>> > chat with me about it, feel free to drop me a line off-list.
>> >
>> > Thanks much,
>> >
>> > --
>> > Nathan Anderson
>> > First Step Internet, LLC
>> > nathana at fsr.com
>> >
>> >
>>
>
>

From tomas.lynch at gmail.com  Wed Aug 26 16:34:15 2015
From: tomas.lynch at gmail.com (Tomas Lynch)
Date: Wed, 26 Aug 2015 12:34:15 -0400
Subject: BRAS sugestion
In-Reply-To: <CF962BA7-AA67-4A6E-B2EC-5AB8DB4A8E21@telcoinabox.com>
References: <1394889029.4809714.1439564780456.JavaMail.yahoo@mail.yahoo.com>
 <CF962BA7-AA67-4A6E-B2EC-5AB8DB4A8E21@telcoinabox.com>
Message-ID: <CAGEujU9o81JCJ2gXo0Ou-rGxbFFhiJNrxuvBehJf3c7TYUihxg@mail.gmail.com>

You can try Ericsson SSR or SE.

On Fri, Aug 14, 2015 at 9:58 PM, Ahad Aboss <ahad at telcoinabox.com> wrote:

> Julian
>
> If you have budget constraints, try getting 2 x ASR1004, else ASR1006 with
> dual RP would take care of your needs.
>
>
> Cheers
>
> Ahad
> Sent from my iPhone
>
> > On 15 Aug 2015, at 1:06 am, Julian Eble <julianeble at yahoo.com.br> wrote:
> >
> > Hello Nanog,
> > Our company are constantly growing and we're looking for a 30k+
> subscribers BRAS, does the community have a sugestion?
> >
> > Thank you!
>

From Valdis.Kletnieks at vt.edu  Wed Aug 26 16:42:43 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 26 Aug 2015 12:42:43 -0400
Subject: Production-scale NAT64
In-Reply-To: <55DDE25C.7060903@seacom.mu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <63682.1440602171@turing-police.cc.vt.edu>
 <55DDE25C.7060903@seacom.mu>
Message-ID: <20040.1440607363@turing-police.cc.vt.edu>

On Wed, 26 Aug 2015 17:59:24 +0200, Mark Tinka said:

> The point is you need a transition tech. solution if you are serious
> about providing a service to your customers. Assuming you don't is
> living in denial.

Actually, the point is that if you're a content provider, there's a good
chance that turning up IPv6 will result in happier eyeballs, which can
probably be leveraged into a competitive advantage.  And the more content
providers do that, the smaller your transition problem becomes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150826/4e951897/attachment.pgp>

From mark.tinka at seacom.mu  Wed Aug 26 16:45:10 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 26 Aug 2015 18:45:10 +0200
Subject: Production-scale NAT64
In-Reply-To: <20040.1440607363@turing-police.cc.vt.edu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <63682.1440602171@turing-police.cc.vt.edu> <55DDE25C.7060903@seacom.mu>
 <20040.1440607363@turing-police.cc.vt.edu>
Message-ID: <55DDED16.2040706@seacom.mu>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 26/Aug/15 18:42, Valdis.Kletnieks at vt.edu wrote:

>
> Actually, the point is that if you're a content provider, there's a good
> chance that turning up IPv6 will result in happier eyeballs, which can
> probably be leveraged into a competitive advantage.  And the more content
> providers do that, the smaller your transition problem becomes.

I can't argue with you there.

But the problem has to be attacked from all sides. We can't just sit
back and hope for the best; that's already nearly 2x decades in the
making...

Mark.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJV3e0WAAoJEGcZuYTeKm+G6DQP/iXbz6v6xWqAOyLU4TyVWJLa
xcf0GBajZ7GR2iHNIqJ/usYAZg1nVvApoaBPd1tCegp8QWM2nzrAz1hRYFZnTZVY
LTm40+6UD37/tMML9WgXyXw3qk/23LR0bY2IQZcwBtzscpStAEWCB304GPmyRS1X
JFtunFTxE8zP1iD1ErE8CgHvJMN5vRGyJpASxWyk7ZS3UFWDfH1TVur+U9PsqiuZ
av0tobjp+/tLgkMYTU2jRhnVbgnhXrkawS0uvT8uyt8ivn8Igf/f15SkM+X4DIJs
Ck1Bu2cTtNW8QLuLbu/ue8M9S1JU/jHKS18LN0medoByqPJ1fLL1Ur3Xl2SzBDkm
Fr9IZftTvLnpNvyP/FXLF6XH/CyzU1+lChOvhZ8Bmy305ETZFNz177fsjpcdVogg
NiZ6GzHhA7wZ1NWrkqSVwdvCcg9kd413MKbhnWPi7cKB1Yi6Tewcam8+xCWH56T7
j2+2qhT3FPQHO5viVgfFEAhCB7PW2p9HRzf7mlpq7ykFIZG4t0oYpXqlBNuVd07o
7qKRIDFM8Ym8Po4edKxQLoW3w0yk8HDfcb8ByiDuoyDHX/ZcrKZY2ME6WTyUBgKf
58w/0IbSJaeTHTjyAaZu/MwgP/WFBzul6sKnXh3aQrdrVOo6xrcW0EvvN+wZGD5D
AjhpcWdteKjf/Smv/HlG
=igCd
-----END PGP SIGNATURE-----


From nanogml at Mail.DDoS-Mitigator.net  Wed Aug 26 17:53:15 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Wed, 26 Aug 2015 10:53:15 -0700
Subject: DDoS appliances reviews needed
In-Reply-To: <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
 <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>
Message-ID: <20150826175315.GA10152@Mail.DDoS-Mitigator.net>


hi ramy

On 08/26/15 at 12:54pm, Aftab Siddiqui wrote:
> 
> > Anybody here has experienced a PoC for any anti DDoS appliance, or already
> > using a anti DDoS appliance in production and able to share his user
> > experience/review?
> >
> 
> only interested in appliance? why not scrubbing services? is it for own use
> (industry reviews before purchase) or some article/publication/research?

see previous similar thread for some "real world reviews by folks"

http://mailman.nanog.org/pipermail/nanog/2015-April/074410.html

i think a "benchmarking ddos lab" would be fun to build and publish findings..
to test all the ddos appliances from those competitors willing to participate

---

for your "reviewing" or collecing info from folks ..
- what's your metrics that is important to you ?
- what (ddos) problems are you trying to resolve ?

- do you want to see the ddos attacks in progress and how you're being attacked
	http://ddos-mitigator.net/cgi-bin/IPtables-GUI.pl

- do you want 100% automated ddos defense with zero false positives :-)

my $0.02 ddos experiences n summary over the years, aka mitigation in production use ...

usually, arp-based ddos attacks requires fixing your infrastructure, 
  a ddos appliance may not help you

usually, udp and icmp ddos attacks can only be resolved by the ISP or scrubbing centers
	- if you limit udp/icmp at your appliance, the damage is already done,
	since those packets used your bandwidth, cpu, memory, diskspace and your time

spoof'd source addresses can only be resolved by having the ISP preventing outgoing
spoofed address ( fix egress filters ) at their edge routers

my requirement: all tcp-based ddos attacks must be tarpit'd ... ddos attacks
are now 1% of it's peak a few years ago where "firefox google.com" wouldn't come up

	- you must be able to distinguish legit tcp traffic from ddos attacks
	which is ez if you build/install/configure the servers properly

	i want the attacking zombies and script kiddies to pay a penalty for 
	attacking my customer's servers

	to sustain a 100,000 tcp packets attack requires lots of kernel memory 
	( 100,000 packets * 1500 byte/packet * 120 seconds ) for 2minute tcp timeouts 

	there are 65,535 tcp they could be attacking ... imho, an ssh-based solution
	or apache-based solution would be useless ... add another 65,535 udp ports

always keep your servers up to date ... patch your OS, apps, etc, etc

volumetric attacks can only be resolved by (expensive) ddos scrubbers or installing 
your own geographcially separated colo in usa, europe, asia like the scrubbers ... 
if you are high profile target, the ddos attackers probably has more bandwidth than 
you could afford and the ddos attacks will probably make the evening news

magic pixie dust
alvin
# DDoS-Mitigator.net/Competitors
# DDoS-Mitigator.net/InHouse-vs-Cloud
# DDoS-Simulator.net
#

From dmburgess at linktechs.net  Wed Aug 26 19:40:33 2015
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Wed, 26 Aug 2015 19:40:33 +0000
Subject: Zayo Contact
Message-ID: <B542CC3757123745918E6B7E4D2EEE934556FE@zeus.lti.local>

I have a customer with a fiber outage with some Zayo IPs, Zayo is adverting the /24, would love to have someone contact me from zayo; as we need that advertisement turned off so we can get inbound though another provider until the fiber is fixed.:(

Thanks,

[DennisBurgessSignature]
www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>


From ryan at hack.net  Wed Aug 26 21:34:43 2015
From: ryan at hack.net (Ryan K. Brooks)
Date: Wed, 26 Aug 2015 16:34:43 -0500
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
Message-ID: <55DE30F3.3030900@hack.net>

Seeing packet loss on AS4323 since 2:30 Central time.   NOC is 
unresponsive to phone and email.  Anyone have an idea what's going on 
over there?

From rafael at gav.ufsc.br  Wed Aug 26 21:41:45 2015
From: rafael at gav.ufsc.br (Rafael Possamai)
Date: Wed, 26 Aug 2015 16:41:45 -0500
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <55DE30F3.3030900@hack.net>
References: <55DE30F3.3030900@hack.net>
Message-ID: <CAJB2g-HLx1F8q94-kt2ckANGZ0PM0nmV42M8enw6s8Ht3cK0hA@mail.gmail.com>

I have been seeing the same issues, but haven't heard anything back yet. It
has improved in the last 30 minutes or so, see below.


http://imgur.com/KVAzetA



On Wed, Aug 26, 2015 at 4:34 PM, Ryan K. Brooks <ryan at hack.net> wrote:

> Seeing packet loss on AS4323 since 2:30 Central time.   NOC is
> unresponsive to phone and email.  Anyone have an idea what's going on over
> there?
>

From ryan at hack.net  Wed Aug 26 21:44:54 2015
From: ryan at hack.net (Ryan K. Brooks)
Date: Wed, 26 Aug 2015 16:44:54 -0500
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CAJB2g-HLx1F8q94-kt2ckANGZ0PM0nmV42M8enw6s8Ht3cK0hA@mail.gmail.com>
References: <55DE30F3.3030900@hack.net>
 <CAJB2g-HLx1F8q94-kt2ckANGZ0PM0nmV42M8enw6s8Ht3cK0hA@mail.gmail.com>
Message-ID: <55DE3356.6060009@hack.net>

Seems to be impacting their entire network now.

On 8/26/15 4:41 PM, Rafael Possamai wrote:
> I have been seeing the same issues, but haven't heard anything back 
> yet. It has improved in the last 30 minutes or so, see below.
>
>
> http://imgur.com/KVAzetA
> *
> *
>
>
> On Wed, Aug 26, 2015 at 4:34 PM, Ryan K. Brooks <ryan at hack.net 
> <mailto:ryan at hack.net>> wrote:
>
>     Seeing packet loss on AS4323 since 2:30 Central time.   NOC is
>     unresponsive to phone and email.  Anyone have an idea what's going
>     on over there?
>
>


From jhellenthal at dataix.net  Thu Aug 27 00:33:11 2015
From: jhellenthal at dataix.net (Jason Hellenthal)
Date: Wed, 26 Aug 2015 19:33:11 -0500
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <55DE3356.6060009@hack.net>
References: <55DE30F3.3030900@hack.net>
 <CAJB2g-HLx1F8q94-kt2ckANGZ0PM0nmV42M8enw6s8Ht3cK0hA@mail.gmail.com>
 <55DE3356.6060009@hack.net>
Message-ID: <161B660B-BDEB-4ACA-A9C4-F7191ED54423@dataix.net>

Cleared up here in WI TW/Level3 COLO between 19:00 - 19:20 CST - 3235 Intertech Dr. Brookfield

> On Aug 26, 2015, at 16:44, Ryan K. Brooks <ryan at hack.net> wrote:
> 
> Seems to be impacting their entire network now.
> 
> On 8/26/15 4:41 PM, Rafael Possamai wrote:
>> I have been seeing the same issues, but haven't heard anything back yet. It has improved in the last 30 minutes or so, see below.
>> 
>> 
>> http://imgur.com/KVAzetA
>> *
>> *
>> 
>> 
>> On Wed, Aug 26, 2015 at 4:34 PM, Ryan K. Brooks <ryan at hack.net <mailto:ryan at hack.net>> wrote:
>> 
>>    Seeing packet loss on AS4323 since 2:30 Central time.   NOC is
>>    unresponsive to phone and email.  Anyone have an idea what's going
>>    on over there?
>> 
>> 
> 


--
 Jason Hellenthal
 JJH48-ARIN




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150826/2f941b81/attachment.pgp>

From mel at beckman.org  Thu Aug 27 01:01:11 2015
From: mel at beckman.org (Mel Beckman)
Date: Thu, 27 Aug 2015 01:01:11 +0000
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <161B660B-BDEB-4ACA-A9C4-F7191ED54423@dataix.net>
References: <55DE30F3.3030900@hack.net>
 <CAJB2g-HLx1F8q94-kt2ckANGZ0PM0nmV42M8enw6s8Ht3cK0hA@mail.gmail.com>
 <55DE3356.6060009@hack.net>, <161B660B-BDEB-4ACA-A9C4-F7191ED54423@dataix.net>
Message-ID: <CO1PR07MB9563ED313DB87C9F808F785A76F0@CO1PR07MB956.namprd07.prod.outlook.com>

We continue to see 10 to 20 percent packet loss crossing TW border and even between clients in the same region (e.g. LA and Santa Barbara). No news from the NOC yet.

 -mel

________________________________________
From: NANOG <nanog-bounces at nanog.org> on behalf of Jason Hellenthal <jhellenthal at dataix.net>
Sent: Wednesday, August 26, 2015 5:33 PM
To: nanog at nanog.org
Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)

Cleared up here in WI TW/Level3 COLO between 19:00 - 19:20 CST - 3235 Intertech Dr. Brookfield

> On Aug 26, 2015, at 16:44, Ryan K. Brooks <ryan at hack.net> wrote:
>
> Seems to be impacting their entire network now.
>
> On 8/26/15 4:41 PM, Rafael Possamai wrote:
>> I have been seeing the same issues, but haven't heard anything back yet. It has improved in the last 30 minutes or so, see below.
>>
>>
>> http://imgur.com/KVAzetA
>> *
>> *
>>
>>
>> On Wed, Aug 26, 2015 at 4:34 PM, Ryan K. Brooks <ryan at hack.net <mailto:ryan at hack.net>> wrote:
>>
>>    Seeing packet loss on AS4323 since 2:30 Central time.   NOC is
>>    unresponsive to phone and email.  Anyone have an idea what's going
>>    on over there?
>>
>>
>


--
 Jason Hellenthal
 JJH48-ARIN





From jared at puck.Nether.net  Thu Aug 27 01:21:14 2015
From: jared at puck.Nether.net (Jared Mauch)
Date: Wed, 26 Aug 2015 21:21:14 -0400
Subject: Production-scale NAT64
In-Reply-To: <55DDCF8F.6020204@seacom.mu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu>
Message-ID: <20150827012114.GA15533@puck.nether.net>

On Wed, Aug 26, 2015 at 04:39:11PM +0200, Mark Tinka wrote:
> On 26/Aug/15 16:32, Jared Mauch wrote:
> > This for me is an important note, because if your site only gives out an A address,
> > it?s going to be slowed by the NAT process.  I have noticed the IPv4 penalty getting
> > worse with many locations.
> 
> But you only need to hit the NAT64 gateway "if" you are IPv6-only.

	Sure...

	For DS, I could send IPv6 native and IPv4 via NAT.  I suspect this 
actually the most common home setup at this point.  It's certainly the 
way mine looks.

	I have noticed that IPv4 "feels" slow on my t-mobile usa connected
devices.  This is only a problem when interacting with legacy players on the
network, eg: financials, opensrs, airlines.  I suspect this is a 64 CGN tax.

	Waiting to see my other devices/sims see IPv6 on them via VZ and AT&T.

> If you're dual-stacked, your route to an A record will not hit the NAT64
> gateway.

	Sure, but your v4 is likely to have issues regardless and face this
penalty/tax.

	- Jared

-- 
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 mark.tinka at seacom.mu  Thu Aug 27 04:37:51 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 27 Aug 2015 06:37:51 +0200
Subject: Production-scale NAT64
In-Reply-To: <20150827012114.GA15533@puck.nether.net>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu> <20150827012114.GA15533@puck.nether.net>
Message-ID: <55DE941F.90806@seacom.mu>



On 27/Aug/15 03:21, Jared Mauch wrote:

>
> 	Sure...
>
> 	For DS, I could send IPv6 native and IPv4 via NAT.  I suspect this 
> actually the most common home setup at this point.  It's certainly the 
> way mine looks.
>
> 	I have noticed that IPv4 "feels" slow on my t-mobile usa connected
> devices.  This is only a problem when interacting with legacy players on the
> network, eg: financials, opensrs, airlines.  I suspect this is a 64 CGN tax.
>
> 	Waiting to see my other devices/sims see IPv6 on them via VZ and AT&T.

If your IPv4 is public, you should not "feel slow". Of course, if your
IPv4 is private, then yes, some NAT44 may happen somewhere along the path.


> 	Sure, but your v4 is likely to have issues regardless and face this
> penalty/tax.

But that would be a function of NAT44 if you're on private IPv4, and
have nothing to do with the NAT64.

In our deployment, we do not offer customers private IPv4 addresses. I
suppose we can afford to do this because a) we still have lots of public
IPv4, b) we are not a mobile carrier. So any of our customers with IPv4
will never hit the NAT64 gateway.

When we do run out of public IPv4 addresses (and cannot get anymore from
AFRINIC), all new customers will be assigned IPv6 addresses. These will
hit a NAT64 gateway if they want to talk to legacy resources on the
Internet.

Mark.

From tore at fud.no  Thu Aug 27 04:53:46 2015
From: tore at fud.no (Tore Anderson)
Date: Thu, 27 Aug 2015 06:53:46 +0200
Subject: Production-scale NAT64
In-Reply-To: <55DE941F.90806@seacom.mu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu>
 <20150827012114.GA15533@puck.nether.net> <55DE941F.90806@seacom.mu>
Message-ID: <20150827065346.58554fa7@echo.ms.redpill-linpro.com>

Hi Mark,

* Mark Tinka <mark.tinka at seacom.mu>

> In our deployment, we do not offer customers private IPv4 addresses. I
> suppose we can afford to do this because a) we still have lots of
> public IPv4, b) we are not a mobile carrier. So any of our customers
> with IPv4 will never hit the NAT64 gateway.
> 
> When we do run out of public IPv4 addresses (and cannot get anymore
> from AFRINIC), all new customers will be assigned IPv6 addresses.

Why wait until then?

Any particular reason why you cannot already today provide IPv6
addresses to your [new] customers in parallel with IPv4?

Tore

From mark.tinka at seacom.mu  Thu Aug 27 05:11:49 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 27 Aug 2015 07:11:49 +0200
Subject: Production-scale NAT64
In-Reply-To: <20150827065346.58554fa7@echo.ms.redpill-linpro.com>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu> <20150827012114.GA15533@puck.nether.net>
 <55DE941F.90806@seacom.mu>
 <20150827065346.58554fa7@echo.ms.redpill-linpro.com>
Message-ID: <55DE9C15.4070608@seacom.mu>



On 27/Aug/15 06:53, Tore Anderson wrote:

> Why wait until then?

I didn't say that we're waiting :-)...

>
> Any particular reason why you cannot already today provide IPv6
> addresses to your [new] customers in parallel with IPv4?

As a standard delivery of service, all our customers (BGP- and
non-BGP-based) are assigned IPv6 addresses by default. Point-to-point
for the BGP-based customers, and point-to-point + onward LAN assignments
for the non-BGP-based customers.

We do (and configure) this regardless of whether customers have asked
for it or not. In reality, 70% of the time it's like pulling teeth
getting customers to configure their end of the IPv6 point-to-point
address, much less turn-up an IPv6 BGP session. Reasons range from, "We
do not have a /32 IPv6 allocation yet", "Our router does not support
IPv6 yet", "We shall get to it in time, we are busy with other things
now", "It is not important to us", "We only have one interface in our
whole network with IPv6, so let's forget about it for now", "What is
IPv6? Oh, that - no thanks", and so on and so on.

30% of the time, however, we are dealing with a switched-on customer
that is happy to turn it up, and would even chase us for the same. We
like these types of customers.

You won't find a customer order or port in our network that does not
have IPv6 enabled. It's just all about getting their side sorted out.
And the team have been going out of their way to help them turn-up,
e.g., recommending the minimum software they should upgrade to to
support IPv6, helping them reach out to AFRINIC to apply for their /32
IPv6 allocation, helping them set things up on their end, nagging them
weekly on when they will get their side up, e.t.c. It's never-ending work.

Same things goes for peering - we always ask peers to turn-up both IPv4
and IPv6 at the same time. For the majority of peers, once the IPv4
session is up, they disappear. But we keep nagging, and nagging and
nagging, and many times we are successful in getting IPv6 going.
Sometimes, however, it's all falling on deaf ears. But it is good work,
so we do not let up.

All I was saying before is that when we can no longer hand out public
IPv4 addresses to new customers in the future, those customers will
require the NAT64 gateway to speak to IPv4-only resources. Hopefully, by
the time that happens, the demand on the NAT64 gateways is as close to
0% as possible.

Mark.


From marka at isc.org  Thu Aug 27 05:16:57 2015
From: marka at isc.org (Mark Andrews)
Date: Thu, 27 Aug 2015 15:16:57 +1000
Subject: Production-scale NAT64
In-Reply-To: Your message of "Thu, 27 Aug 2015 06:53:46 +0200."
 <20150827065346.58554fa7@echo.ms.redpill-linpro.com>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu> <20150827012114.GA15533@puck.nether.net>
 <55DE941F.90806@seacom.mu>
 <20150827065346.58554fa7@echo.ms.redpill-linpro.com>
Message-ID: <20150827051657.4F33B36446DF@rock.dv.isc.org>


In message <20150827065346.58554fa7 at echo.ms.redpill-linpro.com>, Tore Anderson 
writes:
> Hi Mark,
> 
> * Mark Tinka <mark.tinka at seacom.mu>
> 
> > In our deployment, we do not offer customers private IPv4 addresses. I
> > suppose we can afford to do this because a) we still have lots of
> > public IPv4, b) we are not a mobile carrier. So any of our customers
> > with IPv4 will never hit the NAT64 gateway.
> > 
> > When we do run out of public IPv4 addresses (and cannot get anymore
> > from AFRINIC), all new customers will be assigned IPv6 addresses.
> 
> Why wait until then?
> 
> Any particular reason why you cannot already today provide IPv6
> addresses to your [new] customers in parallel with IPv4?
> 
> Tore

Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
all of which are better solutions than NAT64.  NAT64 + DNS64 which
breaks DNSSEC.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From ramy.ihashish at gmail.com  Thu Aug 27 05:22:20 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Thu, 27 Aug 2015 08:22:20 +0300
Subject: DDoS appliances reviews needed
In-Reply-To: <20150826175315.GA10152@Mail.DDoS-Mitigator.net>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
 <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>
 <20150826175315.GA10152@Mail.DDoS-Mitigator.net>
Message-ID: <CAOLsBOsD3_U0xVTf+SoYc9A6D-FGOKW3nuQfQc8xp6bDHVYm9w@mail.gmail.com>

Thank you Alvin, I have just remembered that I wanted to reply to your
previous input on Wanguard versus the other vendors in the market, I will
reply this there.

I can't get exactly what you are doing, do you have your own mitigation SW?
If so I would like to know more about it.



On Wed, Aug 26, 2015 at 8:53 PM, alvin nanog <
nanogml at mail.ddos-mitigator.net> wrote:

>
> hi ramy
>
> On 08/26/15 at 12:54pm, Aftab Siddiqui wrote:
> >
> > > Anybody here has experienced a PoC for any anti DDoS appliance, or
> already
> > > using a anti DDoS appliance in production and able to share his user
> > > experience/review?
> > >
> >
> > only interested in appliance? why not scrubbing services? is it for own
> use
> > (industry reviews before purchase) or some article/publication/research?
>
> see previous similar thread for some "real world reviews by folks"
>
> http://mailman.nanog.org/pipermail/nanog/2015-April/074410.html
>
> i think a "benchmarking ddos lab" would be fun to build and publish
> findings..
> to test all the ddos appliances from those competitors willing to
> participate
>
> ---
>
> for your "reviewing" or collecing info from folks ..
> - what's your metrics that is important to you ?
>

Our important metrics includes but not limited to the following:

- Ability to mitigate all kinds of volumetric DDoS attacks.
- Ability to mitigate application level attacks for at least HTTP, HTTPs,
SMTP and DNS.
- Time-to-detect and time-to-mitigate.
- False positives.
- Response time to the management plan.
- Ability to sniff packets for further analysis with the support.
- Granularity of detection thresholds.
- Percentage of DDoS attack leakage.
- Multitenancy (We are an ISP)


> - what (ddos) problems are you trying to resolve ?
>

- Fast to detect/mitigate appliance, no problem to work inline.


>
> - do you want to see the ddos attacks in progress and how you're being
> attacked
>         http://ddos-mitigator.net/cgi-bin/IPtables-GUI.pl
>
> - do you want 100% automated ddos defense with zero false positives :-)
>
> my $0.02 ddos experiences n summary over the years, aka mitigation in
> production use ...
>
>
> my requirement: all tcp-based ddos attacks must be tarpit'd ... ddos
> attacks
> are now 1% of it's peak a few years ago where "firefox google.com"
> wouldn't come up
>
>         - you must be able to distinguish legit tcp traffic from ddos
> attacks
>         which is ez if you build/install/configure the servers properly
>

Could you please give more details on this?


>
>         i want the attacking zombies and script kiddies to pay a penalty
> for
>         attacking my customer's servers
>


Could you please give more details about how to tarpit?

From mark.tinka at seacom.mu  Thu Aug 27 05:32:46 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 27 Aug 2015 07:32:46 +0200
Subject: Production-scale NAT64
In-Reply-To: <20150827051657.4F33B36446DF@rock.dv.isc.org>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu> <20150827012114.GA15533@puck.nether.net>
 <55DE941F.90806@seacom.mu>
 <20150827065346.58554fa7@echo.ms.redpill-linpro.com>
 <20150827051657.4F33B36446DF@rock.dv.isc.org>
Message-ID: <55DEA0FE.1010204@seacom.mu>



On 27/Aug/15 07:16, Mark Andrews wrote:

>
> Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
> all of which are better solutions than NAT64.  NAT64 + DNS64 which
> breaks DNSSEC.

Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the
dust settles.

There is value in that.

Mark.

From ramy.ihashish at gmail.com  Thu Aug 27 05:54:18 2015
From: ramy.ihashish at gmail.com (Ramy Hashish)
Date: Thu, 27 Aug 2015 08:54:18 +0300
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <20150813012026.GA16939@Mail.DDoS-Mitigator.net>
References: <CAOLsBOuQP1m8u=1H_nre9jaExONfJ16rs0h=O4m7_+Gt5q9d7g@mail.gmail.com>
 <20150813012026.GA16939@Mail.DDoS-Mitigator.net>
Message-ID: <CAOLsBOuCPzEovehWgLqqhaNH5mFo0TG+fn_s4ia-bJATm=2RWg@mail.gmail.com>

On Thu, Aug 13, 2015 at 4:20 AM, alvin nanog <
nanogml at mail.ddos-mitigator.net> wrote:

>
> hi ramy
>
> On 08/12/15 at 05:28pm, Ramy Hashish wrote:
> >
> > Anybody here compared Wanguard's performance with the DDoS vendors in the
> > market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ......)?
>
> wouldn't the above "comparison" be kinda funky comparing software solutions
> with hardware appliances and/or cloud scubbers ??
>
> comparisons between vendors should be between sw solutions,
> or hw appliances vs other hw, or cloud vs other clouds
>
> wanguard should be compared with other sw options or vendors using
> sflow, netflow, jflow, etc etc
>         http://www.andrisoft.com/software/wanguard
>         http://bitbucket.org/tortoiselabs/ddosmon
>         http://www.github.com/FastVPSEestiOu/fastnetmon
>         http://nfdump.sourceforge.net
>         http://nfsen.sourceforge.net
>
> wanguard - software solution using sflow
>         http://www.andrisoft.com/software/wanguard
>
> arbor ---- hardware/software solutions -- "peakflow"
>         http://www.arbornetworks.com/products/peakflow
>
> radware -- hardware/software/cloud solutions -- "defenseflow"
>         http://www.radware.com/products/attack-mitigation-service/
>         http://www.radware.com/Products/DefenseFlow/
>
> nsfocus -- hardware/cloud solutions
>         http://www.nsfocus.com/products/
>
> A10 ------ hardware solution
>         http://www.a10network.com/products
>
> riorey --- hardware solution
>         http://www.riorey.com/riorey-ddos-products
>
> staminus - hardware/cloud solutions
>         http://www.staminus.net/shield
>
> # and to add to the ddos confusion ..
>
> akamai/prolexic --- hardware/cloud solution
>
> f5 ---------------- hardware/cloud solutions
>
> http://www.f5.com/resources/white-papers/mitigating-ddos-attacks-with-f5-technology
>
> fortinet ---------- custom ASIC hardware and cloud solution
>
> http://www.fortinet.com/products/fortiddos/ddos-mitigation-appliances.html
>
>
Let me disagree to some extent, we have contacted most of the above
vendors, selling a HW doesn't necessarily mean they are HW based solution,
most of them run their SW/algorithm on an x86 machine.

Thanks,

Ramy

From tore at fud.no  Thu Aug 27 06:34:28 2015
From: tore at fud.no (Tore Anderson)
Date: Thu, 27 Aug 2015 08:34:28 +0200
Subject: Production-scale NAT64
In-Reply-To: <55DEA0FE.1010204@seacom.mu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu>
 <20150827012114.GA15533@puck.nether.net> <55DE941F.90806@seacom.mu>
 <20150827065346.58554fa7@echo.ms.redpill-linpro.com>
 <20150827051657.4F33B36446DF@rock.dv.isc.org>
 <55DEA0FE.1010204@seacom.mu>
Message-ID: <20150827083428.6f00303c@echo.ms.redpill-linpro.com>

* Mark Tinka <mark.tinka at seacom.mu>

> On 27/Aug/15 07:16, Mark Andrews wrote:
> 
> >
> > Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
> > all of which are better solutions than NAT64.  NAT64 + DNS64 which
> > breaks DNSSEC.
> 
> Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the
> dust settles.

Hi Mark,

There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in
this respect, the way I see it. In all cases you need four things:

0) Native IPv6.
1) A central component connected to the IPv4 internet and the IPv6.
   access network (464XLAT: "PLAT", MAP-*: "BR", DS-Lite/lw4o6: "AFTR")
2) Signalling to client that #1 exists and can be used (464XLAT: DNS64,
   others: DHCPv6 options).
3) A distributed component at the customer premise/nodes that acts on
   #2 and connects an isolated IPv4 network to the IPv6 access network
   (464XLAT: "CLAT", MAP-*: "CE", DS-Lite/lw4o6: "B4").

The necessary "undo work" in all cases is to disable #2. At that point
components #1 and #3 will become un-used and can be removed if you
care. My guess is that you'll care about removing #1 because it
probably uses power and space in your PoP, but that you won't care
about #3 because that's just an unused software function residing in a
customer device you might not even have management access to.

I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3
to remove as part of your "undo work", but as I mentioned above I doubt
you'll care about that particular distinction. Besides, since a CLAT is
included by default in multiple client platforms, you can't really
prevent your users from using 464XLAT if you're providing NAT64/DNS64
to begin with, unless you're doing something really weird like
disabling DNS64 for the "ipv4only.arpa." hostname specifically.

Tore

From nanogml at Mail.DDoS-Mitigator.net  Thu Aug 27 09:48:31 2015
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Thu, 27 Aug 2015 02:48:31 -0700
Subject: DDoS appliances reviews needed
In-Reply-To: <CAOLsBOsD3_U0xVTf+SoYc9A6D-FGOKW3nuQfQc8xp6bDHVYm9w@mail.gmail.com>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
 <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>
 <20150826175315.GA10152@Mail.DDoS-Mitigator.net>
 <CAOLsBOsD3_U0xVTf+SoYc9A6D-FGOKW3nuQfQc8xp6bDHVYm9w@mail.gmail.com>
Message-ID: <20150827094831.GA21515@Mail.DDoS-Mitigator.net>


hi ya ramy

- ddos mitigation is NOT one appliance or cloud scrubber ...
  you'd require multiple layers of different ddos mitigation methodologies

On 08/27/15 at 08:22am, Ramy Hashish wrote:
> Thank you Alvin, I have just remembered that I wanted to reply to your previous
> input on Wanguard versus the other vendors in the market, I will reply this
> there.
 
per your comments on the other posts, its okay to disagree etc, etc ...
everybody has their views .. maybe i wasnt clear enough with what i was saying too

> I can't get exactly what you are doing, do you have your own mitigation SW? If
> so I would like to know more about it.

you can download the free version for testing ..
	http://DDoS-Mitigator.net/Download

> On Wed, Aug 26, 2015 at 8:53 PM, alvin nanog <nanogml at mail.ddos-mitigator.net>
> wrote:
...
>     for your "reviewing" or collecing info from folks ..
>     - what's your metrics that is important to you ?
> 
> Our important metrics includes but not limited to the following:
> 
> - Ability to mitigate all kinds of volumetric DDoS attacks.

"mitigating all kinds of volumetric DDoS attacks" means you'd probably fail
most of the time ...

the (simulated) ddos attackers can always, 100% of the time, generate more 
traffic that you want to defend against in hw or $$$ or time or staff ...

i say, first defend against all the current DDoS attacks you are getting
every minute of every day .... that'd already take lots and lots of time 
and $$$ and resources as is ... and volumizing it, to 1,000,000 packets/sec 
or more 10M or 100M packets/sec doesn't solve anything ...

imho, the only way to defend against any volumetric ddos attacks that 
exceed your bandwidth capacity is to buy more capacity from the ISP
or from (more expensive) DDoS cloud scrubbers

> - Ability to mitigate application level attacks for at least HTTP, HTTPs, SMTP
> and DNS.

it should be trivial to defend against incoming http/https/smtp ddos attacks
	- the so called "10 minute problem"

defending against DNS is almost equally trivial ....
	- 53/udp is used for dns queries ...
	- 53/tcp is used for zone transfers between primary and secondary DNS servers

	thus, all incoming  tcp packets to a DNS server are DDoS attacks
	except your own primary and secondary dns server ip#

if UDP attacks against DNS servers exceed your bandwidth, again, you have to 
buy more bandwidth or have the ISP or the ddos scrubber cloud drop it for you

	- limiting replies to incoming udp or icmp is useless since it already
	used your bandwidth, cpu, memory, disk and the expensive staff's time
 
	- we're all assuming your DNS server is closed for recursive queries
	to prevent DNS amplification attacks ... 

	- similary fix/patch NTP servers and ntp clients

	- if the ISP doesn't want to help defend against incoming UDP/ICMP
	attacks, than you're kinda screwed ... time to find a new ISP

similarly, always turn off replies to ping broadcast from the outside to 
prevent smurf'ing yourself

> - Time-to-detect and time-to-mitigate.

ddos mitigation should be automated ... people cannot watch and defend the
servers watching millions of packets per second flowing thru the servers

more importantlty, if people are looking at the packets and if you're
sending/receiving confidential data, do you really want 3rd party eyeballs
looking at all your packets, and regulations say they should be certified
eyeballs and certified colo facilities too

> - False positives.

hard to avoid which requires careful planning and lots of testing

> - Response time to the management plan.

why would "management" dictate ddos mitigation policy vs IT security folks 

> - Ability to sniff packets for further analysis with the support.

too much work ... you have million or gazillion ddos packets per second 
to look at and you will NOT be able to see the attack from the legitimate 
packets or more importantly, might not care anymore ...

> - Granularity of detection thresholds.

seem arbitrary to hit some threshold ...

either it IS a ddos attack or it's NOT ... it should be fairly clear

> - Percentage of DDoS attack leakage.

i dont understand the "leakage"

> - Multitenancy (We are an ISP)
?
good ....  the customers can help you determine legit traffic from
DDoS traffic

> - Fast to detect/mitigate appliance, no problem to work inline.
?
as is always the case, anytime you have a server inline, be sure
they are crossed connected so that the other server can take over
in case of hw failure

>     my requirement: all tcp-based ddos attacks must be tarpit'd ... 
...
> Could you please give more details on this?

tarpit holds any incoming tcp-based connection attempt open for say 2minutes
during which time the attacking server is stuck 

if the zombie ddos attacker sends 100,000 tcp packets/sec against
your webserver or mail server, they'd have to have a lots of kernel memory

	( 100,000 packet/sec * 1500byte/packet ) * 120 sec tcp timeout

	try sending 100,000 tcp packets/sec for 2 minutes against a 
	test web server with tarpits properly installed w/ the proper
	iptables rules ... 
	( eg... any incoming tcp packet not on port 80 gets tarpit'd )

	100,000 packets/sec is still an itty-bitty ddos attack

> Could you please give more details about how to tarpit?

http://NetworkNightmare.net/Tarpits

magic pixie dust
alvin
#
# DDoS-Mitigator.net
# DDoS-Simulator.net
#

From mark.tinka at seacom.mu  Thu Aug 27 10:03:46 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 27 Aug 2015 12:03:46 +0200
Subject: Production-scale NAT64
In-Reply-To: <20150827083428.6f00303c@echo.ms.redpill-linpro.com>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu> <20150827012114.GA15533@puck.nether.net>
 <55DE941F.90806@seacom.mu>
 <20150827065346.58554fa7@echo.ms.redpill-linpro.com>
 <20150827051657.4F33B36446DF@rock.dv.isc.org> <55DEA0FE.1010204@seacom.mu>
 <20150827083428.6f00303c@echo.ms.redpill-linpro.com>
Message-ID: <55DEE082.5070109@seacom.mu>



On 27/Aug/15 08:34, Tore Anderson wrote:
> Hi Mark,
>
> There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in
> this respect, the way I see it. In all cases you need four things:
>
> 0) Native IPv6.
> 1) A central component connected to the IPv4 internet and the IPv6.
>    access network (464XLAT: "PLAT", MAP-*: "BR", DS-Lite/lw4o6: "AFTR")
> 2) Signalling to client that #1 exists and can be used (464XLAT: DNS64,
>    others: DHCPv6 options).
> 3) A distributed component at the customer premise/nodes that acts on
>    #2 and connects an isolated IPv4 network to the IPv6 access network
>    (464XLAT: "CLAT", MAP-*: "CE", DS-Lite/lw4o6: "B4").
>
> The necessary "undo work" in all cases is to disable #2. At that point
> components #1 and #3 will become un-used and can be removed if you
> care. My guess is that you'll care about removing #1 because it
> probably uses power and space in your PoP, but that you won't care
> about #3 because that's just an unused software function residing in a
> customer device you might not even have management access to.
>
> I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3
> to remove as part of your "undo work", but as I mentioned above I doubt
> you'll care about that particular distinction. Besides, since a CLAT is
> included by default in multiple client platforms, you can't really
> prevent your users from using 464XLAT if you're providing NAT64/DNS64
> to begin with, unless you're doing something really weird like
> disabling DNS64 for the "ipv4only.arpa." hostname specifically.

Agree that with 464XLAT, the situation is not that different.

The issue with 464XLAT for a service provider such as ourselves is that
the majority of our customer's CPE and terminal equipment does not have
464XLAT support. You are mostly seeing 464XLAT support in mobile phones,
and on specific mobile OS's (iOS does not support 464XLAT today, for
example - unless this has changed or is changing).

In that situation, our particular use-case could use more DNS64 for the
signaling than 464XLAT or equivalent.

You can't have it all - each network will have to choose the least of
the various evils that can apply to it.

Mark.

From bzeeb-lists at lists.zabbadoz.net  Thu Aug 27 12:59:55 2015
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Thu, 27 Aug 2015 12:59:55 +0000
Subject: Production-scale NAT64
In-Reply-To: <CAD6AjGTv0DCtmmdydmTDnFoZ7p2rU0HG4ai0JDew7ADkJAdhxw@mail.gmail.com>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <63682.1440602171@turing-police.cc.vt.edu>
 <CAD6AjGTv0DCtmmdydmTDnFoZ7p2rU0HG4ai0JDew7ADkJAdhxw@mail.gmail.com>
Message-ID: <9E360D02-5C33-4CFE-9DBC-FA363F1F970A@lists.zabbadoz.net>


> On 26 Aug 2015, at 15:23 , Ca By <cb.list6 at gmail.com> wrote:
> 
> On Wed, Aug 26, 2015 at 8:16 AM, <Valdis.Kletnieks at vt.edu> wrote:
> 
>> On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
>> 
>>> Another relevant metric, less than 25% of my mobile subscribers traffic
>>> require NAT64 translating.  75+% of bits flows through end-to-end IPv6
>>> (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on
>> ...).
>> 
>> So I'm guessing that 75% of the traffic flows with better latency than
>> the 25% IPvhorse-n-buggy traffic? ;)
>> 
>> 
> Facebook says IPv6 is 20-40% faster
> 
> http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/
> 
> Another way to look at it, IPv4 is 20-40% slower than IPv6.


The question I have not seen the answer yet to is ?why??

Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps?

Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance?

Is it about middle nodes?

Has anyone done the research on this?

From mark.tinka at seacom.mu  Thu Aug 27 13:17:47 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 27 Aug 2015 15:17:47 +0200
Subject: Production-scale NAT64
In-Reply-To: <9E360D02-5C33-4CFE-9DBC-FA363F1F970A@lists.zabbadoz.net>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <63682.1440602171@turing-police.cc.vt.edu>
 <CAD6AjGTv0DCtmmdydmTDnFoZ7p2rU0HG4ai0JDew7ADkJAdhxw@mail.gmail.com>
 <9E360D02-5C33-4CFE-9DBC-FA363F1F970A@lists.zabbadoz.net>
Message-ID: <55DF0DFB.2060004@seacom.mu>



On 27/Aug/15 14:59, Bjoern A. Zeeb wrote:
>
>
> The question I have not seen the answer yet to is ?why??
>
> Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps?
>
> Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance?
>
> Is it about middle nodes?
>
> Has anyone done the research on this?.

The life of an IPv4 packet on the Internet is very likely to undergo
some NAT at some point in its travels.

I haven't yet heard of many doing NAT66, hence IPv6 not undergoing NAT
means any slow-downs caused by NAT44 are missed (gladly) on IPv6.

This might not necessarily be immediately visible on regular networks,
but the large content players could count this quite easily due to the
significant volumes of traffic their networks are having to aggregate
and process.

Mark.

From nanog1 at roadrunner.com  Thu Aug 27 13:51:13 2015
From: nanog1 at roadrunner.com (nanog1 at roadrunner.com)
Date: Thu, 27 Aug 2015 9:51:13 -0400
Subject: Organization - Network and Firewall
Message-ID: <20150827135113.N49I2.349540.root@cdptpa-web24>

In your orgs (Enterprise, Service Provider, whatever), how are your Network and Firewall teams organized?

I'm a fan of having operational staff from both teams under the same leadership with an architectural presence from your security org directly involved enough to have influence.

What have you seen work most effectively?  Poorly?

Thanks!

From cb.list6 at gmail.com  Thu Aug 27 14:35:42 2015
From: cb.list6 at gmail.com (Ca By)
Date: Thu, 27 Aug 2015 07:35:42 -0700
Subject: Production-scale NAT64
In-Reply-To: <9E360D02-5C33-4CFE-9DBC-FA363F1F970A@lists.zabbadoz.net>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <63682.1440602171@turing-police.cc.vt.edu>
 <CAD6AjGTv0DCtmmdydmTDnFoZ7p2rU0HG4ai0JDew7ADkJAdhxw@mail.gmail.com>
 <9E360D02-5C33-4CFE-9DBC-FA363F1F970A@lists.zabbadoz.net>
Message-ID: <CAD6AjGQs8GNdM8nX_KG4e1qfWAuqh-uajoyALSOszcn=gHq8=Q@mail.gmail.com>

On Thu, Aug 27, 2015 at 5:59 AM, Bjoern A. Zeeb <
bzeeb-lists at lists.zabbadoz.net> wrote:

>
> > On 26 Aug 2015, at 15:23 , Ca By <cb.list6 at gmail.com> wrote:
> >
> > On Wed, Aug 26, 2015 at 8:16 AM, <Valdis.Kletnieks at vt.edu> wrote:
> >
> >> On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
> >>
> >>> Another relevant metric, less than 25% of my mobile subscribers traffic
> >>> require NAT64 translating.  75+% of bits flows through end-to-end IPv6
> >>> (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on
> >> ...).
> >>
> >> So I'm guessing that 75% of the traffic flows with better latency than
> >> the 25% IPvhorse-n-buggy traffic? ;)
> >>
> >>
> > Facebook says IPv6 is 20-40% faster
> >
> >
> http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/
> >
> > Another way to look at it, IPv4 is 20-40% slower than IPv6.
>
>
> The question I have not seen the answer yet to is ?why??
>
> Is this really because of the network, e.g., separate pipes in some places
> still, with forwarding devices handling a lot less pps?
>
> Is it because of people having done a newer cleaner-cut network stack
> implementation and lately cared about its performance?
>
> Is it about middle nodes?
>
> Has anyone done the research on this?


I too do not know, and i do not care.

Looking in the rear view mirror at why NAT encumbered IPv4 sucks is not a
priority of mine, but may be an interesting pedantic project for internet
historians.  We know that NAT causes very minor latency (session setup and
matching per packet) and very minor loss (state management chaos), but i
can hardly believe that is a 20-40% speedup. Then again, TCP is a sensitive
thing.

Either way, Twitter and Amazon seem a tad slow... perhaps they should
enable IPv6.  Or maybe they have plenty of IPv4 and don't care much about
the 20-40% performance gain that Facebook has seen.

CB

From hugo at slabnet.com  Thu Aug 27 15:24:15 2015
From: hugo at slabnet.com (Hugo Slabbert)
Date: Thu, 27 Aug 2015 08:24:15 -0700
Subject: DDoS appliances reviews needed
In-Reply-To: <20150827094831.GA21515@Mail.DDoS-Mitigator.net>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
 <CAK5YLgd0BNDWMJ+HXMBVhCkwDjFCgGMPdo9kTxmNLgoOEsX3Gw@mail.gmail.com>
 <20150826175315.GA10152@Mail.DDoS-Mitigator.net>
 <CAOLsBOsD3_U0xVTf+SoYc9A6D-FGOKW3nuQfQc8xp6bDHVYm9w@mail.gmail.com>
 <20150827094831.GA21515@Mail.DDoS-Mitigator.net>
Message-ID: <20150827152415.GG7132@bamboo.slabnet.com>

On Thu 2015-Aug-27 02:48:31 -0700, alvin nanog 
<nanogml at Mail.DDoS-Mitigator.net> wrote:

--snip--

>defending against DNS is almost equally trivial ....
>	- 53/udp is used for dns queries ...

...except when it's not.  TCP is an accepted transport for DNS queries and 
necessary for response sizes > 512 bytes where EDNS is not in use / 
available.

>	- 53/tcp is used for zone transfers between primary and secondary DNS 
>	servers
>
>	thus, all incoming  tcp packets to a DNS server are DDoS attacks
>	except your own primary and secondary dns server ip#

As per above, that's not entirely accurate, though you're welcome to cause 
some FPs by dropping legitimate DNS queries over TCP.  Granted on our own 
recursive resolvers the percentage of TCP queries is vanishingly small to 
non-existent, but "all" is not correct.

>	- we're all assuming your DNS server is closed for recursive queries
>	to prevent DNS amplification attacks ...

...for different degrees of "closed".  I'm assuming $dayjob for at least 
*some* of the folks on this list entails a service provider network of some 
sort, where it'd be pretty likely there are some recursive resolvers 
available to their customers.  DNS amplification queries sourced from (or 
spoofed as) within customer ranges and able to reach the resolvers are 
still a vector.

--
Hugo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150827/c648dceb/attachment.pgp>

From jchisolm at computer.org  Thu Aug 27 15:53:08 2015
From: jchisolm at computer.org (Joe Chisolm)
Date: Thu, 27 Aug 2015 10:53:08 -0500
Subject: DDoS appliances reviews needed
In-Reply-To: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
Message-ID: <55DF3264.5070303@computer.org>

Gartner did a report about a year ago.  Not free.
https://www.gartner.com/doc/2910217/ddos-comparison-defense-approaches

On 08/26/2015 07:40 AM, Ramy Hashish wrote:
> Good day all,
>
> Anybody here has experienced a PoC for any anti DDoS appliance, or already
> using a anti DDoS appliance in production and able to share his user
> experience/review?
>
> We need to collect good reviews from people whom got their hands dirty with
> the configuration/attack mitigation, real experience.
>
> Thanks,
>
> Ramy
>

-- 
Joe Chisolm
Computer Translations, Inc.
Network and Datacenter Consulting
Marble Falls, Tx.
830-265-8018

Public Key Available at www.sks-keyservers.net



From bross at pobox.com  Thu Aug 27 15:57:25 2015
From: bross at pobox.com (Brandon Ross)
Date: Thu, 27 Aug 2015 11:57:25 -0400 (EDT)
Subject: Production-scale NAT64
In-Reply-To: <55DE941F.90806@seacom.mu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu>
 <20150827012114.GA15533@puck.nether.net> <55DE941F.90806@seacom.mu>
Message-ID: <alpine.OSX.2.02.1508271154360.1024@brugal>

On Thu, 27 Aug 2015, Mark Tinka wrote:

> If your IPv4 is public, you should not "feel slow". Of course, if your
> IPv4 is private, then yes, some NAT44 may happen somewhere along the path.

I strongly advise you to not assume that just because an IPv4 address is 
"public" (which I'm reading as RFC1918) means that it's not NATed.

I learned the hard way that Tmobile, for one, squats on other 
organization's public IP space on their mobile network and NATs it to 
address space they are actually assigned.  What you really mean is if your 
IPv4 is not NATed, then it should not "feel slow", the type of address 
isn't necessarily an indicator.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross

From Steve.Mikulasik at civeo.com  Thu Aug 27 16:00:10 2015
From: Steve.Mikulasik at civeo.com (Steve Mikulasik)
Date: Thu, 27 Aug 2015 16:00:10 +0000
Subject: DDoS appliances reviews needed
In-Reply-To: <55DF3264.5070303@computer.org>
References: <CAOLsBOsabFa_cxY64OGmuO+0vS5jbW+8xTm_+ZtPH7MOH7FAwA@mail.gmail.com>
 <55DF3264.5070303@computer.org>
Message-ID: <BY1PR0701MB1781D116ED99F67358E79877FA6F0@BY1PR0701MB1781.namprd07.prod.outlook.com>

I assume they don't list their testing methodology right? It always feels like they just read vendor spec sheets. 

Steve Mikulasik

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Chisolm
Sent: Thursday, August 27, 2015 9:53 AM
To: nanog at nanog.org
Subject: Re: DDoS appliances reviews needed

Gartner did a report about a year ago.  Not free.
https://www.gartner.com/doc/2910217/ddos-comparison-defense-approaches

On 08/26/2015 07:40 AM, Ramy Hashish wrote:
> Good day all,
>
> Anybody here has experienced a PoC for any anti DDoS appliance, or 
> already using a anti DDoS appliance in production and able to share 
> his user experience/review?
>
> We need to collect good reviews from people whom got their hands dirty 
> with the configuration/attack mitigation, real experience.
>
> Thanks,
>
> Ramy
>

--
Joe Chisolm
Computer Translations, Inc.
Network and Datacenter Consulting
Marble Falls, Tx.
830-265-8018

Public Key Available at http://www.sks-keyservers.net



From mark.tinka at seacom.mu  Thu Aug 27 16:23:36 2015
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 27 Aug 2015 18:23:36 +0200
Subject: Production-scale NAT64
In-Reply-To: <alpine.OSX.2.02.1508271154360.1024@brugal>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu> <20150827012114.GA15533@puck.nether.net>
 <55DE941F.90806@seacom.mu> <alpine.OSX.2.02.1508271154360.1024@brugal>
Message-ID: <55DF3988.9010806@seacom.mu>



On 27/Aug/15 17:57, Brandon Ross wrote:

>  
>
> I strongly advise you to not assume that just because an IPv4 address
> is "public" (which I'm reading as RFC1918) means that it's not NATed.
>
> I learned the hard way that Tmobile, for one, squats on other
> organization's public IP space on their mobile network and NATs it to
> address space they are actually assigned.  What you really mean is if
> your IPv4 is not NATed, then it should not "feel slow", the type of
> address isn't necessarily an indicator.

If we're being pedantic, yes.

Mark.


From mel at beckman.org  Thu Aug 27 18:00:11 2015
From: mel at beckman.org (Mel Beckman)
Date: Thu, 27 Aug 2015 18:00:11 +0000
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CO1PR07MB9563ED313DB87C9F808F785A76F0@CO1PR07MB956.namprd07.prod.outlook.com>
References: <55DE30F3.3030900@hack.net>
 <CAJB2g-HLx1F8q94-kt2ckANGZ0PM0nmV42M8enw6s8Ht3cK0hA@mail.gmail.com>
 <55DE3356.6060009@hack.net> <161B660B-BDEB-4ACA-A9C4-F7191ED54423@dataix.net>
 <CO1PR07MB9563ED313DB87C9F808F785A76F0@CO1PR07MB956.namprd07.prod.outlook.com>
Message-ID: <1657021A-226B-4CEF-BCB3-F5115977B945@beckman.org>

Finally got a call back from the Level3 NOC. There is a global ticket for this, #ST1878748. This is a wide-ranging outage effecting the entire Level3 network. I am supposed to get emailed updates now automatically, and will reflect those here.

 -mel


> On Aug 26, 2015, at 6:01 PM, Mel Beckman <mel at beckman.org> wrote:
> 
> We continue to see 10 to 20 percent packet loss crossing TW border and even between clients in the same region (e.g. LA and Santa Barbara). No news from the NOC yet.
> 
> -mel
> 
> ________________________________________
> From: NANOG <nanog-bounces at nanog.org> on behalf of Jason Hellenthal <jhellenthal at dataix.net>
> Sent: Wednesday, August 26, 2015 5:33 PM
> To: nanog at nanog.org
> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
> 
> Cleared up here in WI TW/Level3 COLO between 19:00 - 19:20 CST - 3235 Intertech Dr. Brookfield
> 
>> On Aug 26, 2015, at 16:44, Ryan K. Brooks <ryan at hack.net> wrote:
>> 
>> Seems to be impacting their entire network now.
>> 
>> On 8/26/15 4:41 PM, Rafael Possamai wrote:
>>> I have been seeing the same issues, but haven't heard anything back yet. It has improved in the last 30 minutes or so, see below.
>>> 
>>> 
>>> http://imgur.com/KVAzetA
>>> *
>>> *
>>> 
>>> 
>>> On Wed, Aug 26, 2015 at 4:34 PM, Ryan K. Brooks <ryan at hack.net <mailto:ryan at hack.net>> wrote:
>>> 
>>>   Seeing packet loss on AS4323 since 2:30 Central time.   NOC is
>>>   unresponsive to phone and email.  Anyone have an idea what's going
>>>   on over there?
>>> 
>>> 
>> 
> 
> 
> --
> Jason Hellenthal
> JJH48-ARIN
> 
> 
> 
> 


From brooks at firestormnetworks.net  Thu Aug 27 19:13:37 2015
From: brooks at firestormnetworks.net (Brooks Bridges)
Date: Thu, 27 Aug 2015 12:13:37 -0700
Subject: load balancer product for dns content switching
Message-ID: <55DF6161.4030101@firestormnetworks.net>

Spent quite a bit of time researching products out there looking for one 
that will do content switching based on the domain being queried, and 
I'm coming up empty.  Can anyone point me in a decent direction?

For example:

all requests are sent to one (HA) VIP, and then:

host.bob.domain.com gets routed to dns server group 1
host.bill.domain.com gets routed to dns server group 2
and so on...

Thanks for any advice

-- 
Brooks Bridges
Firestorm Networks
Email: brooks at firestormnetworks.net
Voice: +1.8006975891
Fax: +1.8889721835


From andrew.fried at gmail.com  Thu Aug 27 19:20:45 2015
From: andrew.fried at gmail.com (Andrew Fried)
Date: Thu, 27 Aug 2015 15:20:45 -0400
Subject: load balancer product for dns content switching
In-Reply-To: <55DF6161.4030101@firestormnetworks.net>
References: <55DF6161.4030101@firestormnetworks.net>
Message-ID: <55DF630D.30307@gmail.com>

While still in pre-production state, you might want to look at:

http://dnsdist.org/

Andrew

Andrew Fried
andrew.fried at gmail.com

On 8/27/15 3:13 PM, Brooks Bridges wrote:
> Spent quite a bit of time researching products out there looking for one
> that will do content switching based on the domain being queried, and
> I'm coming up empty.  Can anyone point me in a decent direction?
> 
> For example:
> 
> all requests are sent to one (HA) VIP, and then:
> 
> host.bob.domain.com gets routed to dns server group 1
> host.bill.domain.com gets routed to dns server group 2
> and so on...
> 
> Thanks for any advice
> 

From frnkblk at iname.com  Thu Aug 27 19:31:57 2015
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 27 Aug 2015 14:31:57 -0500
Subject: BT contact?
Message-ID: <000001d0e0ff$098c0d00$1ca42700$@iname.com>

http://www.bt.com over IPv6 has been down since ~8:52 am U.S. Central.
Please send me a PM if you have a contact there, or forward this over.

Thanks,

Frank

Bonus: www.brocade.com over IPv6 has been down since last night, too, as the
AAAA was removed, but I have a contact there.


root at nagios:/# wget -6 www.bt.com
--2015-08-27 14:30:23--  http://www.bt.com/
Resolving www.bt.com... 2a00:2381:ffff::1
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2015-08-27 14:30:24--  (try: 2)  http://www.bt.com/
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2015-08-27 14:30:27--  (try: 3)  http://www.bt.com/
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2015-08-27 14:30:30--  (try: 4)  http://www.bt.com/
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

^C
root at nagios:/#


From rwebb at ropeguru.com  Thu Aug 27 20:11:45 2015
From: rwebb at ropeguru.com (Robert Webb)
Date: Thu, 27 Aug 2015 16:11:45 -0400
Subject: load balancer product for dns content switching
In-Reply-To: <55DF6161.4030101@firestormnetworks.net>
References: <55DF6161.4030101@firestormnetworks.net>
Message-ID: <ximss-520484@mail.ropeguru.com>

F5 Big-IP? Pricey but it should do what you are looking for.

Robert


On Thu, 27 Aug 2015 12:13:37 -0700
  Brooks Bridges <brooks at firestormnetworks.net> wrote:
> Spent quite a bit of time researching products out there looking for 
>one that will do content switching based on the domain being queried, 
>and I'm coming up empty.  Can anyone point me in a decent direction?
> 
>For example:
> 
> all requests are sent to one (HA) VIP, and then:
> 
> host.bob.domain.com gets routed to dns server group 1
> host.bill.domain.com gets routed to dns server group 2
> and so on...
> 
> Thanks for any advice
> 
> -- 
> Brooks Bridges
>Firestorm Networks
> Email: brooks at firestormnetworks.net
> Voice: +1.8006975891
>Fax: +1.8889721835
> 



From ryan.g at atwgpc.net  Thu Aug 27 20:14:59 2015
From: ryan.g at atwgpc.net (Ryan Gelobter)
Date: Thu, 27 Aug 2015 15:14:59 -0500
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CAFPFpmU15DMd3Zhe2NzDc5yVH1ZfOycUbwUMutiFd3ceXxWJoQ@mail.gmail.com>
References: <55DE30F3.3030900@hack.net>
 <CAJB2g-HLx1F8q94-kt2ckANGZ0PM0nmV42M8enw6s8Ht3cK0hA@mail.gmail.com>
 <55DE3356.6060009@hack.net>
 <161B660B-BDEB-4ACA-A9C4-F7191ED54423@dataix.net>
 <CO1PR07MB9563ED313DB87C9F808F785A76F0@CO1PR07MB956.namprd07.prod.outlook.com>
 <1657021A-226B-4CEF-BCB3-F5115977B945@beckman.org>
 <CAFPFpmU15DMd3Zhe2NzDc5yVH1ZfOycUbwUMutiFd3ceXxWJoQ@mail.gmail.com>
Message-ID: <CAFPFpmVqgKJsEbGz5Om=BwZBBVwXx2MX1u5e2b=NRu4Boj60jw@mail.gmail.com>

If you have access to the Level3 portal you should see ticket #9639047
under Network Events now.

Event Summary:IP Network Event ~ Multiple Markets

08/27/2015 8:05 PM GMT

Level 3 Tier III and Operations Engineering teams have identified Internet
Protocols dropping, affecting customer services.  Restoration efforts are
in progress, but an estimated time of restoral is not available at this
time.

08/27/2015 6:36 PM GMT

IP and Transport Tier III, Operations Engineering and Field Services
continue collaboratively working the issue.


08/27/2015 4:59 PM GMT

Operations Engineering is engaged and Field Services is on site in Chicago,
IL investigating the issue.


08/27/2015 4:38 PM GMT

The engineers are currently migrating traffic in efforts of restoring
services while troubleshooting continues. Field Services is being
dispatched to a Chicago, IL site to assist.

08/27/2015 4:21 PM GMT

IP services are affected across multiple markets and the root cause is
currently under investigation. The IP NOC and IP and Transport Tier III are
actively troubleshooting and working to isolate the cause. The engineers
have detected peering issues which are resulting in packet loss for
customers. Please be advised that updates will be provided at minimum of
hourly unless otherwise noted.

From oliver.oboyle at gmail.com  Thu Aug 27 20:29:39 2015
From: oliver.oboyle at gmail.com (Oliver O'Boyle)
Date: Thu, 27 Aug 2015 16:29:39 -0400
Subject: load balancer product for dns content switching
In-Reply-To: <ximss-520484@mail.ropeguru.com>
References: <55DF6161.4030101@firestormnetworks.net>
 <ximss-520484@mail.ropeguru.com>
Message-ID: <CAMOPTExWaQFsSoj3MNjFYwB7Jcv-NfhqhkP4XtyO0gyUGrCcaA@mail.gmail.com>

Citrix Netscaler as well.

On Thu, Aug 27, 2015 at 4:11 PM, Robert Webb <rwebb at ropeguru.com> wrote:

> F5 Big-IP? Pricey but it should do what you are looking for.
>
> Robert
>
>
> On Thu, 27 Aug 2015 12:13:37 -0700
>  Brooks Bridges <brooks at firestormnetworks.net> wrote:
>
>> Spent quite a bit of time researching products out there looking for one
>> that will do content switching based on the domain being queried, and I'm
>> coming up empty.  Can anyone point me in a decent direction?
>>
>> For example:
>>
>> all requests are sent to one (HA) VIP, and then:
>>
>> host.bob.domain.com gets routed to dns server group 1
>> host.bill.domain.com gets routed to dns server group 2
>> and so on...
>>
>> Thanks for any advice
>>
>> --
>> Brooks Bridges
>> Firestorm Networks
>> Email: brooks at firestormnetworks.net
>> Voice: +1.8006975891
>> Fax: +1.8889721835
>>
>>
>
>


-- 
:o@>

From wcooper02 at gmail.com  Thu Aug 27 20:29:59 2015
From: wcooper02 at gmail.com (William Cooper)
Date: Thu, 27 Aug 2015 13:29:59 -0700
Subject: load balancer product for dns content switching
Message-ID: <-2053341620922838270@unknownmsgid>

A10, brocade, etc lots of options out there-

Sent from my Windows PhoneFrom: Brooks Bridges
Sent: ?8/?27/?2015 3:15 PM
To: <nanog at nanog.org>
Subject: load balancer product for dns content switching
Spent quite a bit of time researching products out there looking for one
that will do content switching based on the domain being queried, and
I'm coming up empty.  Can anyone point me in a decent direction?

For example:

all requests are sent to one (HA) VIP, and then:

host.bob.domain.com gets routed to dns server group 1
host.bill.domain.com gets routed to dns server group 2
and so on...

Thanks for any advice

-- 
Brooks Bridges
Firestorm Networks
Email: brooks at firestormnetworks.net
Voice: +1.8006975891
Fax: +1.8889721835

From Nathan_Sipes at kindermorgan.com  Thu Aug 27 20:32:58 2015
From: Nathan_Sipes at kindermorgan.com (Sipes, Nathan)
Date: Thu, 27 Aug 2015 20:32:58 +0000
Subject: load balancer product for dns content switching
In-Reply-To: <ximss-520484@mail.ropeguru.com>
References: <55DF6161.4030101@firestormnetworks.net>
 <ximss-520484@mail.ropeguru.com>
Message-ID: <13AB87E4E441E94ABE3F62F72C111A38472B660A@COSEX2.kindermorgan.com>

A10Networks should be able to do what you are looking for. 



Nathan Sipes
Principal Network Architect
Tel: 713-369-9866
FAX: 303-763-3510?
Kinder Morgan
1001 Louisiana St
KMB 548
Houston, TX
77002
Nathan_Sipes at kindermorgan.com



-----Original Message-----
From: NANOG [mailto:nanog-bounces+nathan_sipes=kindermorgan.com at nanog.org] On Behalf Of Robert Webb
Sent: Thursday, August 27, 2015 3:12 PM
To: Brooks Bridges <brooks at firestormnetworks.net>; <nanog at nanog.org> <nanog at nanog.org>
Subject: Re: load balancer product for dns content switching

F5 Big-IP? Pricey but it should do what you are looking for.

Robert


On Thu, 27 Aug 2015 12:13:37 -0700
  Brooks Bridges <brooks at firestormnetworks.net> wrote:
> Spent quite a bit of time researching products out there looking for 
>one that will do content switching based on the domain being queried, 
>and I'm coming up empty.  Can anyone point me in a decent direction?
> 
>For example:
> 
> all requests are sent to one (HA) VIP, and then:
> 
> host.bob.domain.com gets routed to dns server group 1 
> host.bill.domain.com gets routed to dns server group 2 and so on...
> 
> Thanks for any advice
> 
> --
> Brooks Bridges
>Firestorm Networks
> Email: brooks at firestormnetworks.net
> Voice: +1.8006975891
>Fax: +1.8889721835
> 



From frnkblk at iname.com  Thu Aug 27 21:31:27 2015
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 27 Aug 2015 16:31:27 -0500
Subject: BT contact?
In-Reply-To: <000001d0e0ff$098c0d00$1ca42700$@iname.com>
References: <000001d0e0ff$098c0d00$1ca42700$@iname.com>
Message-ID: <000e01d0e10f$bb802180$32806480$@iname.com>

Thanks for all the responses and assistance.  I'm not sure if that help was
the reason or not, but the site came back up at 4:16 pm U.S. Central.

Frank

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk
Sent: Thursday, August 27, 2015 2:32 PM
To: nanog at nanog.org
Subject: BT contact?

http://www.bt.com over IPv6 has been down since ~8:52 am U.S. Central.
Please send me a PM if you have a contact there, or forward this over.

Thanks,

Frank

Bonus: www.brocade.com over IPv6 has been down since last night, too, as the
AAAA was removed, but I have a contact there.


root at nagios:/# wget -6 www.bt.com
--2015-08-27 14:30:23--  http://www.bt.com/
Resolving www.bt.com... 2a00:2381:ffff::1
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2015-08-27 14:30:24--  (try: 2)  http://www.bt.com/
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2015-08-27 14:30:27--  (try: 3)  http://www.bt.com/
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2015-08-27 14:30:30--  (try: 4)  http://www.bt.com/
Connecting to www.bt.com|2a00:2381:ffff::1|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

^C
root at nagios:/#




From rdobbins at arbor.net  Thu Aug 27 21:57:51 2015
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 28 Aug 2015 07:57:51 +1000
Subject: load balancer product for dns content switching
In-Reply-To: <-2053341620922838270@unknownmsgid>
References: <-2053341620922838270@unknownmsgid>
Message-ID: <A99D9F23-0349-4F7F-861D-150997B306C1@arbor.net>


On 28 Aug 2015, at 6:29, William Cooper wrote:

> A10, brocade, etc

dnsdist, as well.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>

From nanog at ics-il.net  Fri Aug 28 04:00:37 2015
From: nanog at ics-il.net (Mike Hammett)
Date: Thu, 27 Aug 2015 23:00:37 -0500 (CDT)
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CAFPFpmVqgKJsEbGz5Om=BwZBBVwXx2MX1u5e2b=NRu4Boj60jw@mail.gmail.com>
Message-ID: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>

08/28/2015 3:08 AM GMT 
Event Conclusion Summary 

Start: August 27, 2015 13:20 GMT 
Stop: August 28, 2015 00:00 GMT 

Root Cause: A protocol issue impacted IP services in multiple markets. 
Fix Action: Adjustments were made to clear the errors. 

Summary: 
The IP NOC began investigating the root cause with Tier III Technical Support. It was reported that the issue was causing packet loss for customers. Operations Engineering teams were engaged, and Field Services were dispatched to a site in Chicago, IL to assist with investigations. Troubleshooting identified a protocol issue, and Operations Engineering worked with Tier III Technical Support to perform adjustments on the links. It was confirmed that the errors cleared. The traffic load was also lowered on cards in Chicago to alleviate any further issues. Should any additional impact be experienced, please contact the Level 3 Technical Service Center. 

What the hell is a "protocol issue"? 

I'm not an idiot, you can tell me specifically what happened... 




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

----- Original Message -----

From: "Ryan Gelobter" <ryan.g at atwgpc.net> 
To: "Mel Beckman" <mel at beckman.org> 
Cc: "<nanog at nanog.org>" <nanog at nanog.org> 
Sent: Thursday, August 27, 2015 3:14:59 PM 
Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323) 

If you have access to the Level3 portal you should see ticket #9639047 
under Network Events now. 

Event Summary:IP Network Event ~ Multiple Markets 

08/27/2015 8:05 PM GMT 

Level 3 Tier III and Operations Engineering teams have identified Internet 
Protocols dropping, affecting customer services. Restoration efforts are 
in progress, but an estimated time of restoral is not available at this 
time. 

08/27/2015 6:36 PM GMT 

IP and Transport Tier III, Operations Engineering and Field Services 
continue collaboratively working the issue. 


08/27/2015 4:59 PM GMT 

Operations Engineering is engaged and Field Services is on site in Chicago, 
IL investigating the issue. 


08/27/2015 4:38 PM GMT 

The engineers are currently migrating traffic in efforts of restoring 
services while troubleshooting continues. Field Services is being 
dispatched to a Chicago, IL site to assist. 

08/27/2015 4:21 PM GMT 

IP services are affected across multiple markets and the root cause is 
currently under investigation. The IP NOC and IP and Transport Tier III are 
actively troubleshooting and working to isolate the cause. The engineers 
have detected peering issues which are resulting in packet loss for 
customers. Please be advised that updates will be provided at minimum of 
hourly unless otherwise noted. 


From ryan at finnesey.com  Fri Aug 28 04:31:28 2015
From: ryan at finnesey.com (Ryan Finnesey)
Date: Fri, 28 Aug 2015 04:31:28 +0000
Subject: Hosted Lync Platform 
Message-ID: <BY1PR0501MB14625F20F5FCBAF698DA66CAB46E0@BY1PR0501MB1462.namprd05.prod.outlook.com>

Is there anyone within the group that is running a Hosted Lync Platform that would be open to having a conversation?

Cheers
Ryan

From jason at unlimitednet.us  Fri Aug 28 15:26:39 2015
From: jason at unlimitednet.us (Jason Canady)
Date: Fri, 28 Aug 2015 11:26:39 -0400
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
Message-ID: <55E07DAF.2050604@unlimitednet.us>

Mike, I would take it to mean someone screwed something up and they 
don't want to admit to it.  :-)  That's just a guess.

-- 

Jason Canady
Unlimited Net, LLC
Responsive, Reliable, Secure

www.unlimitednet.us
jason at unlimitednet.us
twitter: @unlimitednet

On 8/28/15 12:00 AM, Mike Hammett wrote:
> 08/28/2015 3:08 AM GMT
> Event Conclusion Summary
>
> Start: August 27, 2015 13:20 GMT
> Stop: August 28, 2015 00:00 GMT
>
> Root Cause: A protocol issue impacted IP services in multiple markets.
> Fix Action: Adjustments were made to clear the errors.
>
> Summary:
> The IP NOC began investigating the root cause with Tier III Technical Support. It was reported that the issue was causing packet loss for customers. Operations Engineering teams were engaged, and Field Services were dispatched to a site in Chicago, IL to assist with investigations. Troubleshooting identified a protocol issue, and Operations Engineering worked with Tier III Technical Support to perform adjustments on the links. It was confirmed that the errors cleared. The traffic load was also lowered on cards in Chicago to alleviate any further issues. Should any additional impact be experienced, please contact the Level 3 Technical Service Center.
>
> What the hell is a "protocol issue"?
>
> I'm not an idiot, you can tell me specifically what happened...
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> ----- Original Message -----
>
> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
> To: "Mel Beckman" <mel at beckman.org>
> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
> Sent: Thursday, August 27, 2015 3:14:59 PM
> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
>
> If you have access to the Level3 portal you should see ticket #9639047
> under Network Events now.
>
> Event Summary:IP Network Event ~ Multiple Markets
>
> 08/27/2015 8:05 PM GMT
>
> Level 3 Tier III and Operations Engineering teams have identified Internet
> Protocols dropping, affecting customer services. Restoration efforts are
> in progress, but an estimated time of restoral is not available at this
> time.
>
> 08/27/2015 6:36 PM GMT
>
> IP and Transport Tier III, Operations Engineering and Field Services
> continue collaboratively working the issue.
>
>
> 08/27/2015 4:59 PM GMT
>
> Operations Engineering is engaged and Field Services is on site in Chicago,
> IL investigating the issue.
>
>
> 08/27/2015 4:38 PM GMT
>
> The engineers are currently migrating traffic in efforts of restoring
> services while troubleshooting continues. Field Services is being
> dispatched to a Chicago, IL site to assist.
>
> 08/27/2015 4:21 PM GMT
>
> IP services are affected across multiple markets and the root cause is
> currently under investigation. The IP NOC and IP and Transport Tier III are
> actively troubleshooting and working to isolate the cause. The engineers
> have detected peering issues which are resulting in packet loss for
> customers. Please be advised that updates will be provided at minimum of
> hourly unless otherwise noted.
>


From ikiris at gmail.com  Fri Aug 28 15:33:54 2015
From: ikiris at gmail.com (Blake Dunlap)
Date: Fri, 28 Aug 2015 08:33:54 -0700
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <55E07DAF.2050604@unlimitednet.us>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
 <55E07DAF.2050604@unlimitednet.us>
Message-ID: <CAJvB4tndQVeMOjCEOFHVqJ2D4a2ihHoDqGQr8duUU1kk=V_OZA@mail.gmail.com>

I'll just leave this here....

https://honestnetworker.wordpress.com/2013/11/04/the-true-meaning-behind-most-rfos/

On Fri, Aug 28, 2015 at 8:26 AM, Jason Canady <jason at unlimitednet.us> wrote:
> Mike, I would take it to mean someone screwed something up and they don't
> want to admit to it.  :-)  That's just a guess.
>
> --
>
> Jason Canady
> Unlimited Net, LLC
> Responsive, Reliable, Secure
>
> www.unlimitednet.us
> jason at unlimitednet.us
> twitter: @unlimitednet
>
>
> On 8/28/15 12:00 AM, Mike Hammett wrote:
>>
>> 08/28/2015 3:08 AM GMT
>> Event Conclusion Summary
>>
>> Start: August 27, 2015 13:20 GMT
>> Stop: August 28, 2015 00:00 GMT
>>
>> Root Cause: A protocol issue impacted IP services in multiple markets.
>> Fix Action: Adjustments were made to clear the errors.
>>
>> Summary:
>> The IP NOC began investigating the root cause with Tier III Technical
>> Support. It was reported that the issue was causing packet loss for
>> customers. Operations Engineering teams were engaged, and Field Services
>> were dispatched to a site in Chicago, IL to assist with investigations.
>> Troubleshooting identified a protocol issue, and Operations Engineering
>> worked with Tier III Technical Support to perform adjustments on the links.
>> It was confirmed that the errors cleared. The traffic load was also lowered
>> on cards in Chicago to alleviate any further issues. Should any additional
>> impact be experienced, please contact the Level 3 Technical Service Center.
>>
>> What the hell is a "protocol issue"?
>>
>> I'm not an idiot, you can tell me specifically what happened...
>>
>>
>>
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> ----- Original Message -----
>>
>> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
>> To: "Mel Beckman" <mel at beckman.org>
>> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
>> Sent: Thursday, August 27, 2015 3:14:59 PM
>> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
>>
>> If you have access to the Level3 portal you should see ticket #9639047
>> under Network Events now.
>>
>> Event Summary:IP Network Event ~ Multiple Markets
>>
>> 08/27/2015 8:05 PM GMT
>>
>> Level 3 Tier III and Operations Engineering teams have identified Internet
>> Protocols dropping, affecting customer services. Restoration efforts are
>> in progress, but an estimated time of restoral is not available at this
>> time.
>>
>> 08/27/2015 6:36 PM GMT
>>
>> IP and Transport Tier III, Operations Engineering and Field Services
>> continue collaboratively working the issue.
>>
>>
>> 08/27/2015 4:59 PM GMT
>>
>> Operations Engineering is engaged and Field Services is on site in
>> Chicago,
>> IL investigating the issue.
>>
>>
>> 08/27/2015 4:38 PM GMT
>>
>> The engineers are currently migrating traffic in efforts of restoring
>> services while troubleshooting continues. Field Services is being
>> dispatched to a Chicago, IL site to assist.
>>
>> 08/27/2015 4:21 PM GMT
>>
>> IP services are affected across multiple markets and the root cause is
>> currently under investigation. The IP NOC and IP and Transport Tier III
>> are
>> actively troubleshooting and working to isolate the cause. The engineers
>> have detected peering issues which are resulting in packet loss for
>> customers. Please be advised that updates will be provided at minimum of
>> hourly unless otherwise noted.
>>
>

From mel at beckman.org  Fri Aug 28 15:45:02 2015
From: mel at beckman.org (Mel Beckman)
Date: Fri, 28 Aug 2015 15:45:02 +0000
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CAJvB4tndQVeMOjCEOFHVqJ2D4a2ihHoDqGQr8duUU1kk=V_OZA@mail.gmail.com>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
 <55E07DAF.2050604@unlimitednet.us>,
 <CAJvB4tndQVeMOjCEOFHVqJ2D4a2ihHoDqGQr8duUU1kk=V_OZA@mail.gmail.com>
Message-ID: <CBA050BD-9EC0-44D7-BCE6-9CCDD1C20D95@beckman.org>

Blake,

There's no call to be blatantly offensive like that. 

-mel 

> On Aug 28, 2015, at 8:35 AM, Blake Dunlap <ikiris at gmail.com> wrote:
> 
> I'll just leave this here....
> 
> https://honestnetworker.wordpress.com/2013/11/04/the-true-meaning-behind-most-rfos/
> 
>> On Fri, Aug 28, 2015 at 8:26 AM, Jason Canady <jason at unlimitednet.us> wrote:
>> Mike, I would take it to mean someone screwed something up and they don't
>> want to admit to it.  :-)  That's just a guess.
>> 
>> --
>> 
>> Jason Canady
>> Unlimited Net, LLC
>> Responsive, Reliable, Secure
>> 
>> www.unlimitednet.us
>> jason at unlimitednet.us
>> twitter: @unlimitednet
>> 
>> 
>>> On 8/28/15 12:00 AM, Mike Hammett wrote:
>>> 
>>> 08/28/2015 3:08 AM GMT
>>> Event Conclusion Summary
>>> 
>>> Start: August 27, 2015 13:20 GMT
>>> Stop: August 28, 2015 00:00 GMT
>>> 
>>> Root Cause: A protocol issue impacted IP services in multiple markets.
>>> Fix Action: Adjustments were made to clear the errors.
>>> 
>>> Summary:
>>> The IP NOC began investigating the root cause with Tier III Technical
>>> Support. It was reported that the issue was causing packet loss for
>>> customers. Operations Engineering teams were engaged, and Field Services
>>> were dispatched to a site in Chicago, IL to assist with investigations.
>>> Troubleshooting identified a protocol issue, and Operations Engineering
>>> worked with Tier III Technical Support to perform adjustments on the links.
>>> It was confirmed that the errors cleared. The traffic load was also lowered
>>> on cards in Chicago to alleviate any further issues. Should any additional
>>> impact be experienced, please contact the Level 3 Technical Service Center.
>>> 
>>> What the hell is a "protocol issue"?
>>> 
>>> I'm not an idiot, you can tell me specifically what happened...
>>> 
>>> 
>>> 
>>> 
>>> -----
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>> 
>>> ----- Original Message -----
>>> 
>>> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
>>> To: "Mel Beckman" <mel at beckman.org>
>>> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
>>> Sent: Thursday, August 27, 2015 3:14:59 PM
>>> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
>>> 
>>> If you have access to the Level3 portal you should see ticket #9639047
>>> under Network Events now.
>>> 
>>> Event Summary:IP Network Event ~ Multiple Markets
>>> 
>>> 08/27/2015 8:05 PM GMT
>>> 
>>> Level 3 Tier III and Operations Engineering teams have identified Internet
>>> Protocols dropping, affecting customer services. Restoration efforts are
>>> in progress, but an estimated time of restoral is not available at this
>>> time.
>>> 
>>> 08/27/2015 6:36 PM GMT
>>> 
>>> IP and Transport Tier III, Operations Engineering and Field Services
>>> continue collaboratively working the issue.
>>> 
>>> 
>>> 08/27/2015 4:59 PM GMT
>>> 
>>> Operations Engineering is engaged and Field Services is on site in
>>> Chicago,
>>> IL investigating the issue.
>>> 
>>> 
>>> 08/27/2015 4:38 PM GMT
>>> 
>>> The engineers are currently migrating traffic in efforts of restoring
>>> services while troubleshooting continues. Field Services is being
>>> dispatched to a Chicago, IL site to assist.
>>> 
>>> 08/27/2015 4:21 PM GMT
>>> 
>>> IP services are affected across multiple markets and the root cause is
>>> currently under investigation. The IP NOC and IP and Transport Tier III
>>> are
>>> actively troubleshooting and working to isolate the cause. The engineers
>>> have detected peering issues which are resulting in packet loss for
>>> customers. Please be advised that updates will be provided at minimum of
>>> hourly unless otherwise noted.
>> 

From jsink at phone.com  Fri Aug 28 16:57:02 2015
From: jsink at phone.com (James Sink)
Date: Fri, 28 Aug 2015 09:57:02 -0700
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CBA050BD-9EC0-44D7-BCE6-9CCDD1C20D95@beckman.org>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
 <55E07DAF.2050604@unlimitednet.us>
 <CAJvB4tndQVeMOjCEOFHVqJ2D4a2ihHoDqGQr8duUU1kk=V_OZA@mail.gmail.com>
 <CBA050BD-9EC0-44D7-BCE6-9CCDD1C20D95@beckman.org>
Message-ID: <CAO7CQnTO_-K71RTz++LQjGxn4KrSe=FWSgsc+4utdLC+hNs57g@mail.gmail.com>

Seemed reasonably accurate to me.


[image: Phone.com] <http://www.phone.com/>James SinkSenior Network Engineer
jsink at phone.com(800) 997-9179 x506Try Phone.com free!
<http://www.phone.com/?_tracking_id=10132>CONFIDENTIALITY NOTICE: This
e-mail and any attachments are for the exclusive and confidential use of
the intended recipient. If you received this in error, please do not read,
distribute, or take action in reliance upon this message. Instead, please
notify us immediately by return e-mail and promptly delete this message and
its attachments from your computer system.

On Fri, Aug 28, 2015 at 8:45 AM, Mel Beckman <mel at beckman.org> wrote:

> Blake,
>
> There's no call to be blatantly offensive like that.
>
> -mel
>
> > On Aug 28, 2015, at 8:35 AM, Blake Dunlap <ikiris at gmail.com> wrote:
> >
> > I'll just leave this here....
> >
> >
> https://honestnetworker.wordpress.com/2013/11/04/the-true-meaning-behind-most-rfos/
> >
> >> On Fri, Aug 28, 2015 at 8:26 AM, Jason Canady <jason at unlimitednet.us>
> wrote:
> >> Mike, I would take it to mean someone screwed something up and they
> don't
> >> want to admit to it.  :-)  That's just a guess.
> >>
> >> --
> >>
> >> Jason Canady
> >> Unlimited Net, LLC
> >> Responsive, Reliable, Secure
> >>
> >> www.unlimitednet.us
> >> jason at unlimitednet.us
> >> twitter: @unlimitednet
> >>
> >>
> >>> On 8/28/15 12:00 AM, Mike Hammett wrote:
> >>>
> >>> 08/28/2015 3:08 AM GMT
> >>> Event Conclusion Summary
> >>>
> >>> Start: August 27, 2015 13:20 GMT
> >>> Stop: August 28, 2015 00:00 GMT
> >>>
> >>> Root Cause: A protocol issue impacted IP services in multiple markets.
> >>> Fix Action: Adjustments were made to clear the errors.
> >>>
> >>> Summary:
> >>> The IP NOC began investigating the root cause with Tier III Technical
> >>> Support. It was reported that the issue was causing packet loss for
> >>> customers. Operations Engineering teams were engaged, and Field
> Services
> >>> were dispatched to a site in Chicago, IL to assist with investigations.
> >>> Troubleshooting identified a protocol issue, and Operations Engineering
> >>> worked with Tier III Technical Support to perform adjustments on the
> links.
> >>> It was confirmed that the errors cleared. The traffic load was also
> lowered
> >>> on cards in Chicago to alleviate any further issues. Should any
> additional
> >>> impact be experienced, please contact the Level 3 Technical Service
> Center.
> >>>
> >>> What the hell is a "protocol issue"?
> >>>
> >>> I'm not an idiot, you can tell me specifically what happened...
> >>>
> >>>
> >>>
> >>>
> >>> -----
> >>> Mike Hammett
> >>> Intelligent Computing Solutions
> >>> http://www.ics-il.com
> >>>
> >>> ----- Original Message -----
> >>>
> >>> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
> >>> To: "Mel Beckman" <mel at beckman.org>
> >>> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
> >>> Sent: Thursday, August 27, 2015 3:14:59 PM
> >>> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
> >>>
> >>> If you have access to the Level3 portal you should see ticket #9639047
> >>> under Network Events now.
> >>>
> >>> Event Summary:IP Network Event ~ Multiple Markets
> >>>
> >>> 08/27/2015 8:05 PM GMT
> >>>
> >>> Level 3 Tier III and Operations Engineering teams have identified
> Internet
> >>> Protocols dropping, affecting customer services. Restoration efforts
> are
> >>> in progress, but an estimated time of restoral is not available at this
> >>> time.
> >>>
> >>> 08/27/2015 6:36 PM GMT
> >>>
> >>> IP and Transport Tier III, Operations Engineering and Field Services
> >>> continue collaboratively working the issue.
> >>>
> >>>
> >>> 08/27/2015 4:59 PM GMT
> >>>
> >>> Operations Engineering is engaged and Field Services is on site in
> >>> Chicago,
> >>> IL investigating the issue.
> >>>
> >>>
> >>> 08/27/2015 4:38 PM GMT
> >>>
> >>> The engineers are currently migrating traffic in efforts of restoring
> >>> services while troubleshooting continues. Field Services is being
> >>> dispatched to a Chicago, IL site to assist.
> >>>
> >>> 08/27/2015 4:21 PM GMT
> >>>
> >>> IP services are affected across multiple markets and the root cause is
> >>> currently under investigation. The IP NOC and IP and Transport Tier III
> >>> are
> >>> actively troubleshooting and working to isolate the cause. The
> engineers
> >>> have detected peering issues which are resulting in packet loss for
> >>> customers. Please be advised that updates will be provided at minimum
> of
> >>> hourly unless otherwise noted.
> >>
>

From tknchris at gmail.com  Fri Aug 28 17:01:46 2015
From: tknchris at gmail.com (chris)
Date: Fri, 28 Aug 2015 13:01:46 -0400
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
References: <CAFPFpmVqgKJsEbGz5Om=BwZBBVwXx2MX1u5e2b=NRu4Boj60jw@mail.gmail.com>
 <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAKnNFz_w07b-vT=Q89sZzs7AoNmbCC1S3bw7kWT189ys9JfwVQ@mail.gmail.com>

This reminded me of this great clip

https://www.youtube.com/watch?v=ckIMuvumYrg

On Fri, Aug 28, 2015 at 12:00 AM, Mike Hammett <nanog at ics-il.net> wrote:

> 08/28/2015 3:08 AM GMT
> Event Conclusion Summary
>
> Start: August 27, 2015 13:20 GMT
> Stop: August 28, 2015 00:00 GMT
>
> Root Cause: A protocol issue impacted IP services in multiple markets.
> Fix Action: Adjustments were made to clear the errors.
>
> Summary:
> The IP NOC began investigating the root cause with Tier III Technical
> Support. It was reported that the issue was causing packet loss for
> customers. Operations Engineering teams were engaged, and Field Services
> were dispatched to a site in Chicago, IL to assist with investigations.
> Troubleshooting identified a protocol issue, and Operations Engineering
> worked with Tier III Technical Support to perform adjustments on the links.
> It was confirmed that the errors cleared. The traffic load was also lowered
> on cards in Chicago to alleviate any further issues. Should any additional
> impact be experienced, please contact the Level 3 Technical Service Center.
>
> What the hell is a "protocol issue"?
>
> I'm not an idiot, you can tell me specifically what happened...
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> ----- Original Message -----
>
> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
> To: "Mel Beckman" <mel at beckman.org>
> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
> Sent: Thursday, August 27, 2015 3:14:59 PM
> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
>
> If you have access to the Level3 portal you should see ticket #9639047
> under Network Events now.
>
> Event Summary:IP Network Event ~ Multiple Markets
>
> 08/27/2015 8:05 PM GMT
>
> Level 3 Tier III and Operations Engineering teams have identified Internet
> Protocols dropping, affecting customer services. Restoration efforts are
> in progress, but an estimated time of restoral is not available at this
> time.
>
> 08/27/2015 6:36 PM GMT
>
> IP and Transport Tier III, Operations Engineering and Field Services
> continue collaboratively working the issue.
>
>
> 08/27/2015 4:59 PM GMT
>
> Operations Engineering is engaged and Field Services is on site in Chicago,
> IL investigating the issue.
>
>
> 08/27/2015 4:38 PM GMT
>
> The engineers are currently migrating traffic in efforts of restoring
> services while troubleshooting continues. Field Services is being
> dispatched to a Chicago, IL site to assist.
>
> 08/27/2015 4:21 PM GMT
>
> IP services are affected across multiple markets and the root cause is
> currently under investigation. The IP NOC and IP and Transport Tier III are
> actively troubleshooting and working to isolate the cause. The engineers
> have detected peering issues which are resulting in packet loss for
> customers. Please be advised that updates will be provided at minimum of
> hourly unless otherwise noted.
>
>

From tknchris at gmail.com  Fri Aug 28 17:04:35 2015
From: tknchris at gmail.com (chris)
Date: Fri, 28 Aug 2015 13:04:35 -0400
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CAJvB4tndQVeMOjCEOFHVqJ2D4a2ihHoDqGQr8duUU1kk=V_OZA@mail.gmail.com>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
 <55E07DAF.2050604@unlimitednet.us>
 <CAJvB4tndQVeMOjCEOFHVqJ2D4a2ihHoDqGQr8duUU1kk=V_OZA@mail.gmail.com>
Message-ID: <CAKnNFz9M3wzHn66r91qitcPYqvPnrCP3yxdBuUgic=HuNvsUXw@mail.gmail.com>

ill just leave this here.... :)

https://www.youtube.com/watch?v=0ilMx7k7mso

On Fri, Aug 28, 2015 at 11:33 AM, Blake Dunlap <ikiris at gmail.com> wrote:

> I'll just leave this here....
>
>
> https://honestnetworker.wordpress.com/2013/11/04/the-true-meaning-behind-most-rfos/
>
> On Fri, Aug 28, 2015 at 8:26 AM, Jason Canady <jason at unlimitednet.us>
> wrote:
> > Mike, I would take it to mean someone screwed something up and they don't
> > want to admit to it.  :-)  That's just a guess.
> >
> > --
> >
> > Jason Canady
> > Unlimited Net, LLC
> > Responsive, Reliable, Secure
> >
> > www.unlimitednet.us
> > jason at unlimitednet.us
> > twitter: @unlimitednet
> >
> >
> > On 8/28/15 12:00 AM, Mike Hammett wrote:
> >>
> >> 08/28/2015 3:08 AM GMT
> >> Event Conclusion Summary
> >>
> >> Start: August 27, 2015 13:20 GMT
> >> Stop: August 28, 2015 00:00 GMT
> >>
> >> Root Cause: A protocol issue impacted IP services in multiple markets.
> >> Fix Action: Adjustments were made to clear the errors.
> >>
> >> Summary:
> >> The IP NOC began investigating the root cause with Tier III Technical
> >> Support. It was reported that the issue was causing packet loss for
> >> customers. Operations Engineering teams were engaged, and Field Services
> >> were dispatched to a site in Chicago, IL to assist with investigations.
> >> Troubleshooting identified a protocol issue, and Operations Engineering
> >> worked with Tier III Technical Support to perform adjustments on the
> links.
> >> It was confirmed that the errors cleared. The traffic load was also
> lowered
> >> on cards in Chicago to alleviate any further issues. Should any
> additional
> >> impact be experienced, please contact the Level 3 Technical Service
> Center.
> >>
> >> What the hell is a "protocol issue"?
> >>
> >> I'm not an idiot, you can tell me specifically what happened...
> >>
> >>
> >>
> >>
> >> -----
> >> Mike Hammett
> >> Intelligent Computing Solutions
> >> http://www.ics-il.com
> >>
> >> ----- Original Message -----
> >>
> >> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
> >> To: "Mel Beckman" <mel at beckman.org>
> >> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
> >> Sent: Thursday, August 27, 2015 3:14:59 PM
> >> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
> >>
> >> If you have access to the Level3 portal you should see ticket #9639047
> >> under Network Events now.
> >>
> >> Event Summary:IP Network Event ~ Multiple Markets
> >>
> >> 08/27/2015 8:05 PM GMT
> >>
> >> Level 3 Tier III and Operations Engineering teams have identified
> Internet
> >> Protocols dropping, affecting customer services. Restoration efforts are
> >> in progress, but an estimated time of restoral is not available at this
> >> time.
> >>
> >> 08/27/2015 6:36 PM GMT
> >>
> >> IP and Transport Tier III, Operations Engineering and Field Services
> >> continue collaboratively working the issue.
> >>
> >>
> >> 08/27/2015 4:59 PM GMT
> >>
> >> Operations Engineering is engaged and Field Services is on site in
> >> Chicago,
> >> IL investigating the issue.
> >>
> >>
> >> 08/27/2015 4:38 PM GMT
> >>
> >> The engineers are currently migrating traffic in efforts of restoring
> >> services while troubleshooting continues. Field Services is being
> >> dispatched to a Chicago, IL site to assist.
> >>
> >> 08/27/2015 4:21 PM GMT
> >>
> >> IP services are affected across multiple markets and the root cause is
> >> currently under investigation. The IP NOC and IP and Transport Tier III
> >> are
> >> actively troubleshooting and working to isolate the cause. The engineers
> >> have detected peering issues which are resulting in packet loss for
> >> customers. Please be advised that updates will be provided at minimum of
> >> hourly unless otherwise noted.
> >>
> >
>

From cscora at apnic.net  Fri Aug 28 18:13:28 2015
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 29 Aug 2015 04:13:28 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201508281813.t7SIDS6k029458@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 <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 29 Aug, 2015

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

Analysis Summary
----------------

BGP routing table entries examined:                              556877
    Prefixes after maximum aggregation (per Origin AS):          210209
    Deaggregation factor:                                          2.65
    Unique aggregates announced (without unneeded subnets):      272891
Total ASes present in the Internet Routing Table:                 51281
    Prefixes per ASN:                                             10.86
Origin-only ASes present in the Internet Routing Table:           36680
Origin ASes announcing only one prefix:                           16140
Transit ASes present in the Internet Routing Table:                6362
Transit-only ASes present in the Internet Routing Table:            169
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      45
    Max AS path prepend of ASN ( 55644)                              41
Prefixes from unregistered ASNs in the Routing Table:              1164
    Unregistered ASNs in the Routing Table:                         426
Number of 32-bit ASNs allocated by the RIRs:                      10780
Number of 32-bit ASNs visible in the Routing Table:                8239
Prefixes from 32-bit ASNs in the Routing Table:                   30881
Number of bogon 32-bit ASNs visible in the Routing Table:            18
Special use prefixes present in the Routing Table:                    1
Prefixes being announced from unallocated address space:            417
Number of addresses announced to Internet:                   2792002752
    Equivalent to 166 /8s, 106 /16s and 148 /24s
    Percentage of available address space announced:               75.4
    Percentage of allocated address space announced:               75.4
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               97.6
Total number of prefixes smaller than registry allocations:      185757

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   137357
    Total APNIC prefixes after maximum aggregation:               39703
    APNIC Deaggregation factor:                                    3.46
Prefixes being announced from the APNIC address blocks:          144673
    Unique aggregates announced from the APNIC address blocks:    59491
APNIC Region origin ASes present in the Internet Routing Table:    5079
    APNIC Prefixes per ASN:                                       28.48
APNIC Region origin ASes announcing only one prefix:               1207
APNIC Region transit ASes present in the Internet Routing Table:    893
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         45
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1600
Number of APNIC addresses announced to Internet:              751999104
    Equivalent to 44 /8s, 210 /16s and 152 /24s
    Percentage of available APNIC address space announced:         87.9

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:                    180309
    Total ARIN prefixes after maximum aggregation:                88398
    ARIN Deaggregation factor:                                     2.04
Prefixes being announced from the ARIN address blocks:           183221
    Unique aggregates announced from the ARIN address blocks:     86088
ARIN Region origin ASes present in the Internet Routing Table:    16593
    ARIN Prefixes per ASN:                                        11.04
ARIN Region origin ASes announcing only one prefix:                6070
ARIN Region transit ASes present in the Internet Routing Table:    1735
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          33
Number of ARIN region 32-bit ASNs visible in the Routing Table:     630
Number of ARIN addresses announced to Internet:              1102416576
    Equivalent to 65 /8s, 181 /16s and 138 /24s
    Percentage of available ARIN address space announced:          58.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, 64198-64296, 393216-395164
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:                    134874
    Total RIPE prefixes after maximum aggregation:                67372
    RIPE Deaggregation factor:                                     2.00
Prefixes being announced from the RIPE address blocks:           141751
    Unique aggregates announced from the RIPE address blocks:     88005
RIPE Region origin ASes present in the Internet Routing Table:    17969
    RIPE Prefixes per ASN:                                         7.89
RIPE Region origin ASes announcing only one prefix:                8057
RIPE Region transit ASes present in the Internet Routing Table:    2969
Average RIPE Region AS path length visible:                         4.5
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    3976
Number of RIPE addresses announced to Internet:               699396736
    Equivalent to 41 /8s, 175 /16s and 242 /24s
    Percentage of available RIPE address space announced:         101.7

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-204287
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:                   60914
    Total LACNIC prefixes after maximum aggregation:              11602
    LACNIC Deaggregation factor:                                   5.25
Prefixes being announced from the LACNIC address blocks:          72516
    Unique aggregates announced from the LACNIC address blocks:   33623
LACNIC Region origin ASes present in the Internet Routing Table:   2462
    LACNIC Prefixes per ASN:                                      29.45
LACNIC Region origin ASes announcing only one prefix:               611
LACNIC Region transit ASes present in the Internet Routing Table:   525
Average LACNIC Region AS path length visible:                       5.0
    Max LACNIC Region AS path length visible:                        28
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  1888
Number of LACNIC addresses announced to Internet:             168599552
    Equivalent to 10 /8s, 12 /16s and 160 /24s
    Percentage of available LACNIC address space announced:       100.5

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:                  12356
    Total AfriNIC prefixes after maximum aggregation:              3088
    AfriNIC Deaggregation factor:                                  4.00
Prefixes being announced from the AfriNIC address blocks:         14299
    Unique aggregates announced from the AfriNIC address blocks:   5328
AfriNIC Region origin ASes present in the Internet Routing Table:   739
    AfriNIC Prefixes per ASN:                                     19.35
AfriNIC Region origin ASes announcing only one prefix:              195
AfriNIC Region transit ASes present in the Internet Routing Table:  164
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       27
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  145
Number of AfriNIC addresses announced to Internet:             69168384
    Equivalent to 4 /8s, 31 /16s and 109 /24s
    Percentage of available AfriNIC address space announced:       68.7

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     3010      11175         987   Korea Telecom
 7545     2763        339         134   TPG Telecom Limited
17974     2703        904          80   PT Telekomunikasi Indonesia
 4755     2036        426         223   TATA Communications formerly 
 4538     1949       4190          71   China Education and Research 
 9829     1871       1373         198   National Internet Backbone
 9808     1585       8639          18   Guangdong Mobile Communicatio
 4808     1529       2254         474   CNCGROUP IP network China169 
 9583     1526        121         570   Sify Limited
 7552     1400       1084           9   Viettel Corporation

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     3165       2960         139   Cox Communications Inc.
 6389     2696       3688          51   BellSouth.net Inc.
 3356     2530      10709         498   Level 3 Communications, Inc.
18566     2147        390         255   MegaPath Corporation
20115     1877       1856         393   Charter Communications
 6983     1738        851         243   EarthLink, Inc.
 4323     1589       1006         410   tw telecom holdings, inc.
30036     1575        319         452   Mediacom Communications Corp
  701     1404      11392         684   MCI Communications Services, 
22561     1377        415         258   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
20940     2081        820        1513   Akamai International B.V.
34984     2026        306         380   TELLCOM ILETISIM HIZMETLERI A
 6849     1207        355          21   JSC "Ukrtelecom"
13188     1069         97          77   TOV "Bank-Inform"
31148     1048         46          23   Freenet Ltd.
 8551      995        376          52   Bezeq International-Ltd
12479      984        933          77   France Telecom Espana SA
 6830      915       2678         467   Liberty Global Operations B.V
 8402      890        544          15   OJSC "Vimpelcom"

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     3343        538         162   Telmex Colombia S.A.
28573     2298       2169         136   NET Servi?os de Comunica??o S
 8151     1690       3268         478   Uninet S.A. de C.V.
 7303     1558        932         238   Telecom Argentina S.A.
 6147     1438        374          30   Telefonica del Peru S.A.A.
 6503     1254        425          56   Axtel, S.A.B. de C.V.
26615     1095       2325          35   Tim Celular S.A.
 7738      996       1882          41   Telemar Norte Leste S.A.
 3816      953        436         163   COLOMBIA TELECOMUNICACIONES S
11830      919        364          15   Instituto Costarricense de El

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      919        281          32   Link Egypt (Link.NET)
 8452      897       1470          14   TE-AS
36903      512        258          99   Office National des Postes et
36992      439       1229          32   ETISALAT MISR
37492      315        191          72   Orange Tunisie
24835      308        146          12   Vodafone Data
 3741      252        857         208   Internet Solutions
29571      247         21          13   Cote d'Ivoire Telecom
37054      204         20           7   Data Telecom Service
36947      185        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     3343        538         162   Telmex Colombia S.A.
22773     3165       2960         139   Cox Communications Inc.
 4766     3010      11175         987   Korea Telecom
 7545     2763        339         134   TPG Telecom Limited
17974     2703        904          80   PT Telekomunikasi Indonesia
 6389     2696       3688          51   BellSouth.net Inc.
 3356     2530      10709         498   Level 3 Communications, Inc.
39891     2472        128           6   SaudiNet, Saudi Telecom Compa
28573     2298       2169         136   NET Servi?os de Comunica??o S
18566     2147        390         255   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      3165        3026      Cox Communications Inc.
 6389      2696        2645      BellSouth.net Inc.
 7545      2763        2629      TPG Telecom Limited
17974      2703        2623      PT Telekomunikasi Indonesia
39891      2472        2466      SaudiNet, Saudi Telecom Compa
28573      2298        2162      NET Servi?os de Comunica??o S
 3356      2530        2032      Level 3 Communications, Inc.
 4766      3010        2023      Korea Telecom
18566      2147        1892      MegaPath Corporation
 4538      1949        1878      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
47092   UNALLOCATED  8.8.204.0/24         16410       The Reynolds and Rey
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
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

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.100.1.0/24        9730     Bharti Telesonic Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
23.249.144.0/21      40430     colo4jax, LLC
23.249.152.0/21      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
31.170.96.0/23       23456     32bit Transition AS
31.217.248.0/21      44902     COVAGE NETWORKS SASU
36.50.0.0/16         23456     32bit Transition AS
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.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:17       /9:13      /10:36      /11:96      /12:261     
/13:500     /14:1001    /15:1735    /16:12890   /17:7217    /18:12390   
/19:25559   /20:36137   /21:38902   /22:61214   /23:53315   /24:303298  
/25:848     /26:931     /27:458     /28:14      /29:14      /30:9       
/31:0       /32:22      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
39891     2432          2472      SaudiNet, Saudi Telecom Compa
22773     2380          3165      Cox Communications Inc.
18566     2062          2147      MegaPath Corporation
 6389     1608          2696      BellSouth.net Inc.
30036     1395          1575      Mediacom Communications Corp
 6983     1385          1738      EarthLink, Inc.
34984     1346          2026      TELLCOM ILETISIM HIZMETLERI A
10620     1214          3343      Telmex Colombia S.A.
11492     1125          1208      CABLE ONE, INC.
22561     1050          1377      CenturyTel Internet Holdings,

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1563      2:688       4:97        5:1878      6:25        8:1397   
  12:1811     13:12       14:1416     15:16       16:2        17:48     
  18:22       20:49       23:1262     24:1754     27:2046     31:1586   
  32:37       33:2        34:4        35:3        36:163      37:2034   
  38:1059     39:14       40:70       41:2782     42:332      43:1481   
  44:30       45:1042     46:2356     47:53       49:934      50:787    
  52:22       54:86       55:6        56:27       57:42       58:1365   
  59:716      60:485      61:1758     62:1383     63:1905     64:4431   
  65:2250     66:3998     67:2060     68:1068     69:3229     70:1032   
  71:447      72:1974     74:2597     75:356      76:397      77:1350   
  78:1125     79:811      80:1349     81:1349     82:872      83:722    
  84:784      85:1387     86:448      87:1036     88:535      89:1939   
  90:166      91:5937     92:845      93:2281     94:2062     95:2165   
  96:420      97:348      98:975      99:55      100:74      101:844    
 103:8127    104:2016    105:72      106:348     107:1070    108:622    
 109:2142    110:1196    111:1467    112:822     113:1112    114:851    
 115:1329    116:1467    117:1097    118:1935    119:1470    120:451    
 121:1090    122:2170    123:1845    124:1517    125:1674    128:593    
 129:395     130:431     131:1251    132:494     133:165     134:416    
 135:103     136:333     137:317     138:1190    139:148     140:251    
 141:435     142:679     143:546     144:547     145:126     146:793    
 147:585     148:1254    149:430     150:593     151:798     152:537    
 153:254     154:506     155:873     156:421     157:420     158:344    
 159:1033    160:413     161:676     162:2046    163:455     164:692    
 165:803     166:301     167:862     168:1252    169:192     170:1475   
 171:249     172:244     173:1506    174:720     175:702     176:1441   
 177:3958    178:2179    179:1006    180:1949    181:1665    182:1802   
 183:633     184:748     185:4181    186:2962    187:1854    188:2087   
 189:1615    190:7794    191:1138    192:8559    193:5670    194:4229   
 195:3645    196:1988    197:1065    198:5495    199:5516    200:6701   
 201:3304    202:9528    203:9184    204:4676    205:2894    206:3091   
 207:3032    208:4013    209:3908    210:3600    211:1929    212:2555   
 213:2236    214:845     215:74      216:5757    217:1830    218:732    
 219:465     220:1555    221:810     222:473     223:820    

End of report

From richard.hesse at weebly.com  Fri Aug 28 18:23:01 2015
From: richard.hesse at weebly.com (Richard Hesse)
Date: Fri, 28 Aug 2015 18:23:01 +0000
Subject: Experience on Wanguard for 'anti' DDOS solutions
In-Reply-To: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
References: <1117637696.1801282.1439189885305.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAJj1h3GPmc0yyL5TLN=2SfUFrMOjckWoTsVN9L01z6vXXyQK9w@mail.gmail.com>

We've tried their products off an on for the past 3-4 years. Here are
my impressions:

* UI stuck in 1999. Can't click zoom, drill down, etc.
* Inflexible UI. Want a bandwidth graph with only egress or ingress? Too bad.
* Inexpensive. I don't like that it's licensed yearly, but it's not
too much money.
* Inaccurate flow processing. Do you have iBGP peering sessions
between border routers? WANGuard will struggle mightily to correctly
classify the traffic as internal or external.
* Yes, it runs out of memory quickly during a spoofed SYN flood with
many sources. This is due to setting the Top generator to Full. If you
just want to mitigate and not have any insight into network data, set
this to Extended and you'll be fine. But if you want to use
WANGuard/WANSight as a network intelligence tool as well, you need to
set the generator to Full and it will fall over.
* Doesn't process IPFIX flow data properly. There's an old thread on
the j-nsp list about this. Basically their support claims Juniper is
broken (which I don't doubt) but then refuses to work around the
issue. None of our other flow processing tools have these problems.
* Support is responsive at times and is always cranky. I brought them
two bonafide bugs in their product that they refused to admit. It got
to the point where I asked for my money back and I think someone in
sales lit up their support team. I get the feeling that the support
team is staffed with employees who really don't like their job or
working with customers. A bad combination.
* The TAP generators with Myricom cards work well. The docs say you
can use SolarFlare for TAPs but they don't work at all. Again, they
blame SolarFlare and say that the cards are too complicated....but
fail to update their documentation saying this.
* Doesn't support any kind of layer 7 detection or filtering. It's all
very rudimentary layer 3-4 stuff. Considering how easy it is to block
layer 3/4 attacks on your own, their filtering clusters don't offer
much value.
* No real scale out solution on the detection side. It's basically
scale up your server or use clunky tech like NFS to share out
directories across managers.
* Works well enough to get you a rough idea of what's going on. It's
also decently cheap.

We use it as one part of our attack detection toolset. We don't use it
for on-site attack mitigation. I'd recommend it if you don't want to
use flow data and only want to use it for intelligence on TAP ports.

-richard

On Mon, Aug 10, 2015 at 6:58 AM, Marcel Duregards
<marcel.duregards at yahoo.fr> wrote:
> Dear Nogers,
> We are currently evaluating some DDOS detection/mitigation solutions.
> Do you have any inputs/experiences on Wanguard from Andrisoft, please ?https://www.andrisoft.com/software/wanguard
> Currently we are just interested on the packets/flows sensors with the console for detection and RTBH trigger. Maybe the packet filtering (for scrubbing) will come later.
> Best Regards,-Marcel Duregards
>
>
>

From nanog at afxr.net  Fri Aug 28 18:48:26 2015
From: nanog at afxr.net (Randy)
Date: Fri, 28 Aug 2015 13:48:26 -0500
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
Message-ID: <55E0ACFA.6010604@afxr.net>

On 8/27/2015 11:00 PM, Mike Hammett wrote:
> 08/28/2015 3:08 AM GMT
> Event Conclusion Summary
>
> Start: August 27, 2015 13:20 GMT
> Stop: August 28, 2015 00:00 GMT
>
> Root Cause: A protocol issue impacted IP services in multiple markets.
> Fix Action: Adjustments were made to clear the errors.
>
> Summary:
> The IP NOC began investigating the root cause with Tier III Technical Support. It was reported that the issue was causing packet loss for customers. Operations Engineering teams were engaged, and Field Services were dispatched to a site in Chicago, IL to assist with investigations. Troubleshooting identified a protocol issue, and Operations Engineering worked with Tier III Technical Support to perform adjustments on the links. It was confirmed that the errors cleared. The traffic load was also lowered on cards in Chicago to alleviate any further issues. Should any additional impact be experienced, please contact the Level 3 Technical Service Center.
>
> What the hell is a "protocol issue"?
>
> I'm not an idiot, you can tell me specifically what happened...
I was having major issues yesterday. It wasn't with all traffic, and its 
seemed to have cleared up now.
I did do packet inspections, and I kept getting ethernet frame check 
errors from certain sources.
vast majority of packets did not have this extra data appended to the 
tcp portion of packet, and I think that is likely the reason for the 
issues, since those packets are supposed to be dropped if there is a 
checksum error. I'm by no means an expert, just voicing what I was seeing.

>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> ----- Original Message -----
>
> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
> To: "Mel Beckman" <mel at beckman.org>
> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
> Sent: Thursday, August 27, 2015 3:14:59 PM
> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
>
> If you have access to the Level3 portal you should see ticket #9639047
> under Network Events now.
>
> Event Summary:IP Network Event ~ Multiple Markets
>
> 08/27/2015 8:05 PM GMT
>
> Level 3 Tier III and Operations Engineering teams have identified Internet
> Protocols dropping, affecting customer services. Restoration efforts are
> in progress, but an estimated time of restoral is not available at this
> time.
>
> 08/27/2015 6:36 PM GMT
>
> IP and Transport Tier III, Operations Engineering and Field Services
> continue collaboratively working the issue.
>
>
> 08/27/2015 4:59 PM GMT
>
> Operations Engineering is engaged and Field Services is on site in Chicago,
> IL investigating the issue.
>
>
> 08/27/2015 4:38 PM GMT
>
> The engineers are currently migrating traffic in efforts of restoring
> services while troubleshooting continues. Field Services is being
> dispatched to a Chicago, IL site to assist.
>
> 08/27/2015 4:21 PM GMT
>
> IP services are affected across multiple markets and the root cause is
> currently under investigation. The IP NOC and IP and Transport Tier III are
> actively troubleshooting and working to isolate the cause. The engineers
> have detected peering issues which are resulting in packet loss for
> customers. Please be advised that updates will be provided at minimum of
> hourly unless otherwise noted.
>


From mel at beckman.org  Fri Aug 28 19:44:20 2015
From: mel at beckman.org (Mel Beckman)
Date: Fri, 28 Aug 2015 19:44:20 +0000
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <55E0ACFA.6010604@afxr.net>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>,
 <55E0ACFA.6010604@afxr.net>
Message-ID: <D85637E1-DB09-4B09-A573-AD3F877BFCFA@beckman.org>

Randy,

Frame Check Sequence errors are not a problem if you are capturing your packets from an endpoint system such as a PC participating in communications. Modern network cards do checksum offloading, so the FCS is calculated and applied by the NIC instead of by the OS. If you're capturing on one of the endpoints, Wireshark will see frames transmitted by that endpoint machine before the NIC inserts a correct FCS.

If communication succeeds (e.g., you see replies to pings), then there is not really an FCS error. If the FCS really was incorrect, the NIC would have discarded them, and you wouldn't see replies.

It's best to capture directly from the wire (for example, from a switch span port or a network tap) rather than an endpoint involved in the communication.

-mel

On Aug 28, 2015, at 11:49 AM, Randy <nanog at afxr.net<mailto:nanog at afxr.net>> wrote:

On 8/27/2015 11:00 PM, Mike Hammett wrote:
08/28/2015 3:08 AM GMT
Event Conclusion Summary

Start: August 27, 2015 13:20 GMT
Stop: August 28, 2015 00:00 GMT

Root Cause: A protocol issue impacted IP services in multiple markets.
Fix Action: Adjustments were made to clear the errors.

Summary:
The IP NOC began investigating the root cause with Tier III Technical Support. It was reported that the issue was causing packet loss for customers. Operations Engineering teams were engaged, and Field Services were dispatched to a site in Chicago, IL to assist with investigations. Troubleshooting identified a protocol issue, and Operations Engineering worked with Tier III Technical Support to perform adjustments on the links. It was confirmed that the errors cleared. The traffic load was also lowered on cards in Chicago to alleviate any further issues. Should any additional impact be experienced, please contact the Level 3 Technical Service Center.

What the hell is a "protocol issue"?

I'm not an idiot, you can tell me specifically what happened...
I was having major issues yesterday. It wasn't with all traffic, and its seemed to have cleared up now.
I did do packet inspections, and I kept getting ethernet frame check errors from certain sources.
vast majority of packets did not have this extra data appended to the tcp portion of packet, and I think that is likely the reason for the issues, since those packets are supposed to be dropped if there is a checksum error. I'm by no means an expert, just voicing what I was seeing.




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

----- Original Message -----

From: "Ryan Gelobter" <ryan.g at atwgpc.net<mailto:ryan.g at atwgpc.net>>
To: "Mel Beckman" <mel at beckman.org<mailto:mel at beckman.org>>
Cc: "<nanog at nanog.org<mailto:nanog at nanog.org>>" <nanog at nanog.org<mailto:nanog at nanog.org>>
Sent: Thursday, August 27, 2015 3:14:59 PM
Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)

If you have access to the Level3 portal you should see ticket #9639047
under Network Events now.

Event Summary:IP Network Event ~ Multiple Markets

08/27/2015 8:05 PM GMT

Level 3 Tier III and Operations Engineering teams have identified Internet
Protocols dropping, affecting customer services. Restoration efforts are
in progress, but an estimated time of restoral is not available at this
time.

08/27/2015 6:36 PM GMT

IP and Transport Tier III, Operations Engineering and Field Services
continue collaboratively working the issue.


08/27/2015 4:59 PM GMT

Operations Engineering is engaged and Field Services is on site in Chicago,
IL investigating the issue.


08/27/2015 4:38 PM GMT

The engineers are currently migrating traffic in efforts of restoring
services while troubleshooting continues. Field Services is being
dispatched to a Chicago, IL site to assist.

08/27/2015 4:21 PM GMT

IP services are affected across multiple markets and the root cause is
currently under investigation. The IP NOC and IP and Transport Tier III are
actively troubleshooting and working to isolate the cause. The engineers
have detected peering issues which are resulting in packet loss for
customers. Please be advised that updates will be provided at minimum of
hourly unless otherwise noted.



From paras at protrafsolutions.com  Fri Aug 28 16:06:44 2015
From: paras at protrafsolutions.com (Paras)
Date: Fri, 28 Aug 2015 12:06:44 -0400
Subject: Level(3) ex-twtelecom midwest packet loss (4323)
In-Reply-To: <CBA050BD-9EC0-44D7-BCE6-9CCDD1C20D95@beckman.org>
References: <426251209.4762.1440734471116.JavaMail.mhammett@ThunderFuck>
 <55E07DAF.2050604@unlimitednet.us>
 <CAJvB4tndQVeMOjCEOFHVqJ2D4a2ihHoDqGQr8duUU1kk=V_OZA@mail.gmail.com>
 <CBA050BD-9EC0-44D7-BCE6-9CCDD1C20D95@beckman.org>
Message-ID: <55E08714.5070502@protrafsolutions.com>

Personally I thought it was funny

I don't think it was meant to come across as offensive

On 8/28/2015 11:45 AM, Mel Beckman wrote:
> Blake,
>
> There's no call to be blatantly offensive like that.
>
> -mel
>
>> On Aug 28, 2015, at 8:35 AM, Blake Dunlap <ikiris at gmail.com> wrote:
>>
>> I'll just leave this here....
>>
>> https://honestnetworker.wordpress.com/2013/11/04/the-true-meaning-behind-most-rfos/
>>
>>> On Fri, Aug 28, 2015 at 8:26 AM, Jason Canady <jason at unlimitednet.us> wrote:
>>> Mike, I would take it to mean someone screwed something up and they don't
>>> want to admit to it.  :-)  That's just a guess.
>>>
>>> --
>>>
>>> Jason Canady
>>> Unlimited Net, LLC
>>> Responsive, Reliable, Secure
>>>
>>> www.unlimitednet.us
>>> jason at unlimitednet.us
>>> twitter: @unlimitednet
>>>
>>>
>>>> On 8/28/15 12:00 AM, Mike Hammett wrote:
>>>>
>>>> 08/28/2015 3:08 AM GMT
>>>> Event Conclusion Summary
>>>>
>>>> Start: August 27, 2015 13:20 GMT
>>>> Stop: August 28, 2015 00:00 GMT
>>>>
>>>> Root Cause: A protocol issue impacted IP services in multiple markets.
>>>> Fix Action: Adjustments were made to clear the errors.
>>>>
>>>> Summary:
>>>> The IP NOC began investigating the root cause with Tier III Technical
>>>> Support. It was reported that the issue was causing packet loss for
>>>> customers. Operations Engineering teams were engaged, and Field Services
>>>> were dispatched to a site in Chicago, IL to assist with investigations.
>>>> Troubleshooting identified a protocol issue, and Operations Engineering
>>>> worked with Tier III Technical Support to perform adjustments on the links.
>>>> It was confirmed that the errors cleared. The traffic load was also lowered
>>>> on cards in Chicago to alleviate any further issues. Should any additional
>>>> impact be experienced, please contact the Level 3 Technical Service Center.
>>>>
>>>> What the hell is a "protocol issue"?
>>>>
>>>> I'm not an idiot, you can tell me specifically what happened...
>>>>
>>>>
>>>>
>>>>
>>>> -----
>>>> Mike Hammett
>>>> Intelligent Computing Solutions
>>>> http://www.ics-il.com
>>>>
>>>> ----- Original Message -----
>>>>
>>>> From: "Ryan Gelobter" <ryan.g at atwgpc.net>
>>>> To: "Mel Beckman" <mel at beckman.org>
>>>> Cc: "<nanog at nanog.org>" <nanog at nanog.org>
>>>> Sent: Thursday, August 27, 2015 3:14:59 PM
>>>> Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323)
>>>>
>>>> If you have access to the Level3 portal you should see ticket #9639047
>>>> under Network Events now.
>>>>
>>>> Event Summary:IP Network Event ~ Multiple Markets
>>>>
>>>> 08/27/2015 8:05 PM GMT
>>>>
>>>> Level 3 Tier III and Operations Engineering teams have identified Internet
>>>> Protocols dropping, affecting customer services. Restoration efforts are
>>>> in progress, but an estimated time of restoral is not available at this
>>>> time.
>>>>
>>>> 08/27/2015 6:36 PM GMT
>>>>
>>>> IP and Transport Tier III, Operations Engineering and Field Services
>>>> continue collaboratively working the issue.
>>>>
>>>>
>>>> 08/27/2015 4:59 PM GMT
>>>>
>>>> Operations Engineering is engaged and Field Services is on site in
>>>> Chicago,
>>>> IL investigating the issue.
>>>>
>>>>
>>>> 08/27/2015 4:38 PM GMT
>>>>
>>>> The engineers are currently migrating traffic in efforts of restoring
>>>> services while troubleshooting continues. Field Services is being
>>>> dispatched to a Chicago, IL site to assist.
>>>>
>>>> 08/27/2015 4:21 PM GMT
>>>>
>>>> IP services are affected across multiple markets and the root cause is
>>>> currently under investigation. The IP NOC and IP and Transport Tier III
>>>> are
>>>> actively troubleshooting and working to isolate the cause. The engineers
>>>> have detected peering issues which are resulting in packet loss for
>>>> customers. Please be advised that updates will be provided at minimum of
>>>> hourly unless otherwise noted.



From cidr-report at potaroo.net  Fri Aug 28 22:00:00 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 28 Aug 2015 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201508282200.t7SM00a2002438@wattle.apnic.net>

This report has been generated at Fri Aug 28 21:14:41 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
        21-08-15    565311      307557
        22-08-15    565397      307372
        23-08-15    564695      307460
        24-08-15    564815      308049
        25-08-15    565247      307192
        26-08-15    565168      306930
        27-08-15    565019      306047
        28-08-15    565765      306135


AS Summary
         51555  Number of ASes in routing system
         20455  Number of ASes announcing only one prefix
          3344  Largest number of prefixes announced by an AS
                AS10620: Telmex Colombia S.A.,CO
      120888576  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').

 --- 28Aug15 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     565908   306049   259859    45.9%   All ASes

AS22773     3168      169     2999    94.7%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.,US
AS6389      2695       69     2626    97.4%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.,US
AS17974     2703       80     2623    97.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia,ID
AS39891     2473       33     2440    98.7%   ALJAWWALSTC-AS Saudi Telecom
                                               Company JSC,SA
AS7545      2908      624     2284    78.5%   TPG-INTERNET-AP TPG Telecom
                                               Limited,AU
AS28573     2297      148     2149    93.6%   NET Servi?os de Comunica??o
                                               S.A.,BR
AS9394      2104      201     1903    90.4%   CTTNET China TieTong
                                               Telecommunications
                                               Corporation,CN
AS4766      3010     1280     1730    57.5%   KIXS-AS-KR Korea Telecom,KR
AS10620     3344     1619     1725    51.6%   Telmex Colombia S.A.,CO
AS9808      1585       75     1510    95.3%   CMNET-GD Guangdong Mobile
                                               Communication Co.Ltd.,CN
AS6983      1736      245     1491    85.9%   ITCDELTA - Earthlink, Inc.,US
AS4755      2038      556     1482    72.7%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP,IN
AS20115     1877      406     1471    78.4%   CHARTER-NET-HKY-NC - Charter
                                               Communications,US
AS3356      2537     1217     1320    52.0%   LEVEL3 - Level 3
                                               Communications, Inc.,US
AS9498      1386      121     1265    91.3%   BBIL-AP BHARTI Airtel Ltd.,IN
AS18566     2148      956     1192    55.5%   MEGAPATH5-US - MegaPath
                                               Corporation,US
AS4323      1594      411     1183    74.2%   TWTC - tw telecom holdings,
                                               inc.,US
AS6147      1439      278     1161    80.7%   Telefonica del Peru S.A.A.,PE
AS6849      1208       74     1134    93.9%   UKRTELNET JSC UKRTELECOM,UA
AS4788      1191       68     1123    94.3%   TMNET-AS-AP TM Net, Internet
                                               Service Provider,MY
AS7303      1556      522     1034    66.5%   Telecom Argentina S.A.,AR
AS7552      1400      366     1034    73.9%   VIETEL-AS-AP Viettel
                                               Corporation,VN
AS22561     1377      343     1034    75.1%   CENTURYLINK-LEGACY-LIGHTCORE -
                                               CenturyTel Internet Holdings,
                                               Inc.,US
AS4808      1545      512     1033    66.9%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network,CN
AS38197     1312      366      946    72.1%   SUNHK-DATA-AS-AP Sun Network
                                               (Hong Kong) Limited,HK
AS26615     1098      153      945    86.1%   Tim Celular S.A.,BR
AS8151      1693      763      930    54.9%   Uninet S.A. de C.V.,MX
AS7738       996       77      919    92.3%   Telemar Norte Leste S.A.,BR
AS8402       885       21      864    97.6%   CORBINA-AS OJSC "Vimpelcom",RU
AS38285      982      133      849    86.5%   M2TELECOMMUNICATIONS-AU M2
                                               Telecommunications Group
                                               Ltd,AU

Total      56285    11886    44399    78.9%   Top 30 total


Possible Bogus Routes

        23.226.112.0/20      AS62788 -Reserved AS-,ZZ
        23.249.144.0/20      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        23.249.144.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        23.249.152.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        27.100.7.0/24        AS56096 
        31.170.96.0/23       AS19798 YOUZEE-MAIN Manaslu Media Entertainment SL,ES
        31.217.248.0/21      AS44902 COV-ASN COVAGE NETWORKS SASU,FR
        36.50.0.0/16         AS20418 MOSMOG-AS OJSC TORGOVYJ DOM MOSKVA-MOGILEV,RU
        41.73.1.0/24         AS37004 -Reserved AS-,ZZ
        41.73.2.0/24         AS37004 -Reserved AS-,ZZ
        41.73.3.0/24         AS37004 -Reserved AS-,ZZ
        41.73.4.0/24         AS37004 -Reserved AS-,ZZ
        41.73.5.0/24         AS37004 -Reserved AS-,ZZ
        41.73.6.0/24         AS37004 -Reserved AS-,ZZ
        41.73.7.0/24         AS37004 -Reserved AS-,ZZ
        41.73.8.0/24         AS37004 -Reserved AS-,ZZ
        41.73.9.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.14.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.17.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.126.0/24      AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        41.189.127.0/24      AS37000 -Reserved AS-,ZZ
        41.189.128.0/24      AS37000 -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.254.196.0/24      AS31972 EMGINECONCEPT-01 - Emagine Concept, Inc.,US
        64.28.145.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.28.146.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        64.57.192.0/22       AS33321 -Reserved AS-,ZZ
        64.234.239.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.,US
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.,US
        66.11.224.0/21       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.234.0/24       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.11.236.0/22       AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US
        66.59.192.0/19       AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.187.240.0/24      AS22753 REDHAT-0 - Red Hat, Inc.,US
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US
        66.228.160.0/20      AS7233  YAHOO-US - Yahoo,US
        66.228.176.0/21      AS17110 YAHOO-US2 - Yahoo,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
        68.234.0.0/19        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.0.0/20        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.5.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.7.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.16.0/20       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.16.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.17.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.18.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.19.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.20.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.21.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.22.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.23.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.24.0/22       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.26.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.28.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        68.234.29.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        69.24.96.0/20        AS26804 -Reserved AS-,ZZ
        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.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
        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
        100.100.1.0/24       AS9730  BHARTITELESONIC-AS-IN-AP Bharti Telesonic Ltd,IN
        103.10.222.0/24      AS13189 
        103.11.16.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.12.48.0/22       AS17676 GIGAINFRA Softbank BB Corp.,JP
        103.13.1.0/24        AS58609 
        103.14.32.0/22       AS2519  VECTANT VECTANT Ltd.,JP
        103.15.92.0/22       AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.18.44.0/24       AS18351 
        103.18.45.0/24       AS18351 
        103.18.47.0/24       AS18351 
        103.20.100.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.101.0/24      AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN
        103.20.219.0/24      AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU
        103.22.212.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.23.148.0/23      AS13209 
        103.23.148.0/24      AS13209 
        103.23.149.0/24      AS13209 
        103.25.144.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.29.236.0/24      AS13200 
        103.29.237.0/24      AS13200 
        103.225.116.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.229.152.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.232.142.0/23     AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG
        103.232.164.0/22     AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH
        103.233.140.0/23     AS55330 GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK,AF
        103.234.8.0/22       AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.244.112.0/22     AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.52.0/22      AS2519  VECTANT VECTANT Ltd.,JP
        103.248.88.0/22      AS23818 JETINTERNET JETINTERNET Corporation,JP
        103.248.196.0/22     AS2514  INFOSPHERE NTT PC Communications, Inc.,JP
        103.250.220.0/24     AS58973 
        103.250.221.0/24     AS58973 
        103.253.164.0/23     AS13317 
        116.12.32.0/21       AS38555 LINKIT Internet Service Provider,BD
        116.199.203.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.205.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.206.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        116.199.207.0/24     AS38521 PISHON-AS-ID Pishon Wireless Teknologi, PT,ID
        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
        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.221.64.0/21      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        162.221.64.0/22      AS40430 COLO4JAX-AS - colo4jax, LLC,US
        162.221.68.0/22      AS40430 COLO4JAX-AS - colo4jax, 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.88.48.0/20       AS29927 -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
        173.249.191.0/24     AS45816 ISHK-AP I-Services Network Solution Limited,HK
        180.222.120.0/21     AS23818 JETINTERNET JETINTERNET Corporation,JP
        181.225.156.0/22     AS10834 Telefonica de Argentina,AR
        185.17.98.0/23       AS19798 HILF-AS Hilf Telecom B.V.,NL
        185.52.57.0/24       AS48039 KGT-AS KGT new media,DE
        185.52.58.0/24       AS48039 KGT-AS KGT new media,DE
        186.148.224.0/21     AS52302 Awknet International, S.A.,PA
        189.14.112.0/20      AS52720 WEBFOCO TELECOMUNICACOES LTDA,BR
        189.14.116.0/22      AS28282 -Reserved AS-,ZZ
        189.14.120.0/22      AS28282 -Reserved AS-,ZZ
        189.14.124.0/22      AS28282 -Reserved AS-,ZZ
        192.9.0.0/16         AS11479 BRM-SUN-AS - Oracle Corporation,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.67.160.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.67.161.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.67.162.0/24      AS55480 ISERVICES-HK I-Services Network Solution Ltd,HK
        192.75.239.0/24      AS23498 CDSI - COGECODATA,CA
        192.84.24.0/24       AS4323  TWTC - tw telecom holdings, inc.,US
        192.101.46.0/23      AS17139 NETRANGE - Corporate Colocation 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.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.206.140.0/24     AS54926 -Reserved AS-,ZZ
        192.206.141.0/24     AS54926 -Reserved AS-,ZZ
        192.206.142.0/24     AS54926 -Reserved AS-,ZZ
        192.206.143.0/24     AS54926 -Reserved AS-,ZZ
        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.22.224.0/20      AS6824  HERMES-NETWORK Hermes Telecom International Ltd,GB
        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.46.200.0/24      AS34243 WEBAGE Web Age Ltd,GB
        193.56.203.0/24      AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR
        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.151.160.0/19     AS39906 COPROSYS CoProSys a.s.,CZ
        193.164.152.0/24     AS3356  LEVEL3 - Level 3 Communications, Inc.,US
        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.130.0/24     AS21104 AM-NETSYS-AS Netsys JV LLC,AM
        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.8.0/21       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.9.9.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.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.233.0/24     AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR
        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.180.0/24       AS37004 -Reserved AS-,ZZ
        196.3.181.0/24       AS37004 -Reserved AS-,ZZ
        196.3.182.0/24       AS37004 -Reserved AS-,ZZ
        196.3.183.0/24       AS37004 -Reserved AS-,ZZ
        196.22.11.0/24       AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US
        198.8.72.0/21        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.72.0/22        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.76.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.77.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.78.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.8.79.0/24        AS40430 COLO4JAX-AS - colo4jax, LLC,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.91.44.0/22       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.44.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.45.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.46.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,US
        198.91.47.0/24       AS40430 COLO4JAX-AS - colo4jax, LLC,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.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.103.89.0/24      AS19523 -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.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
        201.131.5.0/24       AS28389 -Reserved AS-,ZZ
        201.131.88.0/24      AS8151  Uninet S.A. de C.V.,MX
        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.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK
        203.6.208.0/24       AS23937 
        203.6.209.0/24       AS23937 
        203.6.210.0/24       AS23937 
        203.6.211.0/24       AS23937 
        203.6.213.0/24       AS23937 
        203.6.215.0/24       AS23937 
        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.153.206.0/23     AS3561  CENTURYLINK-LEGACY-SAVVIS - Savvis,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.44.0/24       AS11065 -Reserved AS-,ZZ
        208.67.45.0/24       AS11065 -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.74.12.0/23       AS209   CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.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.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 Aug 28 22:00:01 2015
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 28 Aug 2015 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201508282200.t7SM01u6002453@wattle.apnic.net>

BGP Update Report
Interval: 20-Aug-15 -to- 27-Aug-15 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829           285802  7.0%     221.9 -- BSNL-NIB National Internet Backbone,IN
 2 - AS38197          166147  4.0%     131.5 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK
 3 - AS22059          116439  2.8%   58219.5 -- -Reserved AS-,ZZ
 4 - AS26210           80874  2.0%     569.5 -- AXS Bolivia S. A.,BO
 5 - AS3709            57253  1.4%    2120.5 -- NET-CITY-SA - City of San Antonio,US
 6 - AS22773           52705  1.3%     566.7 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
 7 - AS28024           46358  1.1%      29.5 -- Nuevatel PCS de Bolivia S.A.,BO
 8 - AS131090           37063  0.9%     134.3 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
 9 - AS13188           36755  0.9%      47.4 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA
10 - AS8001            34076  0.8%     173.9 -- NET-ACCESS-CORP - Net Access Corporation,US
11 - AS8402            31499  0.8%     106.4 -- CORBINA-AS OJSC "Vimpelcom",RU
12 - AS56636           29589  0.7%   29589.0 -- ASVEDARU VEDA Ltd.,RU
13 - AS30295           29540  0.7%    9846.7 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
14 - AS25563           29032  0.7%    9677.3 -- WEBLAND-AS Webland AG,CH
15 - AS199367           23140  0.6%   23140.0 -- AS_GBP Globe Business Publishing Limited,GB
16 - AS13999           22212  0.5%      52.6 -- Mega Cable, S.A. de C.V.,MX
17 - AS1505            20201  0.5%    2525.1 -- DNIC-AS-01505 - Headquarters, USAISC,US
18 - AS22047           19138  0.5%      63.0 -- VTR BANDA ANCHA S.A.,CL
19 - AS6849            19087  0.5%      15.8 -- UKRTELNET JSC UKRTELECOM,UA
20 - AS200671           17998  0.4%   17998.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS22059          116439  2.8%   58219.5 -- -Reserved AS-,ZZ
 2 - AS56636           29589  0.7%   29589.0 -- ASVEDARU VEDA Ltd.,RU
 3 - AS199367           23140  0.6%   23140.0 -- AS_GBP Globe Business Publishing Limited,GB
 4 - AS200671           17998  0.4%   17998.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL
 5 - AS200008           14778  0.4%   14778.0 -- PIRUM-AS Pirum Systems Limited,GB
 6 - AS30295           29540  0.7%    9846.7 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
 7 - AS25563           29032  0.7%    9677.3 -- WEBLAND-AS Webland AG,CH
 8 - AS37590            9254  0.2%    9254.0 -- BCA-ASN,AO
 9 - AS40493            7840  0.2%    7840.0 -- FACILITYSOURCEINC - FacilitySource,US
10 - AS393588            7061  0.2%    7061.0 -- MUBEA-FLO - Mubea,US
11 - AS31357           14599  0.4%    4866.3 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
12 - AS21973            4473  0.1%    4473.0 -- XPONET - Xponet,US
13 - AS327786           17399  0.4%    4349.8 -- TELECOM-4G,SS
14 - AS197068           16094  0.4%    4023.5 -- QRATOR HLL LLC,RU
15 - AS55741            3614  0.1%    3614.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN
16 - AS28773            6580  0.2%    3290.0 -- MASTER-SERVICE-AS Global Technology Ukraine Ltd,UA
17 - AS51428            7804  0.2%    2601.3 -- ASIRONNET IRONNET Ltd.,CZ
18 - AS38000            5147  0.1%    2573.5 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN
19 - AS1505            20201  0.5%    2525.1 -- DNIC-AS-01505 - Headquarters, USAISC,US
20 - AS45606           12600  0.3%    2520.0 -- 


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 64.34.125.0/24    58586  1.4%   AS22059 -- -Reserved AS-,ZZ
 2 - 76.191.107.0/24   57853  1.4%   AS22059 -- -Reserved AS-,ZZ
 3 - 192.40.244.0/24   51955  1.2%   AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US
 4 - 61.7.155.0/24     35196  0.8%   AS131090 -- CAT-IDC-4BYTENET-AS-AP 
 CAT TELECOM Public Company Ltd,CAT
,TH
 5 - 192.135.223.0/24  33877  0.8%   AS8001  -- NET-ACCESS-CORP - Net Access Corporation,US
 6 - 195.128.159.0/24  29589  0.7%   AS56636 -- ASVEDARU VEDA Ltd.,RU
 7 - 185.19.144.0/22   23140  0.5%   AS199367 -- AS_GBP Globe Business Publishing Limited,GB
 8 - 155.133.79.0/24   17998  0.4%   AS200671 -- SKOK-JAWORZNO SKOK Jaworzno,PL
 9 - 185.65.148.0/24   16091  0.4%   AS197068 -- QRATOR HLL LLC,RU
10 - 185.38.132.0/24   14778  0.3%   AS200008 -- PIRUM-AS Pirum Systems Limited,GB
11 - 78.140.0.0/18     14590  0.3%   AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU
12 - 187.244.68.0/22   13302  0.3%   AS13999 -- Mega Cable, S.A. de C.V.,MX
13 - 199.60.234.0/23   10150  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
14 - 199.60.236.0/24    9942  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
15 - 92.43.216.0/21     9916  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
16 - 185.84.192.0/22    9588  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
17 - 178.174.96.0/19    9528  0.2%   AS25563 -- WEBLAND-AS Webland AG,CH
18 - 199.60.233.0/24    9448  0.2%   AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA
19 - 196.6.255.0/24     9254  0.2%   AS37590 -- BCA-ASN,AO
20 - 94.73.56.0/21      7903  0.2%   AS42081 -- SPEEDY-NET-AS Speedy net AD,BG

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 Aug 29 11:53:25 2015
From: randy at psg.com (Randy Bush)
Date: Sat, 29 Aug 2015 13:53:25 +0200
Subject: Production-scale NAT64
In-Reply-To: <55DF3988.9010806@seacom.mu>
References: <55D5D9AA.2080203@forethought.net> <20150826T141310Z@localhost>
 <55DDCB02.8070904@seacom.mu>
 <CAD6AjGTGeQpi9udS8Bf1AVnF9SPw25fH=De1R25M6AoBN_TXtQ@mail.gmail.com>
 <440A9623-9190-4F50-B1DD-7F4AF8279D9F@puck.nether.net>
 <55DDCF8F.6020204@seacom.mu>
 <20150827012114.GA15533@puck.nether.net> <55DE941F.90806@seacom.mu>
 <alpine.OSX.2.02.1508271154360.1024@brugal>
 <55DF3988.9010806@seacom.mu>
Message-ID: <m24mjitioa.wl%randy@psg.com>

in my experience, differences in latency between ipv4 and ipv6 are
mostly due to non-congruent peering/transit.  sometimes, one or the
other has to actually go farther.

randy

From chris at marget.com  Mon Aug 31 16:12:16 2015
From: chris at marget.com (Chris Marget)
Date: Mon, 31 Aug 2015 12:12:16 -0400
Subject: PMTUD for IPv4 Multicast - How?
Message-ID: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>

I recently discovered that my routers weren't generating ICMP Type 3 Code 4
(unreachable, DF-bit) messages in response to too-big IPv4 multicast
packets with DF=1.

At first, I thought this was a bug, but then learned that RFCs 1112, 1122
and 1812 all specify that ICMP unreachables not be sent in response to
multicast packets.

RFC1981 (PMTUD for IPv6), on the other hand, is explicit that PMTUD works
for multicast flows, that the path MTU for a multicast flow is the smallest
MTU available anywhere in the distribution tree, and that a single
multicast packet may provoke many ICMP unreachables from routers along the
tree.

Further complicating matters, the default Linux behavior (ip_no_pmtu_disc =
0) sets the DF bit on all packets unless the application is explicit
(setsockopt()) that DF be cleared. This behavior strikes me as a
troublesome assumption (that the application will interpret unreachables)
in the case of unicast UDP sockets, and downright broken (because traffic
will be dropped silently) in the case of multicast UDP sockets.

I'm struggling to grok the rationale behind not sending unreachables in
response to multicast packets. It seems to me that our networks put IPv4
multicast speakers in a position where it's impossible for them to do the
right thing.

Does anybody understand why PMTUD for IPv4 multicast flows is disabled in
routers?

Is there a secret lever to enable it in Cisco IOS?

What should a responsible IPv4 multicast application do when receivers are
flung far and wide with un-knowable MTUs in the transit path?

Thanks,

/chris

From Valdis.Kletnieks at vt.edu  Mon Aug 31 16:37:01 2015
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 31 Aug 2015 12:37:01 -0400
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
Message-ID: <7184.1441039021@turing-police.cc.vt.edu>

On Mon, 31 Aug 2015 12:12:16 -0400, Chris Marget said:

> At first, I thought this was a bug, but then learned that RFCs 1112, 1122
> and 1812 all specify that ICMP unreachables not be sent in response to
> multicast packets.

> I'm struggling to grok the rationale behind not sending unreachables in
> response to multicast packets. It seems to me that our networks put IPv4
> multicast speakers in a position where it's impossible for them to do the
> right thing.

For the exact same reason that replying to an ICMP Echo Request sent to
your broadcast address is generally considered a Bad Idea.

The obvious solution is "Doctor, it hurts when I do that" "Don't do that anymore".

Don't send multicast packets with DF set.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150831/4f9607e7/attachment.pgp>

From howard.m.kash.civ at mail.mil  Mon Aug 31 16:39:09 2015
From: howard.m.kash.civ at mail.mil (Kash, Howard M CIV USARMY RDECOM ARL (US))
Date: Mon, 31 Aug 2015 16:39:09 +0000
Subject: Advance notice - H-root address change on December 1, 2015
Message-ID: <8B01299690A8A94AB8629283FAFED8F1ACBA048A@umechpanz.easf.csd.disa.mil>


This is advance notice that there is a scheduled change to the IP addresses
for one of the authorities listed for the DNS root zone and the .ARPA TLD.
The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army
Research Laboratory.
 
The new IPv4 address for this authority is 198.97.190.53.

The new IPv6 address for the authority is 2001:500:1::53.
 
This change is anticipated to be implemented in the root zone on 1 December
2015, however the new addresses are operational now. They will replace the
previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also
previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL).
 
We encourage operators of DNS infrastructure to update any references to the
old IP addresses and replace them with the new addresses. In particular,
many DNS resolvers have a DNS root "hints" file. This should be updated with
the new IP addresses.
 
New hints files will be available at the following URLs once the change has
been formally executed on December 1:

  http://www.internic.net/domain/named.root 
  http://www.internic.net/domain/named.cache

The old IPv4 address will continue to work for six months after the
transition (until 1 June 2016), at which point it will be retired from
service.  The address will remain under the control of the Army Research
Laboratory, never to be used again for DNS service.  The old IPv6 address
will continue to work indefinitely, but may ultimately be retired from
service.

Simultaneous to the retirement of the old address on June 1, 2016, the
ASN for H-root will change from 13 to 1508.

You can monitor the transition of queries to the new addresses at the
following URL:

  http://h.root-servers.org/old_vs_new.html


--
Howard Kash
U.S. Army Research Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5583 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150831/64f1b5c2/attachment.bin>

From chris at marget.com  Mon Aug 31 16:51:17 2015
From: chris at marget.com (Chris Marget)
Date: Mon, 31 Aug 2015 12:51:17 -0400
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <7184.1441039021@turing-police.cc.vt.edu>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
 <7184.1441039021@turing-police.cc.vt.edu>
Message-ID: <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>

On Mon, Aug 31, 2015 at 12:37 PM, <Valdis.Kletnieks at vt.edu> wrote:

> On Mon, 31 Aug 2015 12:12:16 -0400, Chris Marget said:
>
> > At first, I thought this was a bug, but then learned that RFCs 1112, 1122
> > and 1812 all specify that ICMP unreachables not be sent in response to
> > multicast packets.
>
> > I'm struggling to grok the rationale behind not sending unreachables in
> > response to multicast packets. It seems to me that our networks put IPv4
> > multicast speakers in a position where it's impossible for them to do the
> > right thing.
>
> For the exact same reason that replying to an ICMP Echo Request sent to
> your broadcast address is generally considered a Bad Idea.
>
> The obvious solution is "Doctor, it hurts when I do that" "Don't do that
> anymore".
>

It's not as obvious to me as it is to you. I mean, v6 *requires* exactly
this behavior, so it can't be all that bad, can it?


> Don't send multicast packets with DF set.
>

Are you asserting that the default behavior of the Linux kernel (setting DF
on multicast packets) is wrong then?

I'll probably come around, but I've not yet concluded that "screw it,
fragment my traffic, I don't care" is the stance that a conscientious
application should be taking.

/chris

From sthaug at nethelp.no  Mon Aug 31 19:49:43 2015
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 31 Aug 2015 21:49:43 +0200 (CEST)
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
 <7184.1441039021@turing-police.cc.vt.edu>
 <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
Message-ID: <20150831.214943.74737034.sthaug@nethelp.no>

> > > At first, I thought this was a bug, but then learned that RFCs 1112, 1122
> > > and 1812 all specify that ICMP unreachables not be sent in response to
> > > multicast packets.
> >
> > > I'm struggling to grok the rationale behind not sending unreachables in
> > > response to multicast packets. It seems to me that our networks put IPv4
> > > multicast speakers in a position where it's impossible for them to do the
> > > right thing.
> >
> > For the exact same reason that replying to an ICMP Echo Request sent to
> > your broadcast address is generally considered a Bad Idea.
> >
> > The obvious solution is "Doctor, it hurts when I do that" "Don't do that
> > anymore".
> >
> 
> It's not as obvious to me as it is to you. I mean, v6 *requires* exactly
> this behavior, so it can't be all that bad, can it?

ICMP replies to multicast packets can cause ICMP "implosion". This is
not a new discussion - see for instance

http://mailman.nanog.org/pipermail/nanog/2012-June/048685.html

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From bill at herrin.us  Mon Aug 31 20:38:36 2015
From: bill at herrin.us (William Herrin)
Date: Mon, 31 Aug 2015 16:38:36 -0400
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <20150831.214943.74737034.sthaug@nethelp.no>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
 <7184.1441039021@turing-police.cc.vt.edu>
 <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
 <20150831.214943.74737034.sthaug@nethelp.no>
Message-ID: <CAP-guGV2E-4cEHHQGLxyNW32cZz82D-e9+tu8obfF2fMt8qq3A@mail.gmail.com>

On Mon, Aug 31, 2015 at 3:49 PM,  <sthaug at nethelp.no> wrote:
> ICMP replies to multicast packets can cause ICMP "implosion". This is
> not a new discussion - see for instance
>
> http://mailman.nanog.org/pipermail/nanog/2012-June/048685.html

It's a shame we handle path MTU as a layer 3 problem that gets an ICMP
response from a middlebox. It'd make more sense to truncate the
packet, set a flag, and then let layer 4 at the recipient deal with
negotiating a new size with the sender. You know, end to end principle
and all. That'd eliminate the problems with firewall-blocked protocols
and routers using private IP addresses, the usual culprits for pmtud
breakage.

It'd also let multicast protocols make reasonable choices for that
particular protocol without being stuck with the stack's default.

-Bill


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From mohta at necom830.hpcl.titech.ac.jp  Mon Aug 31 21:17:04 2015
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 01 Sep 2015 06:17:04 +0900
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
 <7184.1441039021@turing-police.cc.vt.edu>
 <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
Message-ID: <55E4C450.7070004@necom830.hpcl.titech.ac.jp>

Chris Marget wrote:

>> For the exact same reason that replying to an ICMP Echo Request sent to
>> your broadcast address is generally considered a Bad Idea.
>>
>> The obvious solution is "Doctor, it hurts when I do that" "Don't do that
>> anymore".

And, it implies that some ISPs will filter all the ICMPv6 PTB including
those generated against unicast ones, which means PMTUDv6 won't work.

Filtering ICMPv6 PTB generated against multicast packets but not unicast
ones is not very easy.

> It's not as obvious to me as it is to you. I mean, v6 *requires* exactly
> this behavior, so it can't be all that bad, can it?

Yes, of course.

See

	https://en.wikipedia.org/wiki/Design_by_committee

which is why we should avoid IPv6 entirely, especially because NAT,
with its 48bit effective address space, is fair enough and, for
theoretical purity, NAT can be modified to have full end to end
transparency (https://tools.ietf.org/html/draft-ohta-e2e-nat-00),
or, UPnP capable NAT already practically have the transparency.

> I'll probably come around, but I've not yet concluded that "screw it,
> fragment my traffic, I don't care" is the stance that a conscientious
> application should be taking.

Don't you care, for routers, generating ICMP PTB is as burdensome
as generating fragments?

							Masataka Ohta

PS

Pages 87-101 of

	ftp://chacha.hpcl.titech.ac.jp/2014/infra5.ppt

is my presentation at APNIC32 on the problem.

From chris at marget.com  Mon Aug 31 21:28:27 2015
From: chris at marget.com (Chris Marget)
Date: Mon, 31 Aug 2015 17:28:27 -0400
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <55E4C450.7070004@necom830.hpcl.titech.ac.jp>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
 <7184.1441039021@turing-police.cc.vt.edu>
 <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
 <55E4C450.7070004@necom830.hpcl.titech.ac.jp>
Message-ID: <CAAG5dDDv7k7L4JvmL_Zvd7jMD3T8AGERRE5V=mFJ7ySKh9S+6A@mail.gmail.com>

>> I'll probably come around, but I've not yet concluded that "screw it,
>> fragment my traffic, I don't care" is the stance that a conscientious
>> application should be taking.
>
> Don't you care, for routers, generating ICMP PTB is as burdensome
> as generating fragments?

I don't think so. If PMTUD is working (big IF, I know), the ICMP PTB
generation is a one-time thing (or once per 10 minutes or whatever)
and can be rate limited with little impact. Fragmenting transit
traffic, on the other hand, needs to be done for every transit packet.

From chris at marget.com  Mon Aug 31 21:34:27 2015
From: chris at marget.com (Chris Marget)
Date: Mon, 31 Aug 2015 17:34:27 -0400
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <20150831.214943.74737034.sthaug@nethelp.no>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
 <7184.1441039021@turing-police.cc.vt.edu>
 <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
 <20150831.214943.74737034.sthaug@nethelp.no>
Message-ID: <CAAG5dDC90G3Chc9w65q=UZKohNfvMqogm8mQUZtwvSwD8V0VRw@mail.gmail.com>

> > It's not as obvious to me as it is to you. I mean, v6 *requires* exactly
> > this behavior, so it can't be all that bad, can it?
>
> ICMP replies to multicast packets can cause ICMP "implosion". This is
> not a new discussion - see for instance
>
> http://mailman.nanog.org/pipermail/nanog/2012-June/048685.html

Thanks very much for the pointer to that discussion. "ICMP implosion"
has been a helpful search term.

The position taken there appears to boil down to:
- The IPv6 requirement to generate "too big" messages *really is a problem*
- RFC2463 should not have made the exception which allows sending these messages
- Multicast PMTUD should not be a thing
- Multicast speakers should send un-fragmentable minimum-sized packets

I remain fuzzy on exactly the nature of the implosion problem. Is the
concern that I might DDoS myself by sending un-fragmentable traffic?

It's hard for me to recognize this as a problem, but I'm working on
it. It seems to me that as a multicast speaker, the influx of ICMP
errors is both desirable (I set DF because I intend to react) and
under my control.

It certainly beats sending minimum-sized packets, which appears to be
the recommendation in the linked discussion.

If somebody would be so kind as to detail the disastrous nature of the
implosion, that would be helpful.

From bill at herrin.us  Mon Aug 31 21:38:14 2015
From: bill at herrin.us (William Herrin)
Date: Mon, 31 Aug 2015 17:38:14 -0400
Subject: PMTUD for IPv4 Multicast - How?
In-Reply-To: <55E4C450.7070004@necom830.hpcl.titech.ac.jp>
References: <CAAG5dDCZdbYwnoQUuoaxSdevDTAkwyYGtpNfnVWUWWSZzGPMOg@mail.gmail.com>
 <7184.1441039021@turing-police.cc.vt.edu>
 <CAAG5dDD+oNOEK0b57j8EnVNrZ09oEHzFy9ruATyAzfeDs=furw@mail.gmail.com>
 <55E4C450.7070004@necom830.hpcl.titech.ac.jp>
Message-ID: <CAP-guGUPN2vDdFC1qwkD2FOBQKYjWWRd=07ywpkCz28h_GJ3Bw@mail.gmail.com>

On Mon, Aug 31, 2015 at 5:17 PM, Masataka Ohta
<mohta at necom830.hpcl.titech.ac.jp> wrote:
> for routers, generating ICMP PTB is as burdensome
> as generating fragments?

No, it isn't.

When a router fragments a packet, it has to fragment the next and the
next and the next. Maybe tens or hundreds of thousands of packets
before the end of that one user's session.

When a router generates a PTB, there is no next. PTB is a soft
failure. The origin must correct the error (by reducing packet size)
before communication can succeed.

There are potentially several orders of magnitude of difference in the
burden on the router.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>