From Sam at SanDiegoBroadband.com  Tue Mar  1 00:20:44 2016
From: Sam at SanDiegoBroadband.com (Sam Norris)
Date: Mon, 29 Feb 2016 16:20:44 -0800
Subject: MetroE and Telephone Taxes
Message-ID: <01b801d17350$3404c200$9c0e4600$@SanDiegoBroadband.com>

Hey all,

My provider here in SoCal is charging me 8% or so telephone taxes on our MetroE
products.  This seems fishy to me and I can't find any cut and dry rules about
private Ethernet / MetroE being under these rules.  The same provider selling
internet / DIA has no taxes whatsoever.

Anyone out there getting charged ULS and other telephone taxes on MetroE
circuits?  Or can anyone point me to somewhere that shows that it shouldn't be
charged telephone taxes?  Assume there are no voip calls traversing these
circuits.  I believe ULS is Federal, the other 3-5% is CA taxes on CLECs.

Thx,
Sam


From jared at puck.nether.net  Tue Mar  1 00:45:34 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 29 Feb 2016 19:45:34 -0500
Subject: MetroE and Telephone Taxes
In-Reply-To: <01b801d17350$3404c200$9c0e4600$@SanDiegoBroadband.com>
References: <01b801d17350$3404c200$9c0e4600$@SanDiegoBroadband.com>
Message-ID: <05BB5C00-8A8F-4A55-9AC6-225A10FFABB2@puck.nether.net>


> On Feb 29, 2016, at 7:20 PM, Sam Norris <Sam at SanDiegoBroadband.com> wrote:
> 
> Hey all,
> 
> My provider here in SoCal is charging me 8% or so telephone taxes on our MetroE
> products.  This seems fishy to me and I can't find any cut and dry rules about
> private Ethernet / MetroE being under these rules.  The same provider selling
> internet / DIA has no taxes whatsoever.
> 
> Anyone out there getting charged ULS and other telephone taxes on MetroE
> circuits?  Or can anyone point me to somewhere that shows that it shouldn't be
> charged telephone taxes?  Assume there are no voip calls traversing these
> circuits.  I believe ULS is Federal, the other 3-5% is CA taxes on CLECs.

First of all, you should be consulting with an accountant and/or lawyer.

Regarding internet service itself, the tax free status was recently made
permanent.

http://www.lexology.com/library/detail.aspx?g=d241fbfa-3f0a-4ecd-ae9a-7af255319062

The related bill:

https://www.govtrack.us/congress/bills/114/hr644

IANAL, and I?m not your accountant either.

- Jared


From blockedips at gmail.com  Tue Mar  1 01:20:31 2016
From: blockedips at gmail.com (Blocked IPs)
Date: Mon, 29 Feb 2016 17:20:31 -0800
Subject: AT&T blocking our IPs - need assistance
Message-ID: <CAAL7es9o0D-UEBb2JuBR3GJ=XN5vnbJyFot+a6JHuiDGD00c4A@mail.gmail.com>

The ISP I work for has a large block of IPs (randomly distributed) being
blocked by AT&T so that mutual customers cannot log into online portals
like att.net and directv.com. The common nodes of failure are
cprodmasx.att.net and cprodx.att.com.

We have had no luck getting through to higher tiers from customer-facing
phone representatives, nor have we had a response when leaving a voicemail
at 314-235-8168 (generic WHOIS registrant phone number, but recording
mentions "domain administrator"; please check your voicemail and response;
we just left another).

Please have an AT&T server administrator reply off-list in regards to
fixing this.

Thank you

From pavel.odintsov at gmail.com  Tue Mar  1 07:44:06 2016
From: pavel.odintsov at gmail.com (Pavel Odintsov)
Date: Tue, 1 Mar 2016 10:44:06 +0300
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <56D41A5C.70907@nvcube.net>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
Message-ID: <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>

Yep, Broadcom doing thing right way! :)

But unfortunately they (Cisco Nexus) are pretty expensive and fairly
new for DC and ISP market. It's pretty rare to find big company with
switching backbone on Nexus switches.

But I like this direction of switch silicom unification :) Focus moved
from "network brands" with Not Invented Here syndrome to enough smart
agnostic hardware vendors.

On Mon, Feb 29, 2016 at 1:15 PM, Nikolay Shopik <shopik+lists at nvcube.net> wrote:
> Cisco Nexus switches support sflow, since they are broadcom based.
>
> On 29/02/16 10:26, Pavel Odintsov wrote:
>> Cisco do not support this protocol at all (that's pretty weird,
>> really).



-- 
Sincerely yours, Pavel Odintsov

From meier-hahn at hiig.de  Tue Mar  1 13:19:19 2016
From: meier-hahn at hiig.de (Uta Meier-Hahn)
Date: Tue, 1 Mar 2016 14:19:19 +0100
Subject: New survey report published: The regulatory conditions of internet
 interconnection 
Message-ID: <47D59A73-E742-4970-BE36-DDE4C6F75323@hiig.de>

Hi,

A couple of months ago, I asked you to share your experiences with regards to public regulation of internet interconnection in a survey. Many networkers from around the globe participated. Thank you!

The report has now been published. I?m including the executive summary below. The full paper can be downloaded at <http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2740312>. Feel free to share this link wherever you see fit.

Thanks again for providing your highly valuable input. I will be happy to hear what you think about the results.

Best wishes,

Uta


# Exploring the regulatory conditions of internet interconnection

## Executive summary

Network interconnection is a central feature of the internet that has been subject to only little formal regulation. However, local public regulation is starting to emerge ? be it through disclosure regulations, mandatory peering or licensing terms. Due to the networked nature of the internet, local rules may acquire a global scope.

This report explores internet interconnection professionals? encounters with public regulation and it provides an initial overview about how this regulation affects internet connectivity. On the basis of a convenience sample of 163 survey submissions, the following has been found:

* Nine out of ten kinds of regulation presented to the participants have been encountered by more than half of them. This result gives reason to revisit the widespread notion that internet interconnection is an unregulated space. 66% of the participants have encountered a regulatory authority that imposes its own technical or operational standards. Moreover, imposition of regulatory standards was regarded to be the most influential on internet interconnection practices, together with competition laws (both 67%).

* Local regulation of internet interconnection creates a tension between the regulated and the unregulated space in the internet. In order to overcome the normative difference, network operators need to make an extra effort. The degree to which network operators are affected by local regulation depends on a networks? structure rather than on its size. Local regulation raises more difficulties for the kinds of infrastructural innovations that depend on having many points of presence.

* For networkers, public regulation of internet interconnection is relevant in three thematic domains: 1) in the economies of internet interconnection, 2) in engineering and operations, and 3) in the modes of governance.

* Overarching observations note that public regulation of internet interconnection contributes to a formalisation of the otherwise very informal sector. It also shines a spotlight on how networks are categorised and are thereby ?prepared? for the application of regulation. Further, various examples highlight how regulatory authorities co-opt internet infrastructure for new policy purposes that were previously not understood as central to internet operations, e.g., data retention.

* Local networkers value the presence of international network operators not only as potential peering partners but also as mediators for know-how about best practices and advanced modes of internet interconnection.

* Networkers are very critical about regulations that contradict engineering principles. The most accepted forms of regulation also apply in other societal spheres: basic rights for citizens, e.g., for broadband, and competition regulation.

?
Uta Meier-Hahn | Doctoral Researcher
Alexander von Humboldt Institute for Internet and Society
Franz?sische Stra?e 9 | 10117 Berlin
Phone +49 30 200 760-82 | http://www.hiig.de/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 671 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160301/f6db021b/attachment.pgp>

From mark.tinka at seacom.mu  Tue Mar  1 14:13:33 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 1 Mar 2016 16:13:33 +0200
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <56D41A5C.70907@nvcube.net>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
Message-ID: <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>



On 29/Feb/16 12:15, Nikolay Shopik wrote:

> Cisco Nexus switches support sflow, since they are broadcom based.

Not all of them, just the Nexus 9000, IIRC.

Mark.

From mark.tinka at seacom.mu  Tue Mar  1 14:24:12 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 1 Mar 2016 16:24:12 +0200
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
Message-ID: <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>



On 1/Mar/16 09:44, Pavel Odintsov wrote:
> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
> new for DC and ISP market. It's pretty rare to find big company with
> switching backbone on Nexus switches.

As opposed to?

We are looking at the Nexus 7700 for 100Gbps core switching.

Mark.

From pavel.odintsov at gmail.com  Tue Mar  1 14:33:55 2016
From: pavel.odintsov at gmail.com (Pavel Odintsov)
Date: Tue, 1 Mar 2016 17:33:55 +0300
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
 <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>
Message-ID: <CALgsdbeKFy81_-zu07S0rWfDyW0YssQrgOXi6NEmODKZEWg6qA@mail.gmail.com>

As opposed to older Cisco switches. Btw, 100GE is pretty new and
actually I have experience only with Extreme Black Diamond 8.

On Tue, Mar 1, 2016 at 5:24 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
>
> On 1/Mar/16 09:44, Pavel Odintsov wrote:
>> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
>> new for DC and ISP market. It's pretty rare to find big company with
>> switching backbone on Nexus switches.
>
> As opposed to?
>
> We are looking at the Nexus 7700 for 100Gbps core switching.
>
> Mark.



-- 
Sincerely yours, Pavel Odintsov

From davidbass570 at gmail.com  Tue Mar  1 14:37:13 2016
From: davidbass570 at gmail.com (David Bass)
Date: Tue, 1 Mar 2016 09:37:13 -0500
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
 <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>
Message-ID: <83FC98A1-B93F-462F-BE63-967DB9956EE5@gmail.com>

I don't agree with that statement (about rare to find big companies using Nexus).  If you want 10 gig/40 gig (or 100 gig soon) your options are Cisco Nexus/Arista/Juniper QFX...some periphery devices as well, but the majority use one of those 3. 

The merchant silicon based switches are pretty reasonably priced too. 



> On Mar 1, 2016, at 9:24 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
>> On 1/Mar/16 09:44, Pavel Odintsov wrote:
>> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
>> new for DC and ISP market. It's pretty rare to find big company with
>> switching backbone on Nexus switches.
> 
> As opposed to?
> 
> We are looking at the Nexus 7700 for 100Gbps core switching.
> 
> Mark.

From mark.tinka at seacom.mu  Tue Mar  1 14:38:01 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 1 Mar 2016 16:38:01 +0200
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <CALgsdbeKFy81_-zu07S0rWfDyW0YssQrgOXi6NEmODKZEWg6qA@mail.gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
 <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>
 <CALgsdbeKFy81_-zu07S0rWfDyW0YssQrgOXi6NEmODKZEWg6qA@mail.gmail.com>
Message-ID: <e35070c6-ecc2-f01d-cffe-9d265c5c25e2@seacom.mu>



On 1/Mar/16 16:33, Pavel Odintsov wrote:

> As opposed to older Cisco switches.

Well, every vendor has older switches.

>  Btw, 100GE is pretty new and
> actually I have experience only with Extreme Black Diamond 8.

Does not mean the Nexus is a bad choice for high capacity core
switching. Just means you know Extreme.

Mark.

From pavel.odintsov at gmail.com  Tue Mar  1 14:42:44 2016
From: pavel.odintsov at gmail.com (Pavel Odintsov)
Date: Tue, 1 Mar 2016 17:42:44 +0300
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <e35070c6-ecc2-f01d-cffe-9d265c5c25e2@seacom.mu>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
 <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>
 <CALgsdbeKFy81_-zu07S0rWfDyW0YssQrgOXi6NEmODKZEWg6qA@mail.gmail.com>
 <e35070c6-ecc2-f01d-cffe-9d265c5c25e2@seacom.mu>
Message-ID: <CALgsdbeqzYcGyx5jXPx=O1jC+BOFRDYTnxY9_YL94c=k-OBvmg@mail.gmail.com>

Yep, actually do not mean. I've never used Nexus and haven't any
experience with it :) I mentioned this in original message. I'm pretty
sure it's awesome switch. But as I haven't any experience I do not
known cons and pros about it.

On Tue, Mar 1, 2016 at 5:38 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
>
> On 1/Mar/16 16:33, Pavel Odintsov wrote:
>
>> As opposed to older Cisco switches.
>
> Well, every vendor has older switches.
>
>>  Btw, 100GE is pretty new and
>> actually I have experience only with Extreme Black Diamond 8.
>
> Does not mean the Nexus is a bad choice for high capacity core
> switching. Just means you know Extreme.
>
> Mark.



-- 
Sincerely yours, Pavel Odintsov

From josh at kyneticwifi.com  Tue Mar  1 14:43:12 2016
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Tue, 1 Mar 2016 08:43:12 -0600
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <83FC98A1-B93F-462F-BE63-967DB9956EE5@gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
 <16b44ec3-58e8-f014-f99f-434951ae6165@seacom.mu>
 <83FC98A1-B93F-462F-BE63-967DB9956EE5@gmail.com>
Message-ID: <CAC6=tfb0FZ45+1oO-yUGL6pjb_fmA+6ZHW_byyTptqvaJUPfTg@mail.gmail.com>

Brocade as well.
On Mar 1, 2016 8:39 AM, "David Bass" <davidbass570 at gmail.com> wrote:

> I don't agree with that statement (about rare to find big companies using
> Nexus).  If you want 10 gig/40 gig (or 100 gig soon) your options are Cisco
> Nexus/Arista/Juniper QFX...some periphery devices as well, but the majority
> use one of those 3.
>
> The merchant silicon based switches are pretty reasonably priced too.
>
>
>
> > On Mar 1, 2016, at 9:24 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> >
> >
> >
> >> On 1/Mar/16 09:44, Pavel Odintsov wrote:
> >> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
> >> new for DC and ISP market. It's pretty rare to find big company with
> >> switching backbone on Nexus switches.
> >
> > As opposed to?
> >
> > We are looking at the Nexus 7700 for 100Gbps core switching.
> >
> > Mark.
>

From shopik+lists at nvcube.net  Tue Mar  1 14:55:19 2016
From: shopik+lists at nvcube.net (Nikolay Shopik)
Date: Tue, 1 Mar 2016 17:55:19 +0300
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
Message-ID: <56D5AD57.9010802@nvcube.net>

On 01/03/16 17:13, Mark Tinka wrote:
> 
> 
> On 29/Feb/16 12:15, Nikolay Shopik wrote:
> 
>> Cisco Nexus switches support sflow, since they are broadcom based.
> 
> Not all of them, just the Nexus 9000, IIRC.
> 

Nexus 3000 also broadcom, but maybe not all models.

From shopik+lists at nvcube.net  Tue Mar  1 15:07:12 2016
From: shopik+lists at nvcube.net (Nikolay Shopik)
Date: Tue, 1 Mar 2016 18:07:12 +0300
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <CALgsdbdFbkD=mLoC4po846b=dQNGcOAh4bxFEw0Lb4mDkFiTSQ@mail.gmail.com>
Message-ID: <56D5B020.1090407@nvcube.net>

On 01/03/16 10:44, Pavel Odintsov wrote:
> But unfortunately they (Cisco Nexus) are pretty expensive and fairly
> new for DC and ISP market. It's pretty rare to find big company with
> switching backbone on Nexus switches.

You could go with withbox switches, which is based on same broadcom
ASIC, but this means you have to deal with new commercial NOS and learn
its quirks.

Or you could hack around with OpenSwitch and ask Broadcom to include you
favorite vendor/model into OpenNSL, so you could actually use ASIC w/o
siging NDA.

From peter.phaal at gmail.com  Tue Mar  1 15:18:38 2016
From: peter.phaal at gmail.com (Peter Phaal)
Date: Tue, 1 Mar 2016 07:18:38 -0800
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
Message-ID: <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>

On Tue, Mar 1, 2016 at 6:13 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
>
> On 29/Feb/16 12:15, Nikolay Shopik wrote:
>
>> Cisco Nexus switches support sflow, since they are broadcom based.
>
> Not all of them, just the Nexus 9000, IIRC.
>

The situation in the Cisco Nexus line is confusing. In addition, to
the Nexus 9000 series, the Nexus 3000 series and 3100 series are also
Broadcom based and also support sFlow. The Nexus 3500 series and 6000
series use Cisco ASICs and don't have sFlow or NetFlow support.

It also appears that Cisco's merchant silicon based switches have a
greater variety of orchestration capabilities, Python, NX-API,
Ansible, etc.

From jra at baylink.com  Tue Mar  1 17:16:50 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 1 Mar 2016 17:16:50 +0000 (UTC)
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
Message-ID: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com>

Just got this dropped on my desk an hour ago, and I'm not finding as much
material online as I might have hoped for...

It looks like the easiest solution is to just hang a router/firewall at
Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP and
MPLS; is there a "native" way to do that from an AWS VPC instead?

Any public or private replies cheerfully accepted; will summarize what I
can to the list.

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 george.herbert at gmail.com  Tue Mar  1 19:25:59 2016
From: george.herbert at gmail.com (George Herbert)
Date: Tue, 1 Mar 2016 11:25:59 -0800
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com>
References: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com>
Message-ID: <5D7F5752-8F41-4E7D-B65F-84EC833121A9@gmail.com>


If you're asking if one can get a provider's router to handle the outside physical part of a DC connection... As an ISP service so you don't need your own router hardware...

I was working on this for a recent ex client and asked Level 3 exactly that question.  I believe I had the right network guy on the phone and it was a firm no.

I was going to check all the other Direct Connect providers but client ran out of $$.

If anyone does do that, I would like to know and pass it along to ex client for their information.


George William Herbert
Sent from my iPhone

> On Mar 1, 2016, at 9:16 AM, "Jay R. Ashworth" <jra at baylink.com> wrote:
> 
> Just got this dropped on my desk an hour ago, and I'm not finding as much
> material online as I might have hoped for...
> 
> It looks like the easiest solution is to just hang a router/firewall at
> Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP and
> MPLS; is there a "native" way to do that from an AWS VPC instead?
> 
> Any public or private replies cheerfully accepted; will summarize what I
> can to the list.
> 
> 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 Jason_Livingood at comcast.com  Tue Mar  1 19:27:55 2016
From: Jason_Livingood at comcast.com (Livingood, Jason)
Date: Tue, 1 Mar 2016 19:27:55 +0000
Subject: Thank you, Comcast. (aka patch your D-Link gear)
Message-ID: <D2FB4816.12A177%jason_livingood@cable.comcast.com>

As a followup to this issue, and looking specifically at SSDP abuse (not the DNS amplification noted in the 1st email), one point of commonality we have identified in many customers is a D-Link device (range of different models). If you or someone you know uses a D-Link device, please see this page as you may need to upgrade your firmware: http://support.dlink.ca/FAQView.aspx?f=sY5vcvfAuAV6bXgi%2F8WoVw%3D%3D

As noted last week we're continuing to examine whether / how / when to update our blocked port list.

Jason / Comcast


From lnguyen at opsource.net  Tue Mar  1 19:37:07 2016
From: lnguyen at opsource.net (Luan Nguyen)
Date: Tue, 1 Mar 2016 14:37:07 -0500
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <5D7F5752-8F41-4E7D-B65F-84EC833121A9@gmail.com>
References: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com><5D7F5752-8F41-4E7D-B65F-84EC833121A9@gmail.com>
Message-ID: <CADR+d4ahJQ=t7TZ-f-MCOk9=4f1nwNm2Z-fFxjphZn4T__TR4Q@mail.gmail.com>

Not sure about AWS, but if you are a client of Dimension Data cloud, you
don't need to do anything. Everything will be taking care off from the
provider perspective. Didata will peer with your tier 1/MPLS - acts as
CPE...etc  I am pretty sure AWS does that for you as well.
Else you could spin up a CSR1000v inside the AWS and ask them to connect
you.

On Tue, Mar 1, 2016 at 2:25 PM, George Herbert <george.herbert at gmail.com>
wrote:

>
> If you're asking if one can get a provider's router to handle the outside
> physical part of a DC connection... As an ISP service so you don't need
> your own router hardware...
>
> I was working on this for a recent ex client and asked Level 3 exactly
> that question.  I believe I had the right network guy on the phone and it
> was a firm no.
>
> I was going to check all the other Direct Connect providers but client ran
> out of $$.
>
> If anyone does do that, I would like to know and pass it along to ex
> client for their information.
>
>
> George William Herbert
> Sent from my iPhone
>
> > On Mar 1, 2016, at 9:16 AM, "Jay R. Ashworth" <jra at baylink.com> wrote:
> >
> > Just got this dropped on my desk an hour ago, and I'm not finding as much
> > material online as I might have hoped for...
> >
> > It looks like the easiest solution is to just hang a router/firewall at
> > Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP
> and
> > MPLS; is there a "native" way to do that from an AWS VPC instead?
> >
> > Any public or private replies cheerfully accepted; will summarize what I
> > can to the list.
> >
> > 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 moc at es.net  Tue Mar  1 20:41:35 2016
From: moc at es.net (Michael O'Connor)
Date: Tue, 1 Mar 2016 15:41:35 -0500
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com>
References: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com>
Message-ID: <CAM5sgfzTpQZ-2+F11HH9ew1XmyrHMCZ_p=QES2YPsJQ-3EDT6g@mail.gmail.com>

Jay,

VPC is supported over IPsec if your public path is sufficient into the AWS
cloud.

AWS shortens DirectConnect to DX not DC for some reason.

The AWS DirectConnect service is built on 10G infrastructure so using
potentially larger interconnects over public peerings with IPsec could be
advantageous.

DX requires fiber cross connects in addition to any other AWS peerings that
you may have at a particular location.

-Mike O'Connor


On Tue, Mar 1, 2016 at 12:16 PM, Jay R. Ashworth <jra at baylink.com> wrote:

> Just got this dropped on my desk an hour ago, and I'm not finding as much
> material online as I might have hoped for...
>
> It looks like the easiest solution is to just hang a router/firewall at
> Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP
> and
> MPLS; is there a "native" way to do that from an AWS VPC instead?
>
> Any public or private replies cheerfully accepted; will summarize what I
> can to the list.
>
> 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
>



-- 
Michael O'Connor
ESnet Network Engineering
moc at es.net
631 344-7410

From surfer at mauigateway.com  Tue Mar  1 22:09:49 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 1 Mar 2016 14:09:49 -0800
Subject: Thank you, Comcast. (aka patch your D-Link gear)
Message-ID: <20160301140949.E730207@m0087795.ppops.net>



--- Jason_Livingood at comcast.com wrote:

As noted last week we're ...
--------------------------------------------

Thank you for sharing this and all the other stuff over 
the years with the NANOG community.

scott

From paras at protrafsolutions.com  Tue Mar  1 22:32:44 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Tue, 1 Mar 2016 17:32:44 -0500
Subject: Any large IPv4 space brokers?
Message-ID: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>

Does anyone know of any IP space brokers other than Hilco Streambank? I'm
looking to get a feel for the market a little bit.

Regards
Paras

From alessandro.martins at gmail.com  Tue Mar  1 22:50:07 2016
From: alessandro.martins at gmail.com (Alessandro Martins)
Date: Tue, 1 Mar 2016 19:50:07 -0300
Subject: mrtg alternative
In-Reply-To: <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
Message-ID: <CAEiqDEaz511kvq1UdyMdt7hnzXcA=rH4Gy87N7yM2H8EgLsNUQ@mail.gmail.com>

Hey,

LibreNMS is an opensource Observium's fork with some extra addons...

Take a look: http://www.librenms.org

-- 
Alessandro Martins
On Feb 27, 2016 20:37, "Peter Loron" <peterl at standingwave.org> wrote:

> We?re using Observium for trend collecting, graphing, and alerting.
>
> -Pete
>
>
>
>
> On 2/27/16, 13:12, "NANOG on behalf of Rafael Ganascim" <
> nanog-bounces at nanog.org on behalf of rganascim at gmail.com> wrote:
>
> >I like cacti:
> >
> >http://www.cacti.net
> >
> >
> >
> >2016-02-26 20:18 GMT-03:00 Baldur Norddahl <baldur.norddahl at gmail.com>:
> >
> >> Hi
> >>
> >> I am currently using MRTG and RRD to make traffic graphs. I am searching
> >> for more modern alternatives that allows the user to dynamically zoom
> and
> >> scroll the timeline.
> >>
> >> Bonus points if the user can customize the graphs directly in the
> >> webbrowse. For example he might be able to add or remove individual
> peers
> >> from the graph by simply clicking a checkbox.
> >>
> >> What is the 2016 tool for this?
> >>
> >> Regards,
> >>
> >> Baldur
> >>
> >
>
>

From jeffg at opennms.org  Tue Mar  1 23:08:25 2016
From: jeffg at opennms.org (Jeff Gehlbach)
Date: Tue, 01 Mar 2016 18:08:25 -0500
Subject: mrtg alternative
In-Reply-To: <CAEiqDEaz511kvq1UdyMdt7hnzXcA=rH4Gy87N7yM2H8EgLsNUQ@mail.gmail.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <CAEiqDEaz511kvq1UdyMdt7hnzXcA=rH4Gy87N7yM2H8EgLsNUQ@mail.gmail.com>
Message-ID: <EA7C1767-692B-45DB-A873-A51AB7A5DF3F@opennms.org>

Similar in name but more comprehensive in scope, OpenNMS may also be worth a look. Disclosure: I work for the project's primary maintainer.

On March 1, 2016 5:50:07 PM EST, Alessandro Martins <alessandro.martins at gmail.com> wrote:
>Hey,
>
>LibreNMS is an opensource Observium's fork with some extra addons...
>
>Take a look: http://www.librenms.org
>
>-- 
>Alessandro Martins
>On Feb 27, 2016 20:37, "Peter Loron" <peterl at standingwave.org> wrote:
>
>> We?re using Observium for trend collecting, graphing, and alerting.
>>
>> -Pete
>>
>>
>>
>>
>> On 2/27/16, 13:12, "NANOG on behalf of Rafael Ganascim" <
>> nanog-bounces at nanog.org on behalf of rganascim at gmail.com> wrote:
>>
>> >I like cacti:
>> >
>> >http://www.cacti.net
>> >
>> >
>> >
>> >2016-02-26 20:18 GMT-03:00 Baldur Norddahl
><baldur.norddahl at gmail.com>:
>> >
>> >> Hi
>> >>
>> >> I am currently using MRTG and RRD to make traffic graphs. I am
>searching
>> >> for more modern alternatives that allows the user to dynamically
>zoom
>> and
>> >> scroll the timeline.
>> >>
>> >> Bonus points if the user can customize the graphs directly in the
>> >> webbrowse. For example he might be able to add or remove
>individual
>> peers
>> >> from the graph by simply clicking a checkbox.
>> >>
>> >> What is the 2016 tool for this?
>> >>
>> >> Regards,
>> >>
>> >> Baldur
>> >>
>> >
>>
>>


-jeff

From owen at delong.com  Tue Mar  1 23:47:56 2016
From: owen at delong.com (Owen DeLong)
Date: Tue, 1 Mar 2016 15:47:56 -0800
Subject: About inetnum "ownership"
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C9C011E0@MUNPRDMBXA1.medline.com>
References: <56CADCDB.2000905@ceriz.fr>
 <52D06627-A948-4145-9C39-19E1266DEFC4@matthew.at>
 <9578293AE169674F9A048B2BC9A081B401C9C011E0@MUNPRDMBXA1.medline.com>
Message-ID: <21868565-1258-43AC-BF8C-E43FC63F9024@delong.com>


> On Feb 22, 2016, at 08:50 , Naslund, Steve <SNaslund at medline.com> wrote:
> 
> Oh, and I forgot to add...the number in and of itself does not have a value.  The right to use that number within the Internet connected network is what has value.


But that?s not what RIRs give you.

RIRs have no control over your right to use the number within the context of any network.

RIRs merely provide a record of unique registrations among cooperating registries.

Most network operators currently use this database as a basis for granting permissions to use the numbers within their network contexts, but any network operator that wants to is free to assign any number they wish to any purpose or entity they so choose. Your network, your rules.

Turns out, that since most network operators follow the RIR database, it?s hard to find peers that will accept your announcement of ?off-list? usage of addresses, but that?s not an inherent right conveyed in the registration of an address within the RIR system.

Owen

> 
> Steven Naslund
> Chicago IL
> 
> 
> Simple to answer.  
> 
> 1. Address space is finite in size, therefore in the V4 space more people want addresses than there is available space.  Hence it has value because demand exceeds supply.
> 
> 2.  Managing address space allocations is not a zero cost effort, therefore the RIRs charge a price for that.  Anything that costs money to acquire presumably has value.
> 
> Steven Naslund
> Chicago IL
> 
>> On Feb 22, 2016, at 2:03 AM, J?r?me Nicolle <jerome at ceriz.fr> wrote:
>> 
>> Hi,
>> 
>> How come we've had an inetnum market in place whereas an inetnum 
>> cannot have a market value ?
>> 
>> It's my understanding that the IP adress space is nothing but numbers 
>> and that RIR/LIRs are only responsible for the uniqueness of 
>> allocations and assignements, that is, a transfer of liability over a 
>> shared and common immaterial resource, between community members.
>> 
>> I'm wondering how did we made "Temporary and conditionnal liabality 
>> transfer" a synonym of "perpetual and inconditional usufruct transfer".
>> 
>> May you please enlight me ?
>> 
>> Thanks !
>> 
>> --
>> J?r?me Nicolle
>> +33 6 19 31 27 14


From owen at delong.com  Tue Mar  1 23:55:35 2016
From: owen at delong.com (Owen DeLong)
Date: Tue, 1 Mar 2016 15:55:35 -0800
Subject: About inetnum "ownership"
In-Reply-To: <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
Message-ID: <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>


> On Feb 22, 2016, at 08:57 , William Herrin <bill at herrin.us> wrote:
> 
> On Mon, Feb 22, 2016 at 5:03 AM, J?r?me Nicolle <jerome at ceriz.fr> wrote:
>> It's my understanding that the IP adress space is nothing but numbers
>> and that RIR/LIRs are only responsible for the uniqueness of allocations
>> and assignements, that is, a transfer of liability over a shared and
>> common immaterial resource, between community members.
> 
> Hi J?r?me,
> 
> The short version is this:
> 
> IP addresses are property. A few people get really bent out of shape
> if you say that IP addresses are property. And while extant, the legal
> precedent for IP addresses as property isn't as strong as might be
> nice. So, we mostly pay lip service to the folks who still want to
> claim that IP addresses are just integers even as we treat IP
> addresses like property.

I would argue that it is the other way around.

Unique registrations in the RIR databases may well be property.

IP addresses are so abstract and ephemeral in their nature as to be impossible to treat as property other than by creating some sort of statutory system requiring all network operators to obey a certain set of cooperating registries for said numbers and then using those unique registrations mentioned above to convey property rights in the operational deployment of the ephemeral numbers referenced.

Ownership of the rights to control (convey, modify, update) a registration record are tangible and can be property.

The control over how a network operator interprets, deploys, uses, or otherwise manipulates a particular integer or packets containing a particular integer in a particular field of the packet is not actually subject to any sort of enforceable property rights.

For example, if you have gotten a registration for A.B.C.0/24 from an RIR and you then purchase internet access from $PROVIDER_A, you have nothing which will force $PROVIDER_A to convey all packets to A.B.C.0/24 to your network unless that?s what you add to your contract. 

Further, if some other customer of $PROVIDER_B convinces them to treat A.B.C.0/24 differently within $PROVIDER_B?s network, there?s no law which prohibits that and no way for you to enforce any sort of restraint on their choice to do so.

You might? _MIGHT_ have a case for tortious interference if $PROVIDER_B advertises A.B.C.0/24 to some other provider in a way that negatively impacts your network, but to the best of my knowledge, even that is relatively untested.

So far, resolving any such conflicts has depended almost entirely on the fact that ISPs generally cooperate with the RIR system and treat it as an authoritative list for granting permission to use addresses in their networks.

If ISPs start opting out of that particular choice, life gets much more interesting, but I don?t think there?s any sort of ownership conveyed in an RIR registration that allows you to prevent an ISP that you aren?t in a contract with from doing so.

Owen


From jlewis at lewis.org  Wed Mar  2 00:48:16 2016
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 1 Mar 2016 19:48:16 -0500 (EST)
Subject: Any large IPv4 space brokers?
In-Reply-To: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>
References: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1603011947330.6833@soloth.lewis.org>

On Tue, 1 Mar 2016, Paras Jha wrote:

> Does anyone know of any IP space brokers other than Hilco Streambank? I'm
> looking to get a feel for the market a little bit.

Addrex.net

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

From jim at reptiles.org  Wed Mar  2 00:54:56 2016
From: jim at reptiles.org (Jim Mercer)
Date: Tue, 1 Mar 2016 19:54:56 -0500
Subject: Any large IPv4 space brokers?
In-Reply-To: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>
References: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>
Message-ID: <20160302005456.GA20683@reptiles.org>

On Tue, Mar 01, 2016 at 05:32:44PM -0500, Paras Jha wrote:
> Does anyone know of any IP space brokers other than Hilco Streambank? I'm
> looking to get a feel for the market a little bit.

register with the ARIN STLS, there are some blocks available there too.

--jim

-- 
Jim Mercer     Reptilian Research      jim at reptiles.org    +1 416 410-5633

Life should not be a journey to the grave with the intention of
arriving safely in a pretty and well preserved body, but rather
to skid in broadside in a cloud of smoke, thoroughly used up,
totally worn out, and loudly proclaiming "Wow! What a Ride!"
 -- Hunter S. Thompson

From nanog at ics-il.net  Wed Mar  2 00:59:12 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 1 Mar 2016 18:59:12 -0600 (CST)
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <CAM5sgfzTpQZ-2+F11HH9ew1XmyrHMCZ_p=QES2YPsJQ-3EDT6g@mail.gmail.com>
Message-ID: <175516751.4111.1456880351551.JavaMail.mhammett@ThunderFuck>

I haven't heard it from the horse's mouth, but I heard that the only way to have customers share an AWS DX (apparently) cross connect is through Equinix's cloud exchange service. Can anyone confirm that? It doesn't seem right that I could transport people to AWS all day long if they buy their own cross connect, but once we share, I have to go through someone offering a competitive service. 




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

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

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

From: "Michael O'Connor" <moc at es.net> 
To: "Jay R. Ashworth" <jra at baylink.com> 
Cc: "North American Network Operators' Group" <nanog at nanog.org> 
Sent: Tuesday, March 1, 2016 2:41:35 PM 
Subject: Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS 

Jay, 

VPC is supported over IPsec if your public path is sufficient into the AWS 
cloud. 

AWS shortens DirectConnect to DX not DC for some reason. 

The AWS DirectConnect service is built on 10G infrastructure so using 
potentially larger interconnects over public peerings with IPsec could be 
advantageous. 

DX requires fiber cross connects in addition to any other AWS peerings that 
you may have at a particular location. 

-Mike O'Connor 


On Tue, Mar 1, 2016 at 12:16 PM, Jay R. Ashworth <jra at baylink.com> wrote: 

> Just got this dropped on my desk an hour ago, and I'm not finding as much 
> material online as I might have hoped for... 
> 
> It looks like the easiest solution is to just hang a router/firewall at 
> Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP 
> and 
> MPLS; is there a "native" way to do that from an AWS VPC instead? 
> 
> Any public or private replies cheerfully accepted; will summarize what I 
> can to the list. 
> 
> 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 
> 



-- 
Michael O'Connor 
ESnet Network Engineering 
moc at es.net 
631 344-7410 


From craetdave at gmail.com  Wed Mar  2 01:28:34 2016
From: craetdave at gmail.com (Dave Cohen)
Date: Tue, 1 Mar 2016 20:28:34 -0500
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <175516751.4111.1456880351551.JavaMail.mhammett@ThunderFuck>
References: <CAM5sgfzTpQZ-2+F11HH9ew1XmyrHMCZ_p=QES2YPsJQ-3EDT6g@mail.gmail.com>
 <175516751.4111.1456880351551.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAAsXY1TQW+vL8FMapUTW-bma-PANYsKkkTZB_7O25hfFUSJLbw@mail.gmail.com>

I can confirm that AWS (and Equinix, by extension, from a facility operator
perspective) permit carriers to have multiple end users share a physical
interface into the AWS gateway. The key is whether the providers that are
permitted into the DX environment (I believe AWS has limited the list to
only 7 or 8 in total - anyone else is reselling capacity off of those
carriers) are willing to deal with the constraints of that configuration -
essentially that the carrier needs to take responsibility of engaging
directly with AWS to associate the EVC on the provider interface with the
VPC on the AWS interface. I can confirm that at least one provider other
than Equinix will do this. Point being, it's not an AWS restriction as much
as whether the provider is willing to get its hands a bit dirtier. My $.02
at least.

- Dave

On Tue, Mar 1, 2016 at 7:59 PM, Mike Hammett <nanog at ics-il.net> wrote:

> I haven't heard it from the horse's mouth, but I heard that the only way
> to have customers share an AWS DX (apparently) cross connect is through
> Equinix's cloud exchange service. Can anyone confirm that? It doesn't seem
> right that I could transport people to AWS all day long if they buy their
> own cross connect, but once we share, I have to go through someone offering
> a competitive service.
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ----- Original Message -----
>
> From: "Michael O'Connor" <moc at es.net>
> To: "Jay R. Ashworth" <jra at baylink.com>
> Cc: "North American Network Operators' Group" <nanog at nanog.org>
> Sent: Tuesday, March 1, 2016 2:41:35 PM
> Subject: Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
>
> Jay,
>
> VPC is supported over IPsec if your public path is sufficient into the AWS
> cloud.
>
> AWS shortens DirectConnect to DX not DC for some reason.
>
> The AWS DirectConnect service is built on 10G infrastructure so using
> potentially larger interconnects over public peerings with IPsec could be
> advantageous.
>
> DX requires fiber cross connects in addition to any other AWS peerings that
> you may have at a particular location.
>
> -Mike O'Connor
>
>
> On Tue, Mar 1, 2016 at 12:16 PM, Jay R. Ashworth <jra at baylink.com> wrote:
>
> > Just got this dropped on my desk an hour ago, and I'm not finding as much
> > material online as I might have hoped for...
> >
> > It looks like the easiest solution is to just hang a router/firewall at
> > Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP
> > and
> > MPLS; is there a "native" way to do that from an AWS VPC instead?
> >
> > Any public or private replies cheerfully accepted; will summarize what I
> > can to the list.
> >
> > 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
> >
>
>
>
> --
> Michael O'Connor
> ESnet Network Engineering
> moc at es.net
> 631 344-7410
>
>


-- 
- Dave Cohen
eM: craetdave at gmail.com
AIM: dCo says

From nanog at ics-il.net  Wed Mar  2 02:46:11 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Tue, 1 Mar 2016 20:46:11 -0600 (CST)
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <CAAsXY1TQW+vL8FMapUTW-bma-PANYsKkkTZB_7O25hfFUSJLbw@mail.gmail.com>
Message-ID: <1899282418.4214.1456886766200.JavaMail.mhammett@ThunderFuck>

If anyone has connections at Amazon in those areas, could you pass them my way? My IP peering contact (MMC) seems to have fallen off the face of the earth and I'm not sure that's his jurisdiction anyway. Their web site seems largely useless so far, catering more to the consultant and software dev guys than the infrastructure\transport guys. 




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

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

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

From: "Dave Cohen" <craetdave at gmail.com> 
To: "Mike Hammett" <nanog at ics-il.net> 
Cc: "North American Network Operators' Group" <nanog at nanog.org> 
Sent: Tuesday, March 1, 2016 7:28:34 PM 
Subject: Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS 


I can confirm that AWS (and Equinix, by extension, from a facility operator perspective) permit carriers to have multiple end users share a physical interface into the AWS gateway. The key is whether the providers that are permitted into the DX environment (I believe AWS has limited the list to only 7 or 8 in total - anyone else is reselling capacity off of those carriers) are willing to deal with the constraints of that configuration - essentially that the carrier needs to take responsibility of engaging directly with AWS to associate the EVC on the provider interface with the VPC on the AWS interface. I can confirm that at least one provider other than Equinix will do this. Point being, it's not an AWS restriction as much as whether the provider is willing to get its hands a bit dirtier. My $.02 at least. 


- Dave 


On Tue, Mar 1, 2016 at 7:59 PM, Mike Hammett < nanog at ics-il.net > wrote: 


I haven't heard it from the horse's mouth, but I heard that the only way to have customers share an AWS DX (apparently) cross connect is through Equinix's cloud exchange service. Can anyone confirm that? It doesn't seem right that I could transport people to AWS all day long if they buy their own cross connect, but once we share, I have to go through someone offering a competitive service. 




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

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

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

From: "Michael O'Connor" < moc at es.net > 
To: "Jay R. Ashworth" < jra at baylink.com > 
Cc: "North American Network Operators' Group" < nanog at nanog.org > 
Sent: Tuesday, March 1, 2016 2:41:35 PM 
Subject: Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS 

Jay, 

VPC is supported over IPsec if your public path is sufficient into the AWS 
cloud. 

AWS shortens DirectConnect to DX not DC for some reason. 

The AWS DirectConnect service is built on 10G infrastructure so using 
potentially larger interconnects over public peerings with IPsec could be 
advantageous. 

DX requires fiber cross connects in addition to any other AWS peerings that 
you may have at a particular location. 

-Mike O'Connor 


On Tue, Mar 1, 2016 at 12:16 PM, Jay R. Ashworth < jra at baylink.com > wrote: 

> Just got this dropped on my desk an hour ago, and I'm not finding as much 
> material online as I might have hoped for... 
> 
> It looks like the easiest solution is to just hang a router/firewall at 
> Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP 
> and 
> MPLS; is there a "native" way to do that from an AWS VPC instead? 
> 
> Any public or private replies cheerfully accepted; will summarize what I 
> can to the list. 
> 
> 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 
> 



-- 
Michael O'Connor 
ESnet Network Engineering 
moc at es.net 
631 344-7410 







-- 

- Dave Cohen 
eM: craetdave at gmail.com 
AIM: dCo says 

From bill at herrin.us  Wed Mar  2 05:44:36 2016
From: bill at herrin.us (William Herrin)
Date: Wed, 2 Mar 2016 00:44:36 -0500
Subject: About inetnum "ownership"
In-Reply-To: <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
Message-ID: <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>

On Tue, Mar 1, 2016 at 6:55 PM, Owen DeLong <owen at delong.com> wrote:
> Unique registrations in the RIR databases may well be property.

Hi Owen,

Registration records property. Registrations are not the property recorded.

The U.S. Supreme Court talks about property this way: "The right to
exclude others [is] one of the most essential sticks in the bundle of
rights that are commonly characterized as property." (Kaiser Aetna v.
United States)

Do I have the legal right to exclude others from announcing my block
of IP addresses to the public Internet routing tables? It's not well
tested in court but the odds are exceptionally strong that I do.
Indeed, the whole point of registration is to facilitate determination
of -who- has the exclusive right over -which- blocks of addresses.

The right to exclude is not the only one in the bundle of rights that
is property but it is the primary and it is argued sufficient
condition of property.
http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1492&context=nlr

Which brings us back around to what I said earlier: IP addresses are
property but the legal precedent isn't as strong as might be nice.


> IP addresses are so abstract and ephemeral in their nature
> as to be impossible to treat as property

Computers don't do abstraction. There's nothing abstract or
particularly ephemeral about the use of IP addresses on the public
Internet.

Regards,
Bill Herrin


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

From mark.tinka at seacom.mu  Wed Mar  2 06:04:02 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 2 Mar 2016 08:04:02 +0200
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
Message-ID: <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>



On 1/Mar/16 17:18, Peter Phaal wrote:

> It also appears that Cisco's merchant silicon based switches have a
> greater variety of orchestration capabilities, Python, NX-API,
> Ansible, etc.

We were initially looking at at the Nexus 9000, but then moved to the
7700 because the Broadcom chip on the 7700 cannot do single flows larger
than 40Gbps on the 100Gbps ports.

As a general note, I'm having to avoid merchant silicon
left-right-and-centre. Every time I try to give them a chance, they
don't cut the mustard. When the next chip solves the last issue, I
discover it can't support another feature. The cycle repeats.

Mark.

From mark.tinka at seacom.mu  Wed Mar  2 06:12:39 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 2 Mar 2016 08:12:39 +0200
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
Message-ID: <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>



On 2/Mar/16 08:04, Mark Tinka wrote:

> We were initially looking at at the Nexus 9000, but then moved to the
> 7700 because the Broadcom chip on the 7700 cannot do single flows larger
> than 40Gbps on the 100Gbps ports.

The Broadcom chip on the 9000, I meant...

Mark.

From kauer at biplane.com.au  Wed Mar  2 06:12:38 2016
From: kauer at biplane.com.au (Karl Auer)
Date: Wed, 02 Mar 2016 17:12:38 +1100
Subject: About inetnum "ownership"
In-Reply-To: <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
Message-ID: <1456899158.11868.58.camel@biplane.com.au>

On Wed, 2016-03-02 at 00:44 -0500, William Herrin wrote:
> Do I have the legal right to exclude others from announcing my block
> of IP addresses to the public Internet routing tables? It's not well
> tested in court but the odds are exceptionally strong that I do.

If I own some property - say a field - the location of that field is
with certain rare exceptions public information. I as the owner cannot
enforce a requirement on you to NOT tell people where my field is. I
can't demand that you NOT build roads past it, or that you NOT put up
signs saying how to get to my field, or even that you NOT tell people
who owns the field. I have the right to exclusive use of the property,
but I have no rights to information about the property, nor any
property rights outside the boundary of the property.

Testing in court the idea that you may not advertise my routes would be
a fascinating exercise. If you falsely advertised them it would be a
different matter.

Has this sort of thing been tested in the courts at all? In any
jurisdiction?

> Indeed, the whole point of registration is to facilitate
> determination
> of -who- has the exclusive right over -which- blocks of addresses.

The problem is what rights we are talking about. I would say that
practically speaking the only real right here is the right to configure
an address on an interface. But anyone else can send packets to an
address, or advertise to others the direction of travel towards that
network. Malicious activity excluded of course - DoS attacks and so on,
but I think the issues there are different. Also, contractually
regulated relationships are different - if I connect something up to
ISPX and have a contract with ISPX to NOT advertise the route to me,
then ISPX is constrained.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4




From mr.jonas.bjork at me.com  Wed Mar  2 07:34:38 2016
From: mr.jonas.bjork at me.com (Jonas Bjork)
Date: Wed, 02 Mar 2016 08:34:38 +0100
Subject: Any large IPv4 space brokers?
In-Reply-To: <20160302005456.GA20683@reptiles.org>
References: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>
 <20160302005456.GA20683@reptiles.org>
Message-ID: <D593E3C0-E8DD-437B-BBE9-39ED421CD11F@me.com>

Hi, these sites sell PA network space, I assume? Where may I buy PI nets?

Best regards,
Jonas

Sent from my iPad

> On 02 Mar 2016, at 01:54, Jim Mercer <jim at reptiles.org> wrote:
> 
>> On Tue, Mar 01, 2016 at 05:32:44PM -0500, Paras Jha wrote:
>> Does anyone know of any IP space brokers other than Hilco Streambank? I'm
>> looking to get a feel for the market a little bit.
> 
> register with the ARIN STLS, there are some blocks available there too.
> 
> --jim
> 
> -- 
> Jim Mercer     Reptilian Research      jim at reptiles.org    +1 416 410-5633
> 
> Life should not be a journey to the grave with the intention of
> arriving safely in a pretty and well preserved body, but rather
> to skid in broadside in a cloud of smoke, thoroughly used up,
> totally worn out, and loudly proclaiming "Wow! What a Ride!"
> -- Hunter S. Thompson

From mr.jonas.bjork at me.com  Wed Mar  2 07:46:43 2016
From: mr.jonas.bjork at me.com (Jonas Bjork)
Date: Wed, 02 Mar 2016 08:46:43 +0100
Subject: About inetnum "ownership"
In-Reply-To: <1456899158.11868.58.camel@biplane.com.au>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
Message-ID: <769B3C27-F7D1-4FDF-B99E-3B966F83C568@me.com>

Hi,
shouldn't the same logic of ownership of DNS domain names apply to inetnum address space?

Best regards,
Jonas

Sent from my iPad

> On 02 Mar 2016, at 07:12, Karl Auer <kauer at biplane.com.au> wrote:
> 
>> On Wed, 2016-03-02 at 00:44 -0500, William Herrin wrote:
>> Do I have the legal right to exclude others from announcing my block
>> of IP addresses to the public Internet routing tables? It's not well
>> tested in court but the odds are exceptionally strong that I do.
> 
> If I own some property - say a field - the location of that field is
> with certain rare exceptions public information. I as the owner cannot
> enforce a requirement on you to NOT tell people where my field is. I
> can't demand that you NOT build roads past it, or that you NOT put up
> signs saying how to get to my field, or even that you NOT tell people
> who owns the field. I have the right to exclusive use of the property,
> but I have no rights to information about the property, nor any
> property rights outside the boundary of the property.
> 
> Testing in court the idea that you may not advertise my routes would be
> a fascinating exercise. If you falsely advertised them it would be a
> different matter.
> 
> Has this sort of thing been tested in the courts at all? In any
> jurisdiction?
> 
>> Indeed, the whole point of registration is to facilitate
>> determination
>> of -who- has the exclusive right over -which- blocks of addresses.
> 
> The problem is what rights we are talking about. I would say that
> practically speaking the only real right here is the right to configure
> an address on an interface. But anyone else can send packets to an
> address, or advertise to others the direction of travel towards that
> network. Malicious activity excluded of course - DoS attacks and so on,
> but I think the issues there are different. Also, contractually
> regulated relationships are different - if I connect something up to
> ISPX and have a contract with ISPX to NOT advertise the route to me,
> then ISPX is constrained.
> 
> Regards, K.
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
> 
> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
> 
> 
> 

From bevan at slattery.net.au  Wed Mar  2 09:13:48 2016
From: bevan at slattery.net.au (Bevan Slattery)
Date: Wed, 2 Mar 2016 17:13:48 +0800
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <CAAsXY1TQW+vL8FMapUTW-bma-PANYsKkkTZB_7O25hfFUSJLbw@mail.gmail.com>
References: <CAM5sgfzTpQZ-2+F11HH9ew1XmyrHMCZ_p=QES2YPsJQ-3EDT6g@mail.gmail.com>
 <175516751.4111.1456880351551.JavaMail.mhammett@ThunderFuck>
 <CAAsXY1TQW+vL8FMapUTW-bma-PANYsKkkTZB_7O25hfFUSJLbw@mail.gmail.com>
Message-ID: <5EED4E73-A97F-4E44-93C1-B9E13ABFE04F@slattery.net.au>

***disclaimer - info on subject from a shareholder*** :)

Yeah.  In addition to Equinix and a few others  Megaport is expanding pretty quickly in US at present.  30+ locations 7 US markets.  Worth a look if you are trying to get your Azure and AWS fix from a single provider via 100% SDN, API driven platform (also and other services such as AMS-IX peering).  Interesting differences such as a flat rate Virtual X-Connect regardless of speed and where the other end of the circuit is in the metro.  Day/month/year from 1mbps to 10gbps.  Been doing elastic interconnects since 2013.

https://www.megaport.com/services/megaport_enabled_locations

Well known in Asia but less so in US/NANOG hence the first and last public post about this.

Anyway, maybe worth a look.

Cheers

B

> On 2 Mar 2016, at 9:28 AM, Dave Cohen <craetdave at gmail.com> wrote:
> 
> I can confirm that AWS (and Equinix, by extension, from a facility operator
> perspective) permit carriers to have multiple end users share a physical
> interface into the AWS gateway. The key is whether the providers that are
> permitted into the DX environment (I believe AWS has limited the list to
> only 7 or 8 in total - anyone else is reselling capacity off of those
> carriers) are willing to deal with the constraints of that configuration -
> essentially that the carrier needs to take responsibility of engaging
> directly with AWS to associate the EVC on the provider interface with the
> VPC on the AWS interface. I can confirm that at least one provider other
> than Equinix will do this. Point being, it's not an AWS restriction as much
> as whether the provider is willing to get its hands a bit dirtier. My $.02
> at least.
> 
> - Dave
> 
>> On Tue, Mar 1, 2016 at 7:59 PM, Mike Hammett <nanog at ics-il.net> wrote:
>> 
>> I haven't heard it from the horse's mouth, but I heard that the only way
>> to have customers share an AWS DX (apparently) cross connect is through
>> Equinix's cloud exchange service. Can anyone confirm that? It doesn't seem
>> right that I could transport people to AWS all day long if they buy their
>> own cross connect, but once we share, I have to go through someone offering
>> a competitive service.
>> 
>> 
>> 
>> 
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>> 
>> ----- Original Message -----
>> 
>> From: "Michael O'Connor" <moc at es.net>
>> To: "Jay R. Ashworth" <jra at baylink.com>
>> Cc: "North American Network Operators' Group" <nanog at nanog.org>
>> Sent: Tuesday, March 1, 2016 2:41:35 PM
>> Subject: Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
>> 
>> Jay,
>> 
>> VPC is supported over IPsec if your public path is sufficient into the AWS
>> cloud.
>> 
>> AWS shortens DirectConnect to DX not DC for some reason.
>> 
>> The AWS DirectConnect service is built on 10G infrastructure so using
>> potentially larger interconnects over public peerings with IPsec could be
>> advantageous.
>> 
>> DX requires fiber cross connects in addition to any other AWS peerings that
>> you may have at a particular location.
>> 
>> -Mike O'Connor
>> 
>> 
>>>> On Tue, Mar 1, 2016 at 12:16 PM, Jay R. Ashworth <jra at baylink.com> wrote:
>>> 
>>> Just got this dropped on my desk an hour ago, and I'm not finding as much
>>> material online as I might have hoped for...
>>> 
>>> It looks like the easiest solution is to just hang a router/firewall at
>>> Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP
>>> and
>>> MPLS; is there a "native" way to do that from an AWS VPC instead?
>>> 
>>> Any public or private replies cheerfully accepted; will summarize what I
>>> can to the list.
>>> 
>>> 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
>> 
>> 
>> 
>> --
>> Michael O'Connor
>> ESnet Network Engineering
>> moc at es.net
>> 631 344-7410
> 
> 
> -- 
> - Dave Cohen
> eM: craetdave at gmail.com
> AIM: dCo says
> 
> 
> -- 
> - Dave Cohen
> eM: craetdave at gmail.com
> AIM: dCo says

From jwbensley at gmail.com  Wed Mar  2 10:03:31 2016
From: jwbensley at gmail.com (James Bensley)
Date: Wed, 2 Mar 2016 10:03:31 +0000
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <CAM5sgfzTpQZ-2+F11HH9ew1XmyrHMCZ_p=QES2YPsJQ-3EDT6g@mail.gmail.com>
References: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com>
 <CAM5sgfzTpQZ-2+F11HH9ew1XmyrHMCZ_p=QES2YPsJQ-3EDT6g@mail.gmail.com>
Message-ID: <CAAWx_pUKM9T1pSd8r62HMFte4V7ZXJOmTCF5c36ysj1OaE5KiA@mail.gmail.com>

On 1 March 2016 at 20:41, Michael O'Connor <moc at es.net> wrote:
> Jay,
>
> VPC is supported over IPsec if your public path is sufficient into the AWS
> cloud.

^ This.

I work for a DirectConnect provider, albeit in the UK though. We have
fibre links to a AWS edge routers and we have multiple customers
seperated by VLANs over a fibre link, each terminating into different
VRFs on our edge and the AWS edge. For each customer we have an eBGP
session with a virtual gateway that lives inside the customer's VPC
domain.

Also for each customer they have backup tunnels using IPSec over the
Internet. Again we run eBGP over the IPSec tunnels to the virtual
gateway inside each customers VPC domain.

"just works".

James.

From bill at herrin.us  Wed Mar  2 11:31:42 2016
From: bill at herrin.us (William Herrin)
Date: Wed, 2 Mar 2016 06:31:42 -0500
Subject: About inetnum "ownership"
In-Reply-To: <769B3C27-F7D1-4FDF-B99E-3B966F83C568@me.com>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
 <769B3C27-F7D1-4FDF-B99E-3B966F83C568@me.com>
Message-ID: <CAP-guGUm2+gko==hKGQYy96Aj2HwFjE1GLsUG1uxANSsgH3mMw@mail.gmail.com>

On Wed, Mar 2, 2016 at 2:46 AM, Jonas Bjork <mr.jonas.bjork at me.com> wrote:
> shouldn't the same logic of ownership of DNS domain names apply to inetnum address space?

Hi Jonas,

A trademark owner invoking the UDRP generally is able to exclude
anyone else that can't present an equally valid claim to the name.
That's why the vast majority of squatted names are for sale at just
under the cost of invoking the UDRP.

Regards,
Bill Herrin

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

From bill at herrin.us  Wed Mar  2 11:46:09 2016
From: bill at herrin.us (William Herrin)
Date: Wed, 2 Mar 2016 06:46:09 -0500
Subject: About inetnum "ownership"
In-Reply-To: <1456899158.11868.58.camel@biplane.com.au>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
Message-ID: <CAP-guGWJ7YOQeiin9metTsHDsbECZ-Otf-hGGywF+7TEJUsRbg@mail.gmail.com>

On Wed, Mar 2, 2016 at 1:12 AM, Karl Auer <kauer at biplane.com.au> wrote:
> Testing in court the idea that you may not advertise my routes would be
> a fascinating exercise. If you falsely advertised them it would be a
> different matter.

Hi Karl,

I'm having trouble seeing the nit you're picking. I can't compel you
to announce my BGP route but if you do announce it and your
announcement is inconsistent with my own then by definition it's
false. If your announcement is consistent with my own then you're
propagating the route as intended and I have no cause for complaint.

> Has this sort of thing been tested in the courts at all? In any
> jurisdiction?

So far as I know, network operators have interceded and the false
routes have been withdrawn long before any route hijacking cases would
have gone to court.

Regards,
Bill Herrin



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

From bob at FiberInternetCenter.com  Wed Mar  2 14:05:09 2016
From: bob at FiberInternetCenter.com (Bob Evans)
Date: Wed, 2 Mar 2016 06:05:09 -0800
Subject: About inetnum "ownership"
In-Reply-To: <1456899158.11868.58.camel@biplane.com.au>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
Message-ID: <0ad6d1b5f93eaff0ed3f89aa49ddd31c.squirrel@66.201.44.180>

The numbers (IP addresses) are not the field. The servers are the field.
The numbers are the street addresses of the server. Domain names would be
a nick name for the numbers, like PaddingHouse.com is at 55.51.52.1. The
BGP table is a road map.

That's why it was once called the Super Information Highway, remember?

You can sell street/road maps to the stars, and the stars don't have to
let you in.

Thank You
Bob Evans
CTO




> On Wed, 2016-03-02 at 00:44 -0500, William Herrin wrote:
>> Do I have the legal right to exclude others from announcing my block
>> of IP addresses to the public Internet routing tables? It's not well
>> tested in court but the odds are exceptionally strong that I do.
>
> If I own some property - say a field - the location of that field is
> with certain rare exceptions public information. I as the owner cannot
> enforce a requirement on you to NOT tell people where my field is. I
> can't demand that you NOT build roads past it, or that you NOT put up
> signs saying how to get to my field, or even that you NOT tell people
> who owns the field. I have the right to exclusive use of the property,
> but I have no rights to information about the property, nor any
> property rights outside the boundary of the property.
>
> Testing in court the idea that you may not advertise my routes would be
> a fascinating exercise. If you falsely advertised them it would be a
> different matter.
>
> Has this sort of thing been tested in the courts at all? In any
> jurisdiction?
>
>> Indeed, the whole point of registration is to facilitate
>> determination
>> of -who- has the exclusive right over -which- blocks of addresses.
>
> The problem is what rights we are talking about. I would say that
> practically speaking the only real right here is the right to configure
> an address on an interface. But anyone else can send packets to an
> address, or advertise to others the direction of travel towards that
> network. Malicious activity excluded of course - DoS attacks and so on,
> but I think the issues there are different. Also, contractually
> regulated relationships are different - if I connect something up to
> ISPX and have a contract with ISPX to NOT advertise the route to me,
> then ISPX is constrained.
>
> Regards, K.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
>
> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
>
>
>
>



From moc at es.net  Wed Mar  2 14:40:03 2016
From: moc at es.net (Michael O'Connor)
Date: Wed, 2 Mar 2016 09:40:03 -0500
Subject: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
In-Reply-To: <CAAWx_pUKM9T1pSd8r62HMFte4V7ZXJOmTCF5c36ysj1OaE5KiA@mail.gmail.com>
References: <505999303.21820.1456852610435.JavaMail.zimbra@baylink.com>
 <CAM5sgfzTpQZ-2+F11HH9ew1XmyrHMCZ_p=QES2YPsJQ-3EDT6g@mail.gmail.com>
 <CAAWx_pUKM9T1pSd8r62HMFte4V7ZXJOmTCF5c36ysj1OaE5KiA@mail.gmail.com>
Message-ID: <CAM5sgfyRVihjKevssVUT1CwJHt_0kgc_wTTZhbY907puAbmKaQ@mail.gmail.com>

ESnet employs MPLS virtual circuits from our customer sites to VLANs
connecting over DX cross connects in US-EAST and US-WEST regions. Exploring
the DX provider paradigm we have demonstrated that the billing of the DX
network service can be billed to the provider with the compute costs billed
directly to the customer. In this way a network provider can cover the
shared network resource cost, if desired.

While the carrier does provision EBGP, in our use case it was only used for
monitoring not for exchanging routes. Each of our customers provision both
a public and private/VPC EBGP peering, see public and private DX services.

This gets interesting when you realized the routes advertised by AWS differ
by geographic region in the public Internet case and when peering with DX
AWS advertises a much larger table and recommends that end sites build
policies based on the information in this link:

https://ip-ranges.amazonaws.com/ip-ranges.json

At some point your DX customers will need to make the decision to prefer
the public AWS route prefixes that you export to them or those received
directly from their DX public EBGP service.

-Mike O'Connor


On Wed, Mar 2, 2016 at 5:03 AM, James Bensley <jwbensley at gmail.com> wrote:

> On 1 March 2016 at 20:41, Michael O'Connor <moc at es.net> wrote:
> > Jay,
> >
> > VPC is supported over IPsec if your public path is sufficient into the
> AWS
> > cloud.
>
> ^ This.
>
> I work for a DirectConnect provider, albeit in the UK though. We have
> fibre links to a AWS edge routers and we have multiple customers
> seperated by VLANs over a fibre link, each terminating into different
> VRFs on our edge and the AWS edge. For each customer we have an eBGP
> session with a virtual gateway that lives inside the customer's VPC
> domain.
>
> Also for each customer they have backup tunnels using IPSec over the
> Internet. Again we run eBGP over the IPSec tunnels to the virtual
> gateway inside each customers VPC domain.
>
> "just works".
>
> James.
>



-- 
Michael O'Connor
ESnet Network Engineering
moc at es.net
631 344-7410

From peter.phaal at gmail.com  Wed Mar  2 17:25:24 2016
From: peter.phaal at gmail.com (Peter Phaal)
Date: Wed, 2 Mar 2016 09:25:24 -0800
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
Message-ID: <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>

> 
> On Mar 1, 2016, at 10:12 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
>> On 2/Mar/16 08:04, Mark Tinka wrote:
>> 
>> We were initially looking at at the Nexus 9000, but then moved to the
>> 7700 because the Broadcom chip on the 7700 cannot do single flows larger
>> than 40Gbps on the 100Gbps ports.
> 
> The Broadcom chip on the 9000, I meant...
> 
> Mark.

The Nexus 3200 should work well with 100G flows - I believe it's based on the latest Broadcom Tomahawk ASIC. The older Trident II ASICs in the Nexus 9k are 40g parts

From brough at netblazr.com  Wed Mar  2 17:28:28 2016
From: brough at netblazr.com (Brough Turner)
Date: Wed, 2 Mar 2016 12:28:28 -0500
Subject: Any large IPv4 space brokers?
In-Reply-To: <D593E3C0-E8DD-437B-BBE9-39ED421CD11F@me.com>
References: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>
 <20160302005456.GA20683@reptiles.org>
 <D593E3C0-E8DD-437B-BBE9-39ED421CD11F@me.com>
Message-ID: <CAD2VXC_26aYzMW-ksv0E01sd-uGgAzjZfJAaWrqoM=dokE8gyg@mail.gmail.com>

https://www.arin.net/resources/transfer_listing/facilitator_list.html

Thanks,
Brough

Brough Turner
netBlazr Inc. ? Free your Broadband!
Mobile:  617-285-0433   Skype:  brough
netBlazr Inc. <http://www.netblazr.com/> | Google+
<https://plus.google.com/102447512447094746687/posts?hl=en> | Twitter
<https://twitter.com/#%21/brough> | LinkedIn
<http://www.linkedin.com/in/broughturner> | Facebook
<http://www.facebook.com/brough.turner> | Blog
<http://blogs.broughturner.com/> | Personal website
<http://broughturner.com/>



On Wed, Mar 2, 2016 at 2:34 AM, Jonas Bjork <mr.jonas.bjork at me.com> wrote:

> Hi, these sites sell PA network space, I assume? Where may I buy PI nets?
>
> Best regards,
> Jonas
>
> Sent from my iPad
>
> > On 02 Mar 2016, at 01:54, Jim Mercer <jim at reptiles.org> wrote:
> >
> >> On Tue, Mar 01, 2016 at 05:32:44PM -0500, Paras Jha wrote:
> >> Does anyone know of any IP space brokers other than Hilco Streambank?
> I'm
> >> looking to get a feel for the market a little bit.
> >
> > register with the ARIN STLS, there are some blocks available there too.
> >
> > --jim
> >
> > --
> > Jim Mercer     Reptilian Research      jim at reptiles.org    +1 416
> 410-5633
> >
> > Life should not be a journey to the grave with the intention of
> > arriving safely in a pretty and well preserved body, but rather
> > to skid in broadside in a cloud of smoke, thoroughly used up,
> > totally worn out, and loudly proclaiming "Wow! What a Ride!"
> > -- Hunter S. Thompson
>

From nick at foobar.org  Wed Mar  2 17:30:51 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 02 Mar 2016 17:30:51 +0000
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
Message-ID: <56D7234B.8020304@foobar.org>

Peter Phaal wrote:
> The Nexus 3200 should work well with 100G flows - I believe it's
> based on the latest Broadcom Tomahawk ASIC. The older Trident II
> ASICs in the Nexus 9k are 40g parts

does nx-os still force ingress-and-egress sflow?  sflow is pretty
useless you can define an accounting perimeter, which means that you
need either ingress across the board, or egress.  ingress-and-egress is
basically useless because you end up double counting everything.

Nick

From pkranz at unwiredltd.com  Wed Mar  2 17:59:32 2016
From: pkranz at unwiredltd.com (Peter Kranz)
Date: Wed, 2 Mar 2016 09:59:32 -0800
Subject: Juniper PTX1000
Message-ID: <28b401d174ad$46540250$d2fc06f0$@unwiredltd.com>

Anyone played with the newish Juniper PTX1000 platform? Seems quite
interesting for compact deployments, but I've not been able to find much
pricing information to see just how interesting..

 

Peter Kranz
www.UnwiredLtd.com <http://www.unwiredltd.com/> 
Desk: 510-868-1614 x100
Mobile: 510-207-0000
pkranz at unwiredltd.com <mailto:pkranz at unwiredltd.com> 

 


From hank at efes.iucc.ac.il  Wed Mar  2 19:02:07 2016
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Wed, 2 Mar 2016 21:02:07 +0200
Subject: Any large IPv4 space brokers?
In-Reply-To: <CAD2VXC_26aYzMW-ksv0E01sd-uGgAzjZfJAaWrqoM=dokE8gyg@mail.gmail.com>
References: <CAJayEpGrjXtF1baYkYQvFyS-Dv9SAb8auii3CMKfRcqv5eqBPw@mail.gmail.com>
 <20160302005456.GA20683@reptiles.org>
 <D593E3C0-E8DD-437B-BBE9-39ED421CD11F@me.com>
 <CAD2VXC_26aYzMW-ksv0E01sd-uGgAzjZfJAaWrqoM=dokE8gyg@mail.gmail.com>
Message-ID: <56D738AF.5020806@efes.iucc.ac.il>

On 02/03/2016 19:28, Brough Turner wrote:
> https://www.arin.net/resources/transfer_listing/facilitator_list.html
>
> Thanks,
> Brough

There was a RIPE site:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers
but most of the links are broken (like Brokers and IP Transfer Listing
Service) so try these:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/brokers
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/transfer-faqs

-Hank

From jason.iannone at gmail.com  Wed Mar  2 19:50:07 2016
From: jason.iannone at gmail.com (Jason Iannone)
Date: Wed, 2 Mar 2016 12:50:07 -0700
Subject: BGP MVPN RFC6513, Section 10
In-Reply-To: <CAG5mEj93Jt-RuOnmf2JcuGGYVULnziXoKdDHJ8h=4Qx3v1o11g@mail.gmail.com>
References: <CAGL1wDSPWr35_Uw0PaeCeFCQDeU2mzU_Sxn+VvGz_ifkT6Mg=g@mail.gmail.com>
 <CAG5mEj93Jt-RuOnmf2JcuGGYVULnziXoKdDHJ8h=4Qx3v1o11g@mail.gmail.com>
Message-ID: <CAGL1wDQAXNQ_1Mm856smZ=8fWapupUR6zC8EHdNtBu4PpaOURg@mail.gmail.com>

Thanks for responding.  What's interesting is that even though no
listener joins to RP, one must be configured for PIM Sparse Mode ASM
to function.  I suppose this is a result of MVPN outsmarting PIM.

In my testing so far, generating a working flow with rpt-spt is much
faster than spt-only.  I suspect this has to do with the conditional
nature of the Type 7 Join which waits for receipt of a Type 5 SA
before signaling interest upstream.  spt-only mode seems objectively
superior to rpt-spt in every other way.

Jason

On Fri, Feb 26, 2016 at 2:33 AM, Yann Lejeune <yann.lejeune at gmail.com> wrote:
> Hi
> To support the section ?10 in your conf you have two choices:
> a. (?10.1) implementing the RP on your PE (protocol pim rp local). It will
> advertises the route type after pim register message (or msdp source active
> from other RP is you have other rp in your network)
>     + be sure to use spt-only mvpn mode (default one)
>
> b. (?10.2) implementing an MSDP session between the RP and its PE
>     each time the RP will learn a source (either because it receives a pim
> register or a SA message from another RP (full meshing msdp between rp), it
> will advertise route type 5 to the mVPN. This way receiver PE will learnt
> source and if they received join (*,g), they will be able to advertise the
> good route type 7 to the source PE. The required conf is:
>         - msdp session between the pe and the rp
>         - defining the rp address (protocols pim rp static....)
>         - be sure to use spt-only mvpn mode (default one)
>
> The route type 6 is used in another mode call rpt-spt, where you are closer
> to the traditionnal multicast behavior (first we build the rp tree and
> second we build the source tree). this mode must be enable explicitely per
> routing-instance in the mvpn-mode knob. One thing: even in spt-only mode,
> the junos will create a route type 6 when receiving a join (*,g) but will
> not advertise it. It just wait to get a related route type 5
>
> It's up to you to choose what mode you want to use:
> - spt-only: is quite "simple". We only have (s,g) in the core. To validate
> an os, it's faster.
> - rpt-spt. We have both (*,g) and (s,g) in the core. the validation is more
> complex, the protocol is more dynamic...
>
> Regards,
> Yann.
>
>
>
> On 23 February 2016 at 16:39, Jason Iannone <jason.iannone at gmail.com> wrote:
>>
>> Hi all,
>>
>> I'm having trouble interpreting under what circumstance section 10 of
>> BGP MVPN comes into play.
>>
>> The way I read this section, upon the receipt of PIM/IGMP Join to
>> (*,G) the Receiver Site PE does not signal Type 6 or Type 7 Joins
>> until a Type 5 Source Active route is received from a Sender Site PE.
>>
>> If Section 10 assumes the use of ASM groups in the VPN, why develop a
>> Type 6 Shared Tree Join A-D route for unknown sources?
>>
>> What are the practical minimum Juniper configurations to support
>> Section 10 for ASM and (*,G) PIM Join when the PE doesn't know a
>> source?
>>
>> CE1---PE1,C-RP-----P-----PE2---CE2
>> Sender Site-------------------Receiver Site
>>
>> 1. CE1 has no active source
>> 2. CE2 forwards PIM Join (*,G) to PE2 toward PE1,C-RP
>> 3. PE2 eats PIM Join, maintains (*,G) state
>> 4. CE1 generates Register messages to PE1
>> 5. PE1 originates Type 5 (S,G)
>> 6. PE2 receives Type 5 (S,G)
>> 7. PE2 verifies existing (*,G) state
>> 8. PE2 advertises Type 7 Join (S,G)
>> 9. PE2 does PMSI and P-Tunnel attachment
>> 10. PE1 receives (S,G) from PE2
>> 11. PE1 adds PMSI to downstream interfaces
>> 12. Multicast flow end to end
>> 13. Achievement unlocked!
>>
>> I'm least sure about steps 2 & 3.
>>
>> Comprehension challenged,
>>
>> Jason
>
>

From saku at ytti.fi  Wed Mar  2 21:01:30 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 2 Mar 2016 23:01:30 +0200
Subject: Juniper PTX1000
In-Reply-To: <28b401d174ad$46540250$d2fc06f0$@unwiredltd.com>
References: <28b401d174ad$46540250$d2fc06f0$@unwiredltd.com>
Message-ID: <CAAeewD-KOAbrJQ0K8SbG+ZydGWHsZDce-=EzmNurnV-CaqCprw@mail.gmail.com>

On 2 March 2016 at 19:59, Peter Kranz <pkranz at unwiredltd.com> wrote:

> Anyone played with the newish Juniper PTX1000 platform? Seems quite
> interesting for compact deployments, but I've not been able to find much
> pricing information to see just how interesting..

I would expect it to be priced competitively against Jericho boxes.
Initial look at its brother from another mother are mostly positive,
but then again I had realistic expectations, I didn't expect denser
Trio.

-- 
  ++ytti

From owen at delong.com  Wed Mar  2 22:05:20 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 2 Mar 2016 14:05:20 -0800
Subject: Cogent & Google IPv6
In-Reply-To: <321616AE-EC19-4DD7-9A2D-02378ED73D5B@ianai.net>
References: <CADvW4yP2Zp8-ybd-+BOyPGAwxzLXkaDZDgHJ50-=zKWF1=NLYg@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D0CFB19@EXCH01.sb.local>
 <56CE08B0.2080103@indigowireless.com>
 <CAPkb-7BOi70oWv17H1nzxijZ0JbLcdsHgBzj-qMN6qK-eR2rqw@mail.gmail.com>
 <321616AE-EC19-4DD7-9A2D-02378ED73D5B@ianai.net>
Message-ID: <7534881E-E464-483C-8C19-A92CA273215B@delong.com>

I think actually, that Cogent is the new SPRINT.

I remember a time when virtually all of the internet Transited SPRINT and it was nearly impossible to avoid going through SPRINT?s network.

Then SPRINT started de-peering left and right. Today, as near as I can tell, this strategy has made then an ?also-ran?.

Cogent is already essentially the weakest of any who can lay claim to the idea of ?tier-1? whatever that?s supposed to mean (varies widely depending on who you ask).

For now, Cogent is hoping that they can force the same environment in IPv6 as they have enjoyed in IPv4 while ignoring the reality that many players have surpassed them in IPv6 and that there are new opportunities to go settlement free in IPv6 that didn?t exist in the IPv4 world. The IPv6 game is somewhat different than IPv4 and recent rulings from the FCC are going to potentially change the game even further.

My guess is that Cogent won?t blink, but they will continue to become more and more isolated from more and more IPv6 networks who become wise to their game. As a result, they will become less and less relevant in the market until they join SPRINT on the also-ran list.

Owen

> On Feb 24, 2016, at 12:12 , Patrick W. Gilmore <patrick at ianai.net> wrote:
> 
> Are HE & Google the new L3 & FT?
> 
> Nah, L3 would never have baked Cogent a cake. :)
> 
> Shall we start a pool? Only problem is, should the pool be ?who will disconnect from Cogent next?? or ?when will Cogent blink?? I?m voting for the former.
> 
> -- 
> TTFN,
> patrick
> 
>> On Feb 24, 2016, at 3:08 PM, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
>> 
>> This is Google saying that Google does not want to pay for traffic to
>> Cogent. If Cogent wants to exchange any traffic with Google, Cogent is
>> invited to peer directly with Google. Of course Cogent refuses. And now
>> Cogent is not only missing the part of IPv6 internet that is Hurricane
>> Electric single homed but also everything Google.
>> 
>> Why does Cogent refuse? They used to deliver this traffic on free peering
>> with another tier 1 provider. Now they are asked to deliver the same
>> traffic for the same price (free) on a direct peering session. They won't
>> because Cogent believes Google should pay for this traffic. That another
>> Cogent customer already paid for the traffic does not matter. They want
>> double dipping or nothing. So nothing it is.
>> 
>> Seems to me that if you are serious about IPv6 you can not use Cogent as
>> your primary or secondary transit provider. You can use them as your third
>> if you want to.
>> 
>> Regards,
>> 
>> Baldur
>> 
>> 
>> 
>> On 24 February 2016 at 20:46, Matt Hoppes <mhoppes at indigowireless.com>
>> wrote:
>> 
>>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6,
>>> shouldn't the traffic flow out to one of their peer points where another
>>> peer DOES peer with Google IPv6 and get you in?
>>> 
>>> Isn't that how the Internet is suppose to work?
>>> 
>>> 
>>> On 2/24/16 2:43 PM, Damien Burke wrote:
>>> 
>>>> Not sure. I got the same thing today as well.
>>>> 
>>>> Is this some kind of ipv6 war?
>>>> 
>>>> -----Original Message-----
>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ian Clark
>>>> Sent: Wednesday, February 24, 2016 10:25 AM
>>>> To: NANOG
>>>> Subject: Cogent & Google IPv6
>>>> 
>>>> Anyone know what's actually going on here?  We received the following
>>>> information from the two of them, and this just started a week or so ago.
>>>> 
>>>> 
>>>> *From Cogent, the transit provider for a branch office of ours:*
>>>> 
>>>> Dear Cogent Customer,
>>>> 
>>>> Thank you for contacting Cogent Customer Support for information about
>>>> the Google IPv6 addresses you are unable to reach.
>>>> 
>>>> Google uses transit providers to announce their IPv4 routes to Cogent.
>>>> 
>>>> At this time however, Google has chosen not to announce their IPv6 routes
>>>> to Cogent through transit providers.
>>>> 
>>>> We apologize for any inconvenience this may cause you and will notify you
>>>> if there is an update to the situation.
>>>> 
>>>> 
>>>> 
>>>> *From Google (re: Cogent):*
>>>> 
>>>> Unfortunately it seems that your transit provider does not have IPv6
>>>> connectivity with Google. We suggest you ask your transit provider to look
>>>> for alternatives to interconnect with us.
>>>> 
>>>> Google maintains an open interconnect policy for IPv6 and welcomes any
>>>> network to peer with us for access via IPv6 (and IPv4). For those networks
>>>> that aren't able, or chose not to peer with Google via IPv6, they are able
>>>> to reach us through any of a large number of transit providers.
>>>> 
>>>> For more information in how to peer directly with Google please visit
>>>> https://peering.google.com
>>>> 
>>>> 
>>>> --
>>>> Ian Clark
>>>> Lead Network Engineer
>>>> DreamHost
>>>> 
>>>> 
> 


From peter.phaal at gmail.com  Wed Mar  2 22:37:19 2016
From: peter.phaal at gmail.com (Peter Phaal)
Date: Wed, 2 Mar 2016 14:37:19 -0800
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <56D7234B.8020304@foobar.org>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
 <56D7234B.8020304@foobar.org>
Message-ID: <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>

On Wed, Mar 2, 2016 at 9:30 AM, Nick Hilliard <nick at foobar.org> wrote:
> Peter Phaal wrote:
>> The Nexus 3200 should work well with 100G flows - I believe it's
>> based on the latest Broadcom Tomahawk ASIC. The older Trident II
>> ASICs in the Nexus 9k are 40g parts
>
> does nx-os still force ingress-and-egress sflow?  sflow is pretty
> useless you can define an accounting perimeter, which means that you
> need either ingress across the board, or egress.  ingress-and-egress is
> basically useless because you end up double counting everything.

Monitoring ingress and egress in the switch is wasteful of resources.
In most use switch  use cases (a leaf / spine fabric for example) the
next hop switch will also be reporting ingress sFlow and so when you
combine sFlow streams from both switches you get bi-directional
visibility into every link. Enabling ingress only sFlow on all switch
ports catches all packet paths and halves the overhead of
bi-directional sampling.

The sFlow architecture shifts intelligence from the devices to
external software. The goal is to have a general purpose telemetry
stream that can be used for a variety of purposes. Rather than having
the complexity of configuring sFlow selectively at the sender, the
receiver is responsible for de-duplicate the sFlow stream for
accounting (the packet stream selection and elimination you are doing
in the switch configuration can equally be applied on receipt).
Shifting the decision to the collector means you can also use the
stream to diagnose performance problems (for example identifying top
flows on a busy link), traffic engineering of large flows, etc. If the
sender is configured to suite one application, you limit the value of
the measurements for other applications.

An often overlooked feature of sFlow is that the agent also
periodically sends interface counters (reducing or eliminating the
need for SNMP polling in many use cases). The counters and packet
samples are tied together in the sFlow data model - for example you
can use the interface speed information from the counter samples to
compute utilizations based on the packet sample stream etc). Broadcom
also defined sFlow metrics to provide additional visibility into the
ASIC forwarding pipeline (layer 2 / layer 3 / ACL table utilization,
buffer utilization, microburst detection) and the inclusion of these
metrics with the samples packet data in the sFlow telemetry stream
provides a way to identify the traffic that is consuming the hardware
resources.

From nick at foobar.org  Wed Mar  2 22:45:26 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 02 Mar 2016 22:45:26 +0000
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
 <56D7234B.8020304@foobar.org>
 <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>
Message-ID: <56D76D06.9010102@foobar.org>

Peter Phaal wrote:
> Monitoring ingress and egress in the switch is wasteful of resources.

It's more than a waste of resources:  it's pathologically broken and
Cisco decline to fix it, despite the fact that enabling ingress-only or
egress-only is fully supported via API in the Broadcom SDKs, and
consequently the amount of configuration glue required to fix it in
NX-OS is nearly zero.

Broadcom chipsets don't support netflow, so sflow is the only game in
town if you need data telemetry on broadcom-based ToR boxes.

As I said in a previous email on this thread, refusing to support this
properly is a harmful and short sighted approach to customers' requirements.

Nick


From peter.phaal at gmail.com  Wed Mar  2 23:05:50 2016
From: peter.phaal at gmail.com (Peter Phaal)
Date: Wed, 2 Mar 2016 15:05:50 -0800
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <56D76D06.9010102@foobar.org>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
 <56D7234B.8020304@foobar.org>
 <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>
 <56D76D06.9010102@foobar.org>
Message-ID: <CAB8g2zxpUdmerVmu_CXkFt8db736TUfzQCDd44biUPy2ABUpKg@mail.gmail.com>

On Wed, Mar 2, 2016 at 2:45 PM, Nick Hilliard <nick at foobar.org> wrote:
> Peter Phaal wrote:
>> Monitoring ingress and egress in the switch is wasteful of resources.
>
> It's more than a waste of resources:  it's pathologically broken and
> Cisco decline to fix it, despite the fact that enabling ingress-only or
> egress-only is fully supported via API in the Broadcom SDKs, and
> consequently the amount of configuration glue required to fix it in
> NX-OS is nearly zero.
>
> Broadcom chipsets don't support netflow, so sflow is the only game in
> town if you need data telemetry on broadcom-based ToR boxes.
>
> As I said in a previous email on this thread, refusing to support this
> properly is a harmful and short sighted approach to customers' requirements.

I think "pathologically broken" somewhat overstates the case.
Bidirectional sampling is allowed by the sFlow spec and other vendors
have made that choice. Another vendor used to implement egress only
sampling (also allowed) but unusual. I agree that ingress is the most
common and easiest to deal with, but a decent sFlow analyzer should be
able to handle all three cases without over / under counting.

More annoying is differences in how vendors report telemetry from LAG
/ MLAG topologies. The "sFlow LAG Counters Structure" extension was
published in 2012 and defines how counters and samples should be
generated on LAGs. Anyone with using LAG / MLAG topologies might want
to ask their vendor if they support / plan to support the extension.

From mureninc at gmail.com  Wed Mar  2 23:32:19 2016
From: mureninc at gmail.com (Constantine A. Murenin)
Date: Wed, 2 Mar 2016 15:32:19 -0800
Subject: About inetnum "ownership"
In-Reply-To: <CAP-guGWJ7YOQeiin9metTsHDsbECZ-Otf-hGGywF+7TEJUsRbg@mail.gmail.com>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
 <CAP-guGWJ7YOQeiin9metTsHDsbECZ-Otf-hGGywF+7TEJUsRbg@mail.gmail.com>
Message-ID: <CAPKkNb4VY3OdRficE8zSR_P9xQ+u8hvOnj9xCTWVuryYkKN_1A@mail.gmail.com>

On 2 March 2016 at 03:46, William Herrin <bill at herrin.us> wrote:
> On Wed, Mar 2, 2016 at 1:12 AM, Karl Auer <kauer at biplane.com.au> wrote:
>> Testing in court the idea that you may not advertise my routes would be
>> a fascinating exercise. If you falsely advertised them it would be a
>> different matter.
>
> Hi Karl,
>
> I'm having trouble seeing the nit you're picking. I can't compel you
> to announce my BGP route but if you do announce it and your
> announcement is inconsistent with my own then by definition it's
> false. If your announcement is consistent with my own then you're
> propagating the route as intended and I have no cause for complaint.
>
>> Has this sort of thing been tested in the courts at all? In any
>> jurisdiction?
>
> So far as I know, network operators have interceded and the false
> routes have been withdrawn long before any route hijacking cases would
> have gone to court.

Care to explain why noone has bothered to seek punitive damages, then?

C.

From larrysheldon at cox.net  Thu Mar  3 00:17:13 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Wed, 2 Mar 2016 18:17:13 -0600
Subject: About inetnum "ownership"
In-Reply-To: <0ad6d1b5f93eaff0ed3f89aa49ddd31c.squirrel@66.201.44.180>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
 <0ad6d1b5f93eaff0ed3f89aa49ddd31c.squirrel@66.201.44.180>
Message-ID: <56D78289.1040101@cox.net>

On 3/2/2016 08:05, Bob Evans wrote:
> The numbers (IP addresses) are not the field. The servers are the field.
> The numbers are the street addresses of the server. Domain names would be
> a nick name for the numbers, like PaddingHouse.com is at 55.51.52.1. The
> BGP table is a road map.
>
> That's why it was once called the Super Information Highway, remember?
>
> You can sell street/road maps to the stars, and the stars don't have to
> let you in.
>
> Thank You
> Bob Evans
> CTO
>
>
>
>
>> On Wed, 2016-03-02 at 00:44 -0500, William Herrin wrote:
>>> Do I have the legal right to exclude others from announcing my block
>>> of IP addresses to the public Internet routing tables? It's not well
>>> tested in court but the odds are exceptionally strong that I do.
>> If I own some property - say a field - the location of that field is
>> with certain rare exceptions public information. I as the owner cannot
>> enforce a requirement on you to NOT tell people where my field is. I
>> can't demand that you NOT build roads past it, or that you NOT put up
>> signs saying how to get to my field, or even that you NOT tell people
>> who owns the field. I have the right to exclusive use of the property,
>> but I have no rights to information about the property, nor any
>> property rights outside the boundary of the property.
>>
>> Testing in court the idea that you may not advertise my routes would be
>> a fascinating exercise. If you falsely advertised them it would be a
>> different matter.
>>
>> Has this sort of thing been tested in the courts at all? In any
>> jurisdiction?
>>
>>> Indeed, the whole point of registration is to facilitate
>>> determination
>>> of -who- has the exclusive right over -which- blocks of addresses.
>> The problem is what rights we are talking about. I would say that
>> practically speaking the only real right here is the right to configure
>> an address on an interface. But anyone else can send packets to an
>> address, or advertise to others the direction of travel towards that
>> network. Malicious activity excluded of course - DoS attacks and so on,
>> but I think the issues there are different. Also, contractually
>> regulated relationships are different - if I connect something up to
>> ISPX and have a contract with ISPX to NOT advertise the route to me,
>> then ISPX is constrained.
>>
>> Regards, K.
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Karl Auer (kauer at biplane.com.au)
>> http://www.biplane.com.au/kauer
>> http://twitter.com/kauer389
>>
>> GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
>> Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
>>
>>
>>
>>
>
>

Interesting demonstration of why retreat to analogies does not help in a 
discussion.

A question:  If you stop announcing your routes, where will the world 
get them from?

-- 
sed quis custodiet ipsos custodes? (Juvenal)


From bob at FiberInternetCenter.com  Thu Mar  3 00:55:25 2016
From: bob at FiberInternetCenter.com (Bob Evans)
Date: Wed, 2 Mar 2016 16:55:25 -0800
Subject: About inetnum "ownership"
In-Reply-To: <56D78289.1040101@cox.net>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
 <0ad6d1b5f93eaff0ed3f89aa49ddd31c.squirrel@66.201.44.180>
 <56D78289.1040101@cox.net>
Message-ID: <1039b75433a4028202a8e2ee606224eb.squirrel@66.201.44.180>


As far as I know there is no requirement to announce your assigned or
legacy owned prefixes to the world. You have the right to announce them. 
I don't think you can legally stop others from announcing your path to
them. Once you publicly announce something, it's out there.

Oh well, maybe I didn't get the original question. I thought the
discussion was about a network's right to prevent others in the world from
announcing/propagating a route to that network's prefixes. Seemed to be a
legal question and the field analogy someone put forth seemed to apply
well. I can't take credit for that as I simply tuned it and showed how it
fit in a historical way. I think a lawyer would probably make this analogy
in a court.

Thank You
Bob Evans
CTO


>
> Interesting demonstration of why retreat to analogies does not help in a
> discussion.
>
> A question:  If you stop announcing your routes, where will the world
> get them from?
>
> --
> sed quis custodiet ipsos custodes? (Juvenal)
>
>



From mark.tinka at seacom.mu  Thu Mar  3 06:47:05 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 3 Mar 2016 08:47:05 +0200
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
Message-ID: <7e047c6b-b597-5609-4ea0-2146ab76e5b9@seacom.mu>



On 2/Mar/16 19:25, Peter Phaal wrote:

> The Nexus 3200 should work well with 100G flows - I believe it's based on the latest Broadcom Tomahawk ASIC. The older Trident II ASICs in the Nexus 9k are 40g parts.

Yes, the new Tomahawk chips support native 100Gbps lanes.

Mark.

From nick at foobar.org  Thu Mar  3 11:53:06 2016
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 03 Mar 2016 11:53:06 +0000
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <CAB8g2zxpUdmerVmu_CXkFt8db736TUfzQCDd44biUPy2ABUpKg@mail.gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
 <56D7234B.8020304@foobar.org>
 <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>
 <56D76D06.9010102@foobar.org>
 <CAB8g2zxpUdmerVmu_CXkFt8db736TUfzQCDd44biUPy2ABUpKg@mail.gmail.com>
Message-ID: <56D825A2.70606@foobar.org>

Peter Phaal wrote:
> I think "pathologically broken" somewhat overstates the case.
> Bidirectional sampling is allowed by the sFlow spec and other vendors
> have made that choice. Another vendor used to implement egress only
> sampling (also allowed) but unusual. I agree that ingress is the most
> common and easiest to deal with, but a decent sFlow analyzer should be
> able to handle all three cases without over / under counting.

Bidirectional sampling doesn't allow you to define an sampling perimeter
on your switch topology.  This means that if you if you have anything
other than a trivial topology, you will end up double-counting your
traffic.  The only way to work around this is to get the collector to
discard 50% of the samples or otherwise write down the amount of traffic
by 50%, assuming a standard accounting perimeter configuration.  This is
broken.

The thing is, this is ridiculously easy to fix in code.  The hooks are
already there.

Nick

From peter.phaal at gmail.com  Thu Mar  3 15:26:46 2016
From: peter.phaal at gmail.com (Peter Phaal)
Date: Thu, 3 Mar 2016 07:26:46 -0800
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <56D825A2.70606@foobar.org>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
 <56D7234B.8020304@foobar.org>
 <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>
 <56D76D06.9010102@foobar.org>
 <CAB8g2zxpUdmerVmu_CXkFt8db736TUfzQCDd44biUPy2ABUpKg@mail.gmail.com>
 <56D825A2.70606@foobar.org>
Message-ID: <CAB8g2zwGgeh=qOZ_tSnGDTYYLsTX8YKwYFEnMk41naPstXWq+g@mail.gmail.com>

While it would be nice if the Nexus switches supported ingress
sampling, you can get exactly the same result at the receiving end by
dropping the egress samples. The following sflowtool output shows some
of the metadata contained in the packet sample:

startSample ----------------------
sampleType_tag 0:1
sampleType FLOWSAMPLE
sampleSequenceNo 1022129
sourceId 0:7
meanSkipCount 128
samplePool 130832512
dropEvents 0
inputPort 7
outputPort 10

The two fields of interest are the sourceId (0:7) indicating that this
measurement came from a data source of type ifIndex (0) and that the
ifIndex of the data sources is 7. The inputPort is the ifIndex of the
port that received the packet. In this case because the dataSource
ifIndex and the inputPort ifIndex are the same, this is an ingress
sampled packet. A simple filter along the lines:

if ( sourceId.split(':')[1] != inputPort) return;

would allow your sFlow analyzer to eliminate the unwanted samples. You
could also enable / disable ports on your switches to ensure that each
path is sampled once, but that does limit the types of analysis you
can do with the data. A better approach is to simply add additional
input filters to specify which edge data sources you want to include /
exclude in your traffic accounting application since this would allow
the full sFlow feed to be used for other purposes as well (identifying
traffic on busy links, etc.)

The overhead of enabling sFlow on all ports and all devices is
generally quite small since packets are sampled in hardware and
production sampling rates tend to be in range (1,000 - 50,000) so very
little traffic measurement traffic is actually generated. A more
important consideration is operational complexity. If you have
thousands of switches, designing customized configurations for each
one doesn't make a lot of sense. It's much better if the intelligence
is applied at the collecting end. Taking this approach and including
sensible defaults in the agents can get the sFlow agent configuration
down to something as simple as:

sflow {
  DNSSD = off
  collector {
    ip = 10.0.0.162
  }
}

And you could go even simpler if you use DNS SRV records to identify
the sFlow collector(s)

sflow {
  DNSSD=on
}

These configurations are from Cumulus Linux.

One of the trends in merchant silicon based platforms is inclusions of
the ONIE boot loader. If you don't like the network operating system,
you can install a different operating system to better suite your
requirements without ripping and replacing hardware. There are many
virtually identical switches built around the Broadcom ASICs, giving a
lot of choice in hardware and network operating system vendor.

On Thu, Mar 3, 2016 at 3:53 AM, Nick Hilliard <nick at foobar.org> wrote:
> Peter Phaal wrote:
>> I think "pathologically broken" somewhat overstates the case.
>> Bidirectional sampling is allowed by the sFlow spec and other vendors
>> have made that choice. Another vendor used to implement egress only
>> sampling (also allowed) but unusual. I agree that ingress is the most
>> common and easiest to deal with, but a decent sFlow analyzer should be
>> able to handle all three cases without over / under counting.
>
> Bidirectional sampling doesn't allow you to define an sampling perimeter
> on your switch topology.  This means that if you if you have anything
> other than a trivial topology, you will end up double-counting your
> traffic.  The only way to work around this is to get the collector to
> discard 50% of the samples or otherwise write down the amount of traffic
> by 50%, assuming a standard accounting perimeter configuration.  This is
> broken.
>
> The thing is, this is ridiculously easy to fix in code.  The hooks are
> already there.
>
> Nick

From nick at foobar.org  Thu Mar  3 17:16:25 2016
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 03 Mar 2016 17:16:25 +0000
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <CAB8g2zwGgeh=qOZ_tSnGDTYYLsTX8YKwYFEnMk41naPstXWq+g@mail.gmail.com>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net> <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
 <56D7234B.8020304@foobar.org>
 <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>
 <56D76D06.9010102@foobar.org>
 <CAB8g2zxpUdmerVmu_CXkFt8db736TUfzQCDd44biUPy2ABUpKg@mail.gmail.com>
 <56D825A2.70606@foobar.org>
 <CAB8g2zwGgeh=qOZ_tSnGDTYYLsTX8YKwYFEnMk41naPstXWq+g@mail.gmail.com>
Message-ID: <56D87169.4010908@foobar.org>

Peter Phaal wrote:
> sampled packet. A simple filter along the lines:
> 
> if ( sourceId.split(':')[1] != inputPort) return;

It's not a one-liner in practice.  It involves maintaining an array of
source ip + egressPorts with sflow enabled and (depending on how you
implement it) e.g. ensuring that all flow samples with a destination
port of one of the entries on the list is excluded from the flow
processing.  Alternatively, you can set up a full accounting perimeter
and lop off 50% of the packet and byte counts.

The beauty of sflow is that you can do anything in the collector, but
most people aren't going to do this because it means maintaining two
sets of data about your flow configuration: one set on the switch and
one set in your collector code which you've now diverged from the
mainstream distribution, thereby creating a requirement for future
maintenance, with associated costs.

Cisco could just fix the problem rather than lalala-ing about how it's
now a feature because it's been documented.  Broadcom's SDK makes it
simple to implement this and there is no technical reason for Cisco to
continue to decline to fix the problem.

Nick

From peter.phaal at gmail.com  Thu Mar  3 18:23:24 2016
From: peter.phaal at gmail.com (Peter Phaal)
Date: Thu, 3 Mar 2016 10:23:24 -0800
Subject: sFlow vs netFlow/IPFIX
In-Reply-To: <56D87169.4010908@foobar.org>
References: <CE7FE2C2-80F9-4B42-83BB-7D4219C117D8@n5tech.com>
 <56D3776F.7050508@foobar.org>
 <CAPkb-7ApSOtGJg_E+LECSA83qVmVEeG82cbrfX_5M22KPGr57Q@mail.gmail.com>
 <FFBBB0C1-7002-4B0C-84B6-429D81EFCB71@arbor.net>
 <250778.1456713714@turing-police.cc.vt.edu>
 <CALgsdbfkth3YXg6xzUoOhRzkobgGie5i0f4uq-f2cjFFSF8dWg@mail.gmail.com>
 <56D41A5C.70907@nvcube.net>
 <978c8b83-4281-9f0b-731a-1f9426528dc0@seacom.mu>
 <CAB8g2zy0otuuXYPTw=ts4YDox-Q+Y-RMgjFatLVWuttR0g2Cxg@mail.gmail.com>
 <412620ce-cc20-edfc-c5b9-fd3c3ac9180c@seacom.mu>
 <a0776ccc-faba-af55-e5fc-bdd3f6e52251@seacom.mu>
 <5EC55121-9368-4DA4-9DCE-B62CD40BA439@gmail.com>
 <56D7234B.8020304@foobar.org>
 <CAB8g2zxKxF4z9hcmsQLU=AVJKw4LAmMLdG6GP5MFw+zq2hKMAA@mail.gmail.com>
 <56D76D06.9010102@foobar.org>
 <CAB8g2zxpUdmerVmu_CXkFt8db736TUfzQCDd44biUPy2ABUpKg@mail.gmail.com>
 <56D825A2.70606@foobar.org>
 <CAB8g2zwGgeh=qOZ_tSnGDTYYLsTX8YKwYFEnMk41naPstXWq+g@mail.gmail.com>
 <56D87169.4010908@foobar.org>
Message-ID: <CAB8g2zzZBtpPqNPXEA-X-p421W3bx5aTLQOhBgbq_zqd+TNK1A@mail.gmail.com>

On Thu, Mar 3, 2016 at 9:16 AM, Nick Hilliard <nick at foobar.org> wrote:
> The beauty of sflow is that you can do anything in the collector, but
> most people aren't going to do this because it means maintaining two
> sets of data about your flow configuration: one set on the switch and
> one set in your collector code which you've now diverged from the
> mainstream distribution, thereby creating a requirement for future
> maintenance, with associated costs.

I completely agree that you don't want to maintain two sets of
configurations (switch and collector) that need to be updated.
However, it's much better to focus on minimizing switch configuration
complexity than it is to focus on reducing analyzer software
configuration complexity.

If you push the problem of de-duplication to the switch configurations
then you end up with VxT sets of switch configuration in a
multi-vendor network (where T is the number of topologically different
wiring configurations used for the switches and V is the number of
vendors - actually it can be even worse, since each vendor product
line might have different configuration options, CatOS vs NX-OS for
example). Adopting a standard sFlow agent configuration in which
monitoring is enabled on all switch ports with policy based default
sampling rates (a good default sampling rate = port speed in gigabits
per second x 1000. e.g. 1-in-10,000 on a 10G port) greatly simplifies
large scale sFlow deployments. Now instead of maintaining and updating
VxT configurations in thousands of switches, there are only V switch
configurations that are installed when the switches are initially
provisioned and remain static over the lifetime of the network.

Updating the single, central configuration of the sFlow analyzer
software is much simpler and easily automated. It also makes it much
easier to roll out new analytics capabilities since they are simply
configuration and software updates to the central collector and don't
require building, testing and deploying configurations to all the
devices.

From owen at delong.com  Thu Mar  3 18:44:20 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 3 Mar 2016 10:44:20 -0800
Subject: About inetnum "ownership"
In-Reply-To: <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
Message-ID: <99152FD9-11EF-4F00-9283-7C9417498E7B@delong.com>


> On Mar 1, 2016, at 21:44 , William Herrin <bill at herrin.us> wrote:
> 
> On Tue, Mar 1, 2016 at 6:55 PM, Owen DeLong <owen at delong.com> wrote:
>> Unique registrations in the RIR databases may well be property.
> 
> Hi Owen,
> 
> Registration records property. Registrations are not the property recorded.
> 
> The U.S. Supreme Court talks about property this way: "The right to
> exclude others [is] one of the most essential sticks in the bundle of
> rights that are commonly characterized as property." (Kaiser Aetna v.
> United States)

And you get no such right in IP addresses.

> Do I have the legal right to exclude others from announcing my block
> of IP addresses to the public Internet routing tables? It's not well
> tested in court but the odds are exceptionally strong that I do.
> Indeed, the whole point of registration is to facilitate determination
> of -who- has the exclusive right over -which- blocks of addresses.

Not so much, no.

First, there?s no good definition of ?the public Internet? and there?s
no single definition of ?public routing tables?.

There is, instead, the set of individually run networks who cooperate in
the exchange of traffic by sharing routes.

Any right to exclude would be a right to control how each and every one
of those networks operates. Since many of those networks are outside of
the jurisdiction of any court to which you would likely have access and
to the best of my knowledge there is no international court of competent
jurisdiction to compel ISPs around the world to obey any such order,
no, you have no right to exclude.

> The right to exclude is not the only one in the bundle of rights that
> is property but it is the primary and it is argued sufficient
> condition of property.
> http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1492&context=nlr
> 
> Which brings us back around to what I said earlier: IP addresses are
> property but the legal precedent isn't as strong as might be nice.

I think I have shown that you do not have the right to exclude, so if you
have some other basis by which you think you can define these property
rights, let?s have it.

I argue that because what you actually mean by ?the public Internet? is
a combination of so many different legal entities in so many not-necessarily-
overlapping jurisdictions and because there is no single jurisdiction to
which they are all subject, nor even necessarily any particular agreed
upon complete shared definition or enumeration of all of them, the ability
to enforce any sort of right to exclusion is nothing but a myth, making
any such alleged right also mythical.

>> IP addresses are so abstract and ephemeral in their nature
>> as to be impossible to treat as property
> 
> Computers don't do abstraction. There's nothing abstract or
> particularly ephemeral about the use of IP addresses on the public
> Internet.

Please in a legal way define this single entity that you refer to as
?the public Internet? such that some court would have jurisdiction over
the entirety of its operations.

Then please define the venue of jurisdiction to which you would avail
yourself in order to compel said entity to obey such an order.

Indeed, the reason there aren?t any court precedents to support your
position is because when hijackings have occurred, the solution has
been to contact the provider and/or upstream providers of the one
engaged in hijacking. Case in point, the incident between YouTube
and AS17557 over 208.65.153.0/24. Do you really think that the
Pakistani government would have ever punished Pakistan Telecom or
that YouTube could have obtained any useful injunctive relief in
that jurisdiction?

No, instead, they contacted PCCW and got voluntary cooperation in
no longer forwarding the announcement. This isn?t a sign of a right
of exclusion, but of a gentlemen?s agreement amongst service providers.

https://www.ripe.net/publications/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study

It would have been quite difficult for YouTube to get any sort of
injunctive relief against Pakistan Telecom. It might have been possible
for them to get injunctive relief against PCCW, but even that is iffy.

What if hundreds of other service providers had also forwarded the route?

YouTube would have needed injunctions against each and every one of them.

It?s not at all clear what happens with the ones that do operate in the US
where YouTube has the greatest likelihood of getting injunctive relief.

It?s even less clear what happens with any that are not subject to US
courts.

Owen



From owen at delong.com  Thu Mar  3 18:48:18 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 3 Mar 2016 10:48:18 -0800
Subject: About inetnum "ownership"
In-Reply-To: <56D78289.1040101@cox.net>
References: <56CADCDB.2000905@ceriz.fr>
 <CAP-guGUuJhdmZj27agTbQDk=Y+=S11GmmCxo6D9uEPHouZKTiw@mail.gmail.com>
 <6392326C-3954-4AB8-AE2D-9A617E034E9C@delong.com>
 <CAP-guGWfo6cCHqN2KAKTW1xZ2L=O0WreeuU2VcF=te-nS4SA1Q@mail.gmail.com>
 <1456899158.11868.58.camel@biplane.com.au>
 <0ad6d1b5f93eaff0ed3f89aa49ddd31c.squirrel@66.201.44.180>
 <56D78289.1040101@cox.net>
Message-ID: <BA8EE9EF-14B4-40A3-A383-E5329734B05A@delong.com>

> 
> Interesting demonstration of why retreat to analogies does not help in a discussion.
> 
> A question:  If you stop announcing your routes, where will the world get them from?
> 

In most cases, the first spammer to notice that the space is no longer announced, at least
for some period of time. ;-)

What we are discussing here, however, is some theoretical right to prevent the spammer
from doing so.

Owen


From me at nek0.net  Thu Mar  3 19:52:32 2016
From: me at nek0.net (Stanislaw)
Date: Thu, 03 Mar 2016 21:52:32 +0200
Subject: Juniper QFX5200-32C junos base services license and BGP
Message-ID: <bb5e8fd8e62cf398eae909ce76c28df9@nek0.net>

Hi,
Does anyone has a QFX5200-32C gear with a "Junos Base Services" license? 
Does that license technically allow running BGP?

Currently I have a QFX5100 which only gives me warning "This feature 
requires a license" during commit but BGP routing works fine. So I'm 
wandering if that trick works in QFX5200..

From tony at wicks.co.nz  Thu Mar  3 20:38:37 2016
From: tony at wicks.co.nz (Tony Wicks)
Date: Fri, 4 Mar 2016 09:38:37 +1300
Subject: Juniper QFX5200-32C junos base services license and BGP
In-Reply-To: <bb5e8fd8e62cf398eae909ce76c28df9@nek0.net>
References: <bb5e8fd8e62cf398eae909ce76c28df9@nek0.net>
Message-ID: <003201d1758c$ab6cf1d0$0246d570$@wicks.co.nz>

>
>Hi,
>Does anyone has a QFX5200-32C gear with a "Junos Base Services" license? 
>Does that license technically allow running BGP?
>
>Currently I have a QFX5100 which only gives me warning "This feature
requires a license" during commit but BGP routing works fine. So I'm
wandering if that trick works in QFX5200..
>

Um, you do realise that all the major vendors (including that well Known
vendor) have people on this list ? Sending a question about taking advantage
of said vendors light handed approach to licencing to this list is somewhat
less than subtle ?


From kenneth.mcrae at me.com  Fri Mar  4 00:21:07 2016
From: kenneth.mcrae at me.com (Kenneth McRae)
Date: Fri, 04 Mar 2016 00:21:07 +0000 (GMT)
Subject: Juniper QFX5200-32C junos base services license and BGP
Message-ID: <cc4a1c87-f340-42c2-9d4f-7827ef035afc@me.com>


From mark.tinka at seacom.mu  Fri Mar  4 05:51:32 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 4 Mar 2016 07:51:32 +0200
Subject: Juniper QFX5200-32C junos base services license and BGP
In-Reply-To: <003201d1758c$ab6cf1d0$0246d570$@wicks.co.nz>
References: <bb5e8fd8e62cf398eae909ce76c28df9@nek0.net>
 <003201d1758c$ab6cf1d0$0246d570$@wicks.co.nz>
Message-ID: <52dfe88a-30cc-0833-5948-7dccb22d7cd1@seacom.mu>



On 3/Mar/16 22:38, Tony Wicks wrote:

> Um, you do realise that all the major vendors (including that well Known
> vendor) have people on this list ? Sending a question about taking advantage
> of said vendors light handed approach to licencing to this list is somewhat
> less than subtle ?

I think his use of the word "trick" is what triggered your firewall :-).

He could easily re-phrase the question as "Is there any risk with
running BGP on the QFX5200 with the license warning"?

Juniper already know that a lot of operators run their kit this way.
Their only recourse is to enforce license limits in software, and we are
seeing that with later releases + newer platforms.

Mark.

From me at nek0.net  Fri Mar  4 06:19:01 2016
From: me at nek0.net (Stanislaw Datskevich)
Date: Fri, 04 Mar 2016 08:19:01 +0200
Subject: Juniper QFX5200-32C junos base services license and BGP
In-Reply-To: <52dfe88a-30cc-0833-5948-7dccb22d7cd1@seacom.mu>
References: <bb5e8fd8e62cf398eae909ce76c28df9@nek0.net>
 <003201d1758c$ab6cf1d0$0246d570$@wicks.co.nz>
 <52dfe88a-30cc-0833-5948-7dccb22d7cd1@seacom.mu>
Message-ID: <1457072341.27565.5.camel@nek0.net>

And the question is: is the QFX5200 platform that newer platform which
has license limits enforced?

It seems limits currently are "soft" as in previous platforms according
to vendor's documentation:
"Note: If you try to configure a feature that is not licensed, you will
receive syslog messages saying that you are using a feature that is
licensable and that you do not possess a license for the feature. If
you try to commit configuration changes for a feature that is not
licensed, you will receive a commit warning saying that you have
exceeded the allowed license limit for the feature."


> 
> On 3/Mar/16 22:38, Tony Wicks wrote:
> 
> > 
> > Um, you do realise that all the major vendors (including that well
> > Known
> > vendor) have people on this list ? Sending a question about taking
> > advantage
> > of said vendors light handed approach to licencing to this list is
> > somewhat
> > less than subtle ?
> I think his use of the word "trick" is what triggered your firewall
> :-).
> 
> He could easily re-phrase the question as "Is there any risk with
> running BGP on the QFX5200 with the license warning"?
> 
> Juniper already know that a lot of operators run their kit this way.
> Their only recourse is to enforce license limits in software, and we
> are
> seeing that with later releases + newer platforms.
> 
> Mark.

From colton.conor at gmail.com  Fri Mar  4 17:58:11 2016
From: colton.conor at gmail.com (Colton Conor)
Date: Fri, 4 Mar 2016 11:58:11 -0600
Subject: Samsung Networks
Message-ID: <CAMDdSzOJP1tX1fwc4fnZroxrRggqL7LGd1d2PE9H7=7kUj4GgQ@mail.gmail.com>

Does anyone have an American contact for someone in the Samsung Networks
carrier division?

From cscora at apnic.net  Fri Mar  4 18:11:11 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 5 Mar 2016 04:11:11 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201603041811.u24IBBiJ009790@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

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

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

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

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

Analysis Summary
----------------

BGP routing table entries examined:                              585390
    Prefixes after maximum aggregation (per Origin AS):          215223
    Deaggregation factor:                                          2.72
    Unique aggregates announced (without unneeded subnets):      285498
Total ASes present in the Internet Routing Table:                 52972
    Prefixes per ASN:                                             11.05
Origin-only ASes present in the Internet Routing Table:           36579
Origin ASes announcing only one prefix:                           15795
Transit ASes present in the Internet Routing Table:                6399
Transit-only ASes present in the Internet Routing Table:            162
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      39
    Max AS path prepend of ASN ( 40285)                              34
Prefixes from unregistered ASNs in the Routing Table:               997
    Unregistered ASNs in the Routing Table:                         359
Number of 32-bit ASNs allocated by the RIRs:                      12926
Number of 32-bit ASNs visible in the Routing Table:                9994
Prefixes from 32-bit ASNs in the Routing Table:                   39063
Number of bogon 32-bit ASNs visible in the Routing Table:            22
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            364
Number of addresses announced to Internet:                   2807592132
    Equivalent to 167 /8s, 88 /16s and 116 /24s
    Percentage of available address space announced:               75.8
    Percentage of allocated address space announced:               75.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.0
Total number of prefixes smaller than registry allocations:      191865

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   150343
    Total APNIC prefixes after maximum aggregation:               41580
    APNIC Deaggregation factor:                                    3.62
Prefixes being announced from the APNIC address blocks:          160214
    Unique aggregates announced from the APNIC address blocks:    64732
APNIC Region origin ASes present in the Internet Routing Table:    5145
    APNIC Prefixes per ASN:                                       31.14
APNIC Region origin ASes announcing only one prefix:               1184
APNIC Region transit ASes present in the Internet Routing Table:    912
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         39
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1915
Number of APNIC addresses announced to Internet:              752492036
    Equivalent to 44 /8s, 218 /16s and 30 /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:                    179712
    Total ARIN prefixes after maximum aggregation:                88721
    ARIN Deaggregation factor:                                     2.03
Prefixes being announced from the ARIN address blocks:           184673
    Unique aggregates announced from the ARIN address blocks:     87571
ARIN Region origin ASes present in the Internet Routing Table:    16398
    ARIN Prefixes per ASN:                                        11.26
ARIN Region origin ASes announcing only one prefix:                5891
ARIN Region transit ASes present in the Internet Routing Table:    1694
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          37
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1054
Number of ARIN addresses announced to Internet:              1102628160
    Equivalent to 65 /8s, 184 /16s and 197 /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:                    140677
    Total RIPE prefixes after maximum aggregation:                69631
    RIPE Deaggregation factor:                                     2.02
Prefixes being announced from the RIPE address blocks:           149220
    Unique aggregates announced from the RIPE address blocks:     92148
RIPE Region origin ASes present in the Internet Routing Table:    18040
    RIPE Prefixes per ASN:                                         8.27
RIPE Region origin ASes announcing only one prefix:                7948
RIPE Region transit ASes present in the Internet Routing Table:    2999
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4521
Number of RIPE addresses announced to Internet:               703167872
    Equivalent to 41 /8s, 233 /16s and 125 /24s
    Percentage of available RIPE address space announced:         102.2

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:                   61403
    Total LACNIC prefixes after maximum aggregation:              12097
    LACNIC Deaggregation factor:                                   5.08
Prefixes being announced from the LACNIC address blocks:          75069
    Unique aggregates announced from the LACNIC address blocks:   35085
LACNIC Region origin ASes present in the Internet Routing Table:   2466
    LACNIC Prefixes per ASN:                                      30.44
LACNIC Region origin ASes announcing only one prefix:               582
LACNIC Region transit ASes present in the Internet Routing Table:   552
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2315
Number of LACNIC addresses announced to Internet:             170756608
    Equivalent to 10 /8s, 45 /16s and 138 /24s
    Percentage of available LACNIC address space announced:       101.8

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:                  14081
    Total AfriNIC prefixes after maximum aggregation:              3153
    AfriNIC Deaggregation factor:                                  4.47
Prefixes being announced from the AfriNIC address blocks:         15850
    Unique aggregates announced from the AfriNIC address blocks:   5637
AfriNIC Region origin ASes present in the Internet Routing Table:   741
    AfriNIC Prefixes per ASN:                                     21.39
AfriNIC Region origin ASes announcing only one prefix:              190
AfriNIC Region transit ASes present in the Internet Routing Table:  170
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       19
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  189
Number of AfriNIC addresses announced to Internet:             78156544
    Equivalent to 4 /8s, 168 /16s and 147 /24s
    Percentage of available AfriNIC address space announced:       77.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
 4538     5593       4192          76   China Education and Research 
 7545     3204        351         184   TPG Telecom Limited
 4766     3110      11139        1099   Korea Telecom
17974     2902        914          96   PT Telekomunikasi Indonesia
 9829     2384       1449         424   National Internet Backbone
 4755     2084        431         238   TATA Communications formerly 
 9808     1850       8717          30   Guangdong Mobile Communicatio
45899     1698       1096         171   VNNIC
 4808     1641       2287         521   CNCGROUP IP network China169 
 9583     1519        121         561   Sify Limited

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     3294       2948         145   Cox Communications Inc.
 6389     2394       3687          42   BellSouth.net Inc.
18566     2211        394         276   MegaPath Corporation
20115     1914       1917         400   Charter Communications
30036     1719        341         258   Mediacom Communications Corp
 6983     1691        849         233   EarthLink, Inc.
 4323     1585       1004         392   tw telecom holdings, inc.
  209     1506       4483        1213   Qwest Communications Company,
  701     1392      11453         662   MCI Communications Services, 
11492     1266        234         595   CABLE ONE, INC.

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     2515        135           9   SaudiNet, Saudi Telecom Compa
20940     2400        924        1721   Akamai International B.V.
34984     1948        322         415   TELLCOM ILETISIM HIZMETLERI A
 8551     1230        376          54   Bezeq International-Ltd
 6849     1179        355          21   JSC "Ukrtelecom"
12479     1142        980          86   France Telecom Espana SA
 8402     1131        544          15   OJSC "Vimpelcom"
13188     1077         98          78   TOV "Bank-Inform"
31148     1041         47          41   Freenet Ltd.
 9198      900        352          25   JSC Kazakhtelecom

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     3434        540         157   Telmex Colombia S.A.
 8151     2171       3393         520   Uninet S.A. de C.V.
 7303     1520        940         237   Telecom Argentina S.A.
11830     1442        366          25   Instituto Costarricense de El
 6503     1432        437          55   Axtel, S.A.B. de C.V.
 6147     1038        377          27   Telefonica del Peru S.A.A.
28573      995       2179         154   NET Servi?os de Comunica??o S
 7738      994       1882          41   Telemar Norte Leste S.A.
26615      992       2325          34   Tim Celular S.A.
 3816      988        478         185   COLOMBIA TELECOMUNICACIONES S

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     1200        402          35   Link Egypt (Link.NET)
 8452      965       1470          11   TE-AS
37611      630         48           2   Afrihost-Brevis Computer Serv
36903      584        294         104   Office National des Postes et
36992      504       1357          25   ETISALAT MISR
37492      368        216          66   Orange Tunisie
24835      284        148          10   Vodafone Data
29571      267         21          12   Cote d'Ivoire Telecom
 2018      249        327          74   TENET (The UNINET Project)
 3741      220        821         181   Internet Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5593       4192          76   China Education and Research 
10620     3434        540         157   Telmex Colombia S.A.
22773     3294       2948         145   Cox Communications Inc.
 7545     3204        351         184   TPG Telecom Limited
 4766     3110      11139        1099   Korea Telecom
17974     2902        914          96   PT Telekomunikasi Indonesia
39891     2515        135           9   SaudiNet, Saudi Telecom Compa
20940     2400        924        1721   Akamai International B.V.
 6389     2394       3687          42   BellSouth.net Inc.
 9829     2384       1449         424   National Internet Backbone

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
10620      3434        3277      Telmex Colombia S.A.
22773      3294        3149      Cox Communications Inc.
 7545      3204        3020      TPG Telecom Limited
17974      2902        2806      PT Telekomunikasi Indonesia
39891      2515        2506      SaudiNet, Saudi Telecom Compa
 6389      2394        2352      BellSouth.net Inc.
 4766      3110        2011      Korea Telecom
 9829      2384        1960      National Internet Backbone
18566      2211        1935      MegaPath Corporation
 4755      2084        1846      TATA Communications formerly 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
65001   PRIVATE      5.143.176.0/20       15468       OJSC Rostelecom
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         3356       Level 3 Communicatio
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
16589   UNALLOCATED  8.20.247.0/24        35838       CCANET Limited
16589   UNALLOCATED  8.26.56.0/24         35838       CCANET Limited
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.
37.46.15.0/24        36351     SoftLayer Technologies Inc.
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.3.0/24         37004     >>UNKNOWN<<
41.73.4.0/24         37004     >>UNKNOWN<<

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:101     /12:267     
/13:515     /14:1028    /15:1761    /16:12975   /17:7514    /18:12608   
/19:25651   /20:38075   /21:40110   /22:65185   /23:56178   /24:321744  
/25:552     /26:585     /27:406     /28:18      /29:16      /30:13      
/31:0       /32:23      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2476          3294      Cox Communications Inc.
39891     2472          2515      SaudiNet, Saudi Telecom Compa
18566     2113          2211      MegaPath Corporation
30036     1534          1719      Mediacom Communications Corp
 6389     1521          2394      BellSouth.net Inc.
 6983     1341          1691      EarthLink, Inc.
10620     1327          3434      Telmex Colombia S.A.
34984     1237          1948      TELLCOM ILETISIM HIZMETLERI A
11492     1176          1266      CABLE ONE, INC.
 6849      997          1179      JSC "Ukrtelecom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1619      2:736       4:20        5:2101      6:26        8:916    
  12:1782     13:38       14:1678     15:35       16:2        17:68     
  18:20       20:48       23:1381     24:1745     27:2255     31:1703   
  32:54       33:2        34:2        35:4        36:237      37:2336   
  38:1175     39:26       40:87       41:2926     42:385      43:1672   
  44:41       45:1716     46:2423     47:69       49:1124     50:843    
  51:3        52:80       54:197      55:3        56:6        57:44     
  58:1512     59:857      60:566      61:1795     62:1432     63:1924   
  64:4457     65:2155     66:4057     67:2101     68:1101     69:3323   
  70:1041     71:466      72:1977     74:2540     75:356      76:432    
  77:1378     78:1291     79:827      80:1315     81:1363     82:911    
  83:676      84:792      85:1569     86:470      87:1047     88:571    
  89:1942     90:167      91:6045     92:854      93:2300     94:2363   
  95:2288     96:470      97:355      98:956      99:45      100:69     
 101:992     103:9868    104:2206    105:130     106:391     107:1145   
 108:653     109:2119    110:1258    111:1612    112:936     113:1278   
 114:1117    115:1688    116:1527    117:1418    118:2126    119:1573   
 120:511     121:1161    122:2231    123:2018    124:1595    125:1757   
 128:729     129:372     130:430     131:1273    132:600     133:171    
 134:448     135:122     136:352     137:332     138:1711    139:205    
 140:249     141:464     142:630     143:864     144:602     145:160    
 146:832     147:604     148:1456    149:473     150:660     151:820    
 152:603     153:270     154:537     155:899     156:487     157:440    
 158:344     159:1097    160:425     161:735     162:2290    163:529    
 164:727     165:1119    166:313     167:1062    168:1555    169:607    
 170:1504    171:273     172:467     173:1648    174:722     175:876    
 176:1509    177:4003    178:2222    179:1093    180:2107    181:1641   
 182:1949    183:686     184:794     185:5842    186:3039    187:2017   
 188:2096    189:1730    190:7606    191:1227    192:8910    193:5717   
 194:4366    195:3760    196:1630    197:1148    198:5516    199:5583   
 200:6853    201:3707    202:10132   203:9591    204:4623    205:2706   
 206:2980    207:3064    208:4057    209:3885    210:3964    211:2015   
 212:2665    213:2160    214:811     215:73      216:5724    217:1908   
 218:759     219:565     220:1665    221:851     222:678     223:935    


End of report

From admin at coldnorthadmin.com  Sat Mar  5 21:19:40 2016
From: admin at coldnorthadmin.com (Laurent Dumont)
Date: Sat, 5 Mar 2016 16:19:40 -0500
Subject: IPV6 planning
Message-ID: <56DB4D6C.9080504@coldnorthadmin.com>

Hiya,

We are currently considering deploying IPv6 for a Lan event in April. We 
are assigned a /48 which we then split into smaller subnets for each 
player vlan. That said, what remains to be decided is how we are going 
to assign the IPv6. Basically, it seems that are two ways, one SLAAC 
where the endpoints uses RA to generate it's own IP and DHCPv6 which is 
basically DHCP but for IPv6.

Large events like Dreamhack have used SLAAC and the feedback has been 
mostly positive. Can anyone comment regarding past experiences with IPv6 
gotchas and things that you don't really expect when running dual-stack 
on a large-ish network?

Thanks!

Laurent

From mark.tinka at seacom.mu  Sat Mar  5 21:46:59 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sat, 5 Mar 2016 23:46:59 +0200
Subject: IPV6 planning
In-Reply-To: <56DB4D6C.9080504@coldnorthadmin.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
Message-ID: <f29836b7-3c60-452e-bd8d-6289f39e2a1f@seacom.mu>



On 5/Mar/16 23:19, Laurent Dumont wrote:

> Hiya,
>
> We are currently considering deploying IPv6 for a Lan event in April.
> We are assigned a /48 which we then split into smaller subnets for
> each player vlan. That said, what remains to be decided is how we are
> going to assign the IPv6. Basically, it seems that are two ways, one
> SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6
> which is basically DHCP but for IPv6.
>
> Large events like Dreamhack have used SLAAC and the feedback has been
> mostly positive. Can anyone comment regarding past experiences with
> IPv6 gotchas and things that you don't really expect when running
> dual-stack on a large-ish network?

SLAAC is the way you want to do, as DHCPv6 does not give you a default
gateway.

If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a
hybrid of DHCPv6 and SLAAC is reasonable.

Mark.

From Valdis.Kletnieks at vt.edu  Sat Mar  5 21:54:58 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 05 Mar 2016 16:54:58 -0500
Subject: IPV6 planning
In-Reply-To: <f29836b7-3c60-452e-bd8d-6289f39e2a1f@seacom.mu>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <f29836b7-3c60-452e-bd8d-6289f39e2a1f@seacom.mu>
Message-ID: <77020.1457214898@turing-police.cc.vt.edu>

On Sat, 05 Mar 2016 23:46:59 +0200, Mark Tinka said:

> If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a
> hybrid of DHCPv6 and SLAAC is reasonable.

And note that there isn't any problem with a machine getting an IPv6 address
via SLAAC *and* getting another one via DHCPv6 - my laptop is doing that as I
type (plus a privacy address or two as well).

-------------- 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/20160305/a9086446/attachment.pgp>

From baldur.norddahl at gmail.com  Sat Mar  5 22:30:10 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Sat, 5 Mar 2016 23:30:10 +0100
Subject: IPV6 planning
In-Reply-To: <77020.1457214898@turing-police.cc.vt.edu>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <f29836b7-3c60-452e-bd8d-6289f39e2a1f@seacom.mu>
 <77020.1457214898@turing-police.cc.vt.edu>
Message-ID: <CAPkb-7CPphnuTcfAeouzOAkc6C630GgZDDhOV_NXFfzWnbeDaQ@mail.gmail.com>

On 5 March 2016 at 22:54, <Valdis.Kletnieks at vt.edu> wrote:

> And note that there isn't any problem with a machine getting an IPv6
> address
> via SLAAC *and* getting another one via DHCPv6 - my laptop is doing that
> as I
> type (plus a privacy address or two as well).
>
>
That is what our CPEs (from Inteno) do. Every computer has a DHCPv6
assigned address that is short and easy (my laptop has 2a00:7660:5c6::30e).
The DHCPv6 assigned address is also stable. In the CPE admin website the
user can pick the computer (DHCPv6 assigned address) from a dropdown when
configuring inbound firewall rules. It is very easy to eg. allow SSH to my
laptop by using this feature.

But every computer also have SLAAC and usually with privacy extensions. My
laptop prefers the SLAAC/privacy address for outgoing connections. So I am
not as easily tracked as if the computer used the DHCPv6 address. Currently
my outgoing connections are from 2a00:7660:5c6::bd7d:624c:2d8c:c8d0 but
this will change shortly to something new and random.

Short and stable for inbound, random for outbound.

Regards,

Baldur

From kauer at biplane.com.au  Sat Mar  5 22:59:50 2016
From: kauer at biplane.com.au (Karl Auer)
Date: Sun, 06 Mar 2016 09:59:50 +1100
Subject: IPV6 planning
In-Reply-To: <56DB4D6C.9080504@coldnorthadmin.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
Message-ID: <1457218790.2036.33.camel@biplane.com.au>

On Sat, 2016-03-05 at 16:19 -0500, Laurent Dumont wrote:
> We are currently considering deploying IPv6 for a Lan event in April.
> We are assigned a /48 which we then split into smaller subnets for 
> each player vlan. That said, what remains to be decided is how we are 
> going to assign the IPv6. Basically, it seems that are two ways, one 
> SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6 
> which is basically DHCP but for IPv6.

SLAAC is way easier:
 - no DHCPv6 server is required
 - every IPv6-capable device can do it
 - you only have to configure the router

With SLAAC you don't get DNS names, whereas DHCPv6 can update the DNS
for you. You can let player hosts update the DNS directly, but it's
more open to abuse. Or maybe you don't need names anyway.

Other thing with SLAAC is that you get 64-bit subnets and only 64-bit
subnets. This should not be any kind of problem with a flat /48, but if
you will have more complicated subnetting you should keep an eye on it.

Unless you take steps to prevent SLAAC happening, SLAAC will happen.
The simplest way to prevent it happening is to allocate non-64-bit
subnets to the router interfaces.

The biggest gotcha (or gotchas) you will face is/are buggy IPv6
implementations on the router/switch side - especially the switches. A
small test setup to make sure that your expected host operating systems
all work as expected with your planned network infrastructure would be
a Very Good Idea.

Second biggest gotcha will be forgetting to secure IPv6. IPv6 packet
filters, firewall rules etc are all completely separate and independent
from your IPv4 stuff.

Third gotcha - related to the second - is forgetting that your IPv6
-connected hosts are not behind NAT and are thus directly exposed to
the Internet via IPv6 unless you take steps to make it not so. You
should probably provide at least the same basic setup for IPv6 on your
outside router interfaces that NAT provides for IPv4, plus ICMPv6.
I.e.:
 - allow established/related inbound
 - allow all ICMPv6
 - allow all outbound
 - block all inbound

A possible gotcha is people using temporary or privacy IPv6 addressing,
which is the default on many modern operating systems. Addresses change
- on boot for temporary addresses, at regular intervals. Whether that
will be a problem or not depends on whether the hosts will be using
long-lived connections.
 
You may find that some participants have disabled IPv6. Since you are
dual stack this shouldn't be an issue, unless your IPv6 connectivity is
faster than your IPv4 connectivity. Might be worth getting up to speed
on how to enable/disable IPv6 on various operating systems so that you
can advise people.

Regards, K.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4




From saku at ytti.fi  Sat Mar  5 23:57:54 2016
From: saku at ytti.fi (Saku Ytti)
Date: Sun, 6 Mar 2016 01:57:54 +0200
Subject: IPV6 planning
In-Reply-To: <1457218790.2036.33.camel@biplane.com.au>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
Message-ID: <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>

On 6 March 2016 at 00:59, Karl Auer <kauer at biplane.com.au> wrote:
> Other thing with SLAAC is that you get 64-bit subnets and only 64-bit
> subnets. This should not be any kind of problem with a flat /48, but if
> you will have more complicated subnetting you should keep an eye on it.

Technically speaking there is no reason not to support SLAAC on
arbitrary size networks. I believe Cisco happily will autogenerate
address for smaller subnets.

-- 
  ++ytti

From kauer at biplane.com.au  Sun Mar  6 01:08:55 2016
From: kauer at biplane.com.au (Karl Auer)
Date: Sun, 06 Mar 2016 12:08:55 +1100
Subject: IPV6 planning
In-Reply-To: <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
Message-ID: <1457226535.2036.75.camel@biplane.com.au>

On Sun, 2016-03-06 at 01:57 +0200, Saku Ytti wrote:
> Technically speaking there is no reason not to support SLAAC on
> arbitrary size networks. I believe Cisco happily will autogenerate
> address for smaller subnets.

To support SLAAC with prefix lengths other than 64 you would have to
break numerous standards. RFC2464 is very clear on the matter, at least
for Ethernet interfaces, though RFC 4862 is carefully non-committal. 

Even if the router supports it, as far as I know a standards-conforming
host MUST ignore such prefixes for purposes of SLAAC on Ethernet.

As far as "technically speaking" goes, recall that the host generates
its own address; the only information supplied by the router is the
prefix and an A flag. There is no way for the router to tell hosts
*how* to generate the address. The hosts would have work out where in
the shorter (or longer) prefix the MAC address should go. If the prefix
is too short the hosts would have to work out which bits to discard,
and would have to work out which bit (if any) should be complemented to
indicate local vs global assignment. Might be a good idea to keep least
significant bits, to minimise impacts on solicited node multicast
addresses. Dunno what would happen to solicited node multicast if you
increased the prefix length beyond 104.

Temporary and privacy addresses might be easier - all you would need to
do would be randomise whatever bits were available to you, though as
prefixes got longer your protection would decrease.

There might be more to it than that - haven't really thought it
through.

So to change the prefix length for SLAAC I think you would have to own
the whole ecosystem including host stacks. So while Cisco may support
it on router interfaces, I suspect it wouldn't actually *work* in
practice. But I have been wrong oh, so many times...

Regards, K.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4




From hugo at slabnet.com  Sun Mar  6 05:46:02 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Sat, 5 Mar 2016 21:46:02 -0800
Subject: IPV6 planning
In-Reply-To: <CAPkb-7CPphnuTcfAeouzOAkc6C630GgZDDhOV_NXFfzWnbeDaQ@mail.gmail.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <f29836b7-3c60-452e-bd8d-6289f39e2a1f@seacom.mu>
 <77020.1457214898@turing-police.cc.vt.edu>
 <CAPkb-7CPphnuTcfAeouzOAkc6C630GgZDDhOV_NXFfzWnbeDaQ@mail.gmail.com>
Message-ID: <20160306054602.GC7387@slab-wks-04.int.slabnet.com>

On Sat 2016-Mar-05 23:30:10 +0100, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:

>On 5 March 2016 at 22:54, <Valdis.Kletnieks at vt.edu> wrote:
>
>> And note that there isn't any problem with a machine getting an IPv6
>> address via SLAAC *and* getting another one via DHCPv6 - my laptop is 
>> doing that as I type (plus a privacy address or two as well).
>>
>That is what our CPEs (from Inteno) do. Every computer has a DHCPv6
>assigned address that is short and easy (my laptop has 2a00:7660:5c6::30e).
>The DHCPv6 assigned address is also stable. In the CPE admin website the
>user can pick the computer (DHCPv6 assigned address) from a dropdown when
>configuring inbound firewall rules. It is very easy to eg. allow SSH to my
>laptop by using this feature.
>
>But every computer also have SLAAC and usually with privacy extensions. My
>laptop prefers the SLAAC/privacy address for outgoing connections. So I am
>not as easily tracked as if the computer used the DHCPv6 address. Currently
>my outgoing connections are from 2a00:7660:5c6::bd7d:624c:2d8c:c8d0 but
>this will change shortly to something new and random.
>
>Short and stable for inbound, random for outbound.

Just because this often seems to get overlooked:

In a SLAAC-only environment, even with privacy extensions enabled, client 
operating systems still generate a stable address for inbound 
connections...at least the ones I generally interact with and that you'd be 
likely to find in a LAN event.  For Linux and OS X, this will be an EUI-64 
address; Microsoft decided to be special and generates a random interface 
ID for this rather than use EUI-64, but that random interface ID is still 
stable.

This doesn't get you the "short" part of the "short and stable for inbound, 
random for outbound" DHCPv6 + SLAAC w/ privacy addresses scenario, but it 
does get you "stable for inbound" as well as "random for outbound", since 
privacy/temporary addresses are still preferred for outbound.

You don't get the benefit of the CPE being aware of the user's stable 
address in a nice, user-friendly drop-down, but that's your call wrt how 
much value that provides.

Back to the original question:

>>>>Basically, it seems that are two ways, one SLAAC where the endpoints 
>>>>uses RA to generate it's own IP and DHCPv6 which is basically DHCP but 
>>>>for IPv6.

Pretty much, but with some nuances.

At the very least, you will want:

1.  an IPv6 address
2.  a default gateway
3.  resolvers and possibly a dns domain / search suffix

Assuming you're not making everyone do static config, your options for #1 
are:
i)   stateful DHCPv6 (IA_NA)
ii)  SLAAC, with the assumption that your users will in all likelihood have 
privacy extension enabled

#2, as has already been stated, comes from your RA.

#3 is the trick.  You *can* technically get resolver info from the RA with 
RDNSS, but that assumes (a) your network gear can put RDNSS in its RAs and 
(b) your clients all support RDNSS.  You still can't bank on either of 
those.  So, that means you're running stateless DHCPv6 for resolver info.  

...or, given that you're going dual-stack, you can be a lazy bum, assume 
everyone will be dual stack and do DHCPv4 as well, and stick resolver info 
in your DHCPv4 options and call it a day...but then we'd have to hunt you 
down for IPv6 heresy, plus if you have any single-stack v6 users, you're 
leaving them out in the cold.

My personal recommendation/preference:
SLAAC + stateless DHCPv6, plus RDNSS if your network gear supports it 
because why not,
i.e. RA flags are: M=0 & O=1, and A=1 for your onlink prefix.

>>>>Large events like Dreamhack have used SLAAC and the feedback has been 
>>>>mostly positive. Can anyone comment regarding past experiences with 
>>>>IPv6 gotchas and things that you don't really expect when running 
>>>>dual-stack on a large-ish network?

Karl already pointed out some good bits.

>>>Unless you take steps to prevent SLAAC happening, SLAAC will happen.
>>>The simplest way to prevent it happening is to allocate non-64-bit
>>>subnets to the router interfaces.

...or don't set the A flag in your RAs and hope the clients respect that; 
I've not personally run big issues with clients going all SLAAC-y when A=0, 
but due diligence etc.

>>> - allow all ICMPv6

Folks that haven't pushed out v6 nets yet often miss this one.  Friends 
don't let friends break PMTUD.  If people get all uppity about allowing in 
ICMPv6 from the WAN side because they're used to discarding WAN-side ping 
in v4 and you can't put your foot down heavy enough, at *least* get them to 
give you ICMPv6 types 1-4 and 128,129 inbound.

Whether or not temporary addresses are a concern for your LAN event are a 
factor of how long-lived sessions need to be for your application(s) and 
how your clients are config'd.  You can't guarantee the clients' configs 
for TEMP_VALID_LIFETIME, though if they haven't futzed with it that should 
be a week.

Cheers, and here's wishing you a great event!

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160305/41fa2df3/attachment.pgp>

From saku at ytti.fi  Sun Mar  6 11:53:27 2016
From: saku at ytti.fi (Saku Ytti)
Date: Sun, 6 Mar 2016 13:53:27 +0200
Subject: IPV6 planning
In-Reply-To: <1457226535.2036.75.camel@biplane.com.au>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
Message-ID: <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>

On 6 March 2016 at 03:08, Karl Auer <kauer at biplane.com.au> wrote:
> To support SLAAC with prefix lengths other than 64 you would have to
> break numerous standards. RFC2464 is very clear on the matter, at least
> for Ethernet interfaces, though RFC 4862 is carefully non-committal.

Yes, SLAAC, 4862 clearly does not forbid it, and there is no technical reason.
But as you state, 2464 does not specify other behaviour. Writing new
draft which specifies behaviour for arbitrary size wouldn't be a
challenge, marketing it might be.

>From implementation POV, arbitrary prefix-size from 4862 is fairly
obvious and logical, and dictating 64 is very weird, with no obvious
benefits at all. I suspect the 64 must have come into IPv6 ethernet
standard before people thought of DAD, and assumption was uniqueness
was guaranteed by use of BIA (HAH!), that's only background that I can
imagine where mandating /64 might be remotely sane thought process.
Post-DAD it's just artificial complexity which reduces expressiveness.

> Even if the router supports it, as far as I know a standards-conforming
> host MUST ignore such prefixes for purposes of SLAAC on Ethernet.

I can't recall where it would be worded so harshly. But I agree that
it's not good idea /NOW/ to use it, even if it works on some
implementations.


-- 
  ++ytti

From tore at fud.no  Sun Mar  6 12:10:09 2016
From: tore at fud.no (Tore Anderson)
Date: Sun, 6 Mar 2016 13:10:09 +0100
Subject: IPV6 planning
In-Reply-To: <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
Message-ID: <20160306131009.720b5de7@envy.w5.y.home>

* Saku Ytti

> Yes, SLAAC, 4862 clearly does not forbid it, and there is no
> technical reason. But as you state, 2464 does not specify other
> behaviour. Writing new draft which specifies behaviour for arbitrary
> size wouldn't be a challenge, marketing it might be.

FYI: RFC 7421 is an in-depth discussion of the fixed 64-bit boundary.

Tore


From kauer at biplane.com.au  Sun Mar  6 12:39:49 2016
From: kauer at biplane.com.au (Karl Auer)
Date: Sun, 06 Mar 2016 23:39:49 +1100
Subject: IPV6 planning
In-Reply-To: <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
Message-ID: <1457267989.5152.23.camel@biplane.com.au>

On Sun, 2016-03-06 at 13:53 +0200, Saku Ytti wrote:
> Yes, SLAAC, 4862 clearly does not forbid it, and there is no
> technical reason.

Well - yes, there are some, and I think I pointed out several.

> Writing new
> draft which specifies behaviour for arbitrary size wouldn't be a
> challenge

I think you may find it more difficult than you think. But by all means
write that draft.

> From implementation POV, arbitrary prefix-size from 4862 is fairly
> obvious and logical, and dictating 64 is very weird, with no obvious
> benefits at all.

/64 has a lot of benefits (some one which would be shared by any fixed
-length prefix, some not), but I'm not sure detailing them here would
be appreciated. They've all been gone over at length here and elsewhere
many times before. As Tore just wrote before I finished this :-)
there's even a collected summary of many of pros and cons in RFC 7421,
which by the way has lots of good references.

> that's only background that I can imagine where mandating /64 might 
> be remotely sane thought process.

The argument from personal incomprehension is not a very powerful one.

> I can't recall where it would be worded so harshly.

Dunno about "harsh", but RFC 2464, section 4 says that the prefix must
be 64 bits. By (extremely strong) implication, a host must not use a
prefix of any other length to perform SLAAC. I say "extremely strong"
because the entire description of how an IPv6 Ethernet interface
identifier is formed depends on it being composed of the prefix plus an
EUI-64 identifier. Later RFCs firm up the requirement and apply it in
other contexts.

BUT: Other prefix lengths are fine for anything except automatically
formed interface identifiers, as far as I know.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4




From joly at punkcast.com  Sun Mar  6 21:53:04 2016
From: joly at punkcast.com (Joly MacFie)
Date: Sun, 6 Mar 2016 16:53:04 -0500
Subject: Fwd: Seeking ISP contacts @ Sabey NYC
Message-ID: <CAM9VJk29_oJ-bDBtsf-e=XcGfhYRgLh9gKPTXHksvYOZxAcrSg@mail.gmail.com>

Please could appropriate reps from the listed companies contact David below
offlist. Thanks.

j

---------- Forwarded message ----------
From: David Solomonoff <president at isoc-ny.org>
Date: Sun, Mar 6, 2016 at 2:18 PM
Cc: NYC Mesh <nycmeshmail at gmail.com>


The NY Chapter of the Internet Society is acting as a fiscal sponsor for
NYC Mesh, a wireless community network in lower Manhattan, Brooklyn and
Jersey City.

They are currently arranging for rack space and rooftop antennas
??
at the Sabey data center in lower Manhattan.

ISP's at Sabey include:

1.         Lightpath
2.         Lightower/ Sidera
3.         Axiom Fiber
4.         Level 3
5.         OCG
6.         Time Warner
7.         XO Communications
8.         Verizon
9.         United Fiber Data
10.        Zayo/AboveNet
11.        Earthlink
12.        IGX ? Sabey owned/managed (Cogent!)

I'd appreciate any leads for  contacts at these companies with whom we
could negotiate a discount or donation of services to a tax-exempt
nonprofit.

Thanks,

David

-- 
David Solomonoff, President
Internet Society of New Yorkpresident at isoc-ny.orgisoc-ny.org


-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
--------------------------------------------------------------
-

From baldur.norddahl at gmail.com  Mon Mar  7 01:57:44 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Mon, 7 Mar 2016 02:57:44 +0100
Subject: IPV6 planning
In-Reply-To: <1457267989.5152.23.camel@biplane.com.au>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
Message-ID: <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>

Den 6. mar. 2016 13.41 skrev "Karl Auer" <kauer at biplane.com.au>:

> Dunno about "harsh", but RFC 2464, section 4 says that the prefix must
> be 64 bits. By (extremely strong) implication, a host must not use a
> prefix of any other length to perform SLAAC. I say "extremely strong"
> because the entire description of how an IPv6 Ethernet interface
> identifier is formed depends on it being composed of the prefix plus an
> EUI-64 identifier. Later RFCs firm up the requirement and apply it in
> other contexts.

But the most popular OS (Windows) completely ignores all of that and makes
up an identifier not based on EUI-64. Everyone are happy anyway. The RFC
should have let identifier selection as an implementation detail as the
risk of collision is almost non existent given a sufficient random
selection and we have duplicate address detection as a safeguard.

Regards

Baldur

From daniel at nodesdirect.com  Tue Mar  1 23:53:24 2016
From: daniel at nodesdirect.com (Daniel Stephens)
Date: Tue, 1 Mar 2016 23:53:24 +0000
Subject: Netflix VPN Detection Issues
In-Reply-To: <SN1PR01MB16474E041E3D75764556765EB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
References: <SN1PR01MB16474E041E3D75764556765EB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
Message-ID: <SN1PR01MB16475D8CBEE1C04B4FEB953FB2BB0@SN1PR01MB1647.prod.exchangelabs.com>

Hello,

Can someone from Netflix contact me off-list to assist in a wrongly classified prefix as a VPN/proxy? We serve Internet to a few large residential communities and they have been blocked as of yesterday afternoon. Attempts to cdnetops@ have been unsuccessful.

Thank you,

Daniel Stephens


From frnkblk at iname.com  Mon Mar  7 00:23:34 2016
From: frnkblk at iname.com (frnkblk at iname.com)
Date: Sun, 6 Mar 2016 18:23:34 -0600
Subject: IPV6 planning
In-Reply-To: <1457218790.2036.33.camel@biplane.com.au>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
Message-ID: <001801d17807$973da9c0$c5b8fd40$@iname.com>

Just to amplify what Hugo wrote, there is DNS support with SLAAC (see RFC 6106), but router and client support mixed. In the end, I would recommend support DHCPv6 and SLAAC, and if your router support RFC 6106, stuff the DNS information in there, too.

Frank

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Karl Auer
Sent: Saturday, March 05, 2016 5:00 PM
To: nanog at nanog.org
Subject: Re: IPV6 planning

On Sat, 2016-03-05 at 16:19 -0500, Laurent Dumont wrote:
> We are currently considering deploying IPv6 for a Lan event in April.
> We are assigned a /48 which we then split into smaller subnets for 
> each player vlan. That said, what remains to be decided is how we are 
> going to assign the IPv6. Basically, it seems that are two ways, one 
> SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6 
> which is basically DHCP but for IPv6.

SLAAC is way easier:
 - no DHCPv6 server is required
 - every IPv6-capable device can do it
 - you only have to configure the router

With SLAAC you don't get DNS names, whereas DHCPv6 can update the DNS
for you. You can let player hosts update the DNS directly, but it's
more open to abuse. Or maybe you don't need names anyway.

Other thing with SLAAC is that you get 64-bit subnets and only 64-bit
subnets. This should not be any kind of problem with a flat /48, but if
you will have more complicated subnetting you should keep an eye on it.

Unless you take steps to prevent SLAAC happening, SLAAC will happen.
The simplest way to prevent it happening is to allocate non-64-bit
subnets to the router interfaces.

The biggest gotcha (or gotchas) you will face is/are buggy IPv6
implementations on the router/switch side - especially the switches. A
small test setup to make sure that your expected host operating systems
all work as expected with your planned network infrastructure would be
a Very Good Idea.

Second biggest gotcha will be forgetting to secure IPv6. IPv6 packet
filters, firewall rules etc are all completely separate and independent
from your IPv4 stuff.

Third gotcha - related to the second - is forgetting that your IPv6
-connected hosts are not behind NAT and are thus directly exposed to
the Internet via IPv6 unless you take steps to make it not so. You
should probably provide at least the same basic setup for IPv6 on your
outside router interfaces that NAT provides for IPv4, plus ICMPv6.
I.e.:
 - allow established/related inbound
 - allow all ICMPv6
 - allow all outbound
 - block all inbound

A possible gotcha is people using temporary or privacy IPv6 addressing,
which is the default on many modern operating systems. Addresses change
- on boot for temporary addresses, at regular intervals. Whether that
will be a problem or not depends on whether the hosts will be using
long-lived connections.
 
You may find that some participants have disabled IPv6. Since you are
dual stack this shouldn't be an issue, unless your IPv6 connectivity is
faster than your IPv4 connectivity. Might be worth getting up to speed
on how to enable/disable IPv6 on various operating systems so that you
can advise people.

Regards, K.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4






From landsidel.allen at gmail.com  Sat Mar  5 17:24:31 2016
From: landsidel.allen at gmail.com (Allen Landsidel)
Date: Sat, 5 Mar 2016 12:24:31 -0500
Subject: Cogent / Cloudflare / AS13335
Message-ID: <CACN5WQwC1bHO=HiPnE6K_0r5cqNkK2e9SST5p=6aHHjvZ_PsiQ@mail.gmail.com>

Any known issues here?  Multiple websites on cloudflare IPs in that AS are
currently unreachable (connection timeout) through metrocast cable in NH.
Traceroutes always end up the same, going through 38.104.44.10.  Three
example traceroutes here: http://pastebin.com/tBQbsj4w

Emailed cloudflare support and used cogents contact form a few hours ago,
no response yet.  The sites respond correctly when reached through
alternate routes like telia.

From mnathani.lists at gmail.com  Mon Mar  7 02:59:28 2016
From: mnathani.lists at gmail.com (Mansoor Nathani)
Date: Sun, 6 Mar 2016 21:59:28 -0500
Subject: Netflix VPN Detection Issues
In-Reply-To: <SN1PR01MB16475D8CBEE1C04B4FEB953FB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
References: <SN1PR01MB16474E041E3D75764556765EB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
 <SN1PR01MB16475D8CBEE1C04B4FEB953FB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
Message-ID: <CACumZjwp6_GqtNi+aQJzDP8wDb1cVvQOM=Pd5G3VxA3yWGG9Tw@mail.gmail.com>

Just curious as to why this email was delayed 5 days?

Mansoor

On Tue, Mar 1, 2016 at 6:53 PM, Daniel Stephens <daniel at nodesdirect.com>
wrote:

> Hello,
>
> Can someone from Netflix contact me off-list to assist in a wrongly
> classified prefix as a VPN/proxy? We serve Internet to a few large
> residential communities and they have been blocked as of yesterday
> afternoon. Attempts to cdnetops@ have been unsuccessful.
>
> Thank you,
>
> Daniel Stephens
>
>

From kauer at biplane.com.au  Mon Mar  7 03:01:53 2016
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 07 Mar 2016 14:01:53 +1100
Subject: IPV6 planning
In-Reply-To: <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
 <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
Message-ID: <1457319713.5152.106.camel@biplane.com.au>

On Mon, 2016-03-07 at 02:57 +0100, Baldur Norddahl wrote:
> But the most popular OS (Windows) completely ignores all of that and
> makes up an identifier not based on EUI-64. Everyone are happy 
> anyway. The RFC should have let identifier selection as an 
> implementation detail as the risk of collision is almost non existent 
> given a sufficient random selection and we have duplicate address
> detection as a safeguard.

Privacy and temporary addresses are two of the three SLAAC types. One
critical requirement for the original SLAAC is that the address doesn't
change; for devices without writable storage, that requires a
deterministic algorithm to generate the address. A further critical
requirement was that devices be able to get connected with zero host co
nfiguration - globally and locally.

For temporary and privacy addresses, where permanence is not an issue,
you can use any prefix length, though as I said in my original
response, your protection diminishes the longer the prefix gets.

I'm not trying to be an apologist for those who designed IPv6, but I
really don't think they were stupid, and it's not as simple a situation
as people seem to think.

My initial response was to someone who said they thought Cisco
supported varying prefix lengths with SLAAC. I said it wan't just up to
Cisco, the hosts had to play ball too, and I don't think they do. But,
as already noted, I could be wrong :-)

Regards, K.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4




From rsk at gsp.org  Mon Mar  7 13:33:47 2016
From: rsk at gsp.org (Rich Kulawiec)
Date: Mon, 7 Mar 2016 08:33:47 -0500
Subject: Fwd: [jari.arkko@piuha.net: Ray Tomlinson]
Message-ID: <20160307133347.GA25576@gsp.org>

Forward from the main IETF mailing list.
Includes comments from Craig Partridge and Vint Cerf.

---rsk

----- Forwarded message from Jari Arkko <jari.arkko at piuha.net> -----

> From: Jari Arkko <jari.arkko at piuha.net>
> Date: Sun, 6 Mar 2016 11:02:13 +0000
> To: IETF <ietf at ietf.org>
> Subject: Ray Tomlinson
> 
> I received sad news about Ray Tomlinson?s death from Craig Partridge
> and Vint Cerf yesterday. I wanted to send what they wrote to the IETF
> list as well:
> 
> > I just learned that Ray Tomlinson died this morning.
> > 
> > Ray Tomlinson had been at BBN since 1967.  He?s best known for
> > inventing the concept of sending email over a computer network and
> > choosing the @ sign as the way to split the mailbox name from the host
> > name.  But that?s a fraction of his amazing contributions to our field.
> > Ray was one of a four person team that created TENEX, the first operating
> > system to support virtual memory using paging. He wrote one of the
> > first implementations of TCP and, when he found data being duplicated
> > in the received stream, devised methods to ensure that sequence numbers
> > were not duplicated that remain fundamental to TCP/IP implementations
> > today. He worked on the first object-oriented distributed system and
> > early multimedia email systems.  And I?m sure I?m forgetting at least
> > half a dozen other ways Ray made our world better.
> > 
> > Craig
> 
> > I knew and worked with Ray Tomlinson during the development of
> > the ARPANET and its host protocols and benefited, as have billions,
> > from his seminal work on networked electronic email. More important,
> > from my personal perspective, was his work with Bill Plummer on the
> > first PDP-10 TENEX implementation of TCP (and later TCP/IP). In 1975, he
> > discovered that the TCP as specified in December 1974 had flaws that led
> > it to fail to detect duplicate packets and, together with Yogen Dalal,
> > developed the three-way handshake and initial sequence number selection
> > method to solve this problem. As Craig Partridge summarizes, Ray was a
> > long-time and creative contributor to the Internet, operating systems,
> > and many other highly practical applications in the computer science
> > and communications domains. He was a self-effacing and humble man and
> > extraordinary performer in our online world. I will miss his thoughtful,
> > low-key and always helpful counsel.
> > 
> > vint
> 
> Jari Arkko
> 

----- End forwarded message -----

From dave at temk.in  Mon Mar  7 13:53:30 2016
From: dave at temk.in (Dave Temkin)
Date: Mon, 7 Mar 2016 08:53:30 -0500
Subject: Netflix VPN Detection Issues
In-Reply-To: <SN1PR01MB16475D8CBEE1C04B4FEB953FB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
References: <SN1PR01MB16474E041E3D75764556765EB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
 <SN1PR01MB16475D8CBEE1C04B4FEB953FB2BB0@SN1PR01MB1647.prod.exchangelabs.com>
Message-ID: <CAFJiuFp6kZ8LFyN2WpGO+ztxCPStaUTNomtm6aHyyxwftCZuSQ@mail.gmail.com>

Daniel,

I don't see any emails from *.nodesdirect aside from a peering request from
a long time ago. Feel free to email me directly with the IP ranges in
question and I'll make sure they get looked at.

-Dave

On Tue, Mar 1, 2016 at 6:53 PM, Daniel Stephens <daniel at nodesdirect.com>
wrote:

> Hello,
>
> Can someone from Netflix contact me off-list to assist in a wrongly
> classified prefix as a VPN/proxy? We serve Internet to a few large
> residential communities and they have been blocked as of yesterday
> afternoon. Attempts to cdnetops@ have been unsuccessful.
>
> Thank you,
>
> Daniel Stephens
>
>

From jra at baylink.com  Mon Mar  7 16:06:16 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Mon, 7 Mar 2016 16:06:16 +0000 (UTC)
Subject: Thank you, Comcast.
In-Reply-To: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck>
References: <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck>
Message-ID: <1816597224.34837.1457366776761.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Mike Hammett" <nanog at ics-il.net>

> I think you'd be hard pressed to find more than a tenth of a percent of people
> attempt to run their own DNS server. Some do because they think it'll be better
> in some way. Rare is the occasion where anything user configured would
> outperform a local DNS server managed by the ISP that does no form of trickery.

I suspect it's higher than that, because of the fraction of edge routers which
do DNS masquerading.  Since that caches, I'm assuming it's a recursor, rather
than merely a pass-through, though I suppose it might be implementation 
dependent.

And *most* eyeball customer resolver servers engage in search stupidity now,
don't they? :-)

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 owen at delong.com  Mon Mar  7 23:42:43 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 7 Mar 2016 15:42:43 -0800
Subject: IPV6 planning
In-Reply-To: <f29836b7-3c60-452e-bd8d-6289f39e2a1f@seacom.mu>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <f29836b7-3c60-452e-bd8d-6289f39e2a1f@seacom.mu>
Message-ID: <8CE8FB87-2BB1-4498-B517-60F339703D72@delong.com>


> On Mar 5, 2016, at 13:46 , Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 5/Mar/16 23:19, Laurent Dumont wrote:
> 
>> Hiya,
>> 
>> We are currently considering deploying IPv6 for a Lan event in April.
>> We are assigned a /48 which we then split into smaller subnets for
>> each player vlan. That said, what remains to be decided is how we are
>> going to assign the IPv6. Basically, it seems that are two ways, one
>> SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6
>> which is basically DHCP but for IPv6.
>> 
>> Large events like Dreamhack have used SLAAC and the feedback has been
>> mostly positive. Can anyone comment regarding past experiences with
>> IPv6 gotchas and things that you don't really expect when running
>> dual-stack on a large-ish network?
> 
> SLAAC is the way you want to do, as DHCPv6 does not give you a default
> gateway.

Though you will inherently get one from the RA packet that tells you to
ask DHCPv6 for information anyway.

> If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a
> hybrid of DHCPv6 and SLAAC is reasonable.

Or you can use RFC6106 in your RAs on SLAAC.

Owen


From owen at delong.com  Mon Mar  7 23:51:06 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 7 Mar 2016 15:51:06 -0800
Subject: IPV6 planning
In-Reply-To: <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
 <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
Message-ID: <77735915-D6F5-425D-9147-3447C1F9CAD2@delong.com>


> On Mar 6, 2016, at 17:57 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> Den 6. mar. 2016 13.41 skrev "Karl Auer" <kauer at biplane.com.au>:
> 
>> Dunno about "harsh", but RFC 2464, section 4 says that the prefix must
>> be 64 bits. By (extremely strong) implication, a host must not use a
>> prefix of any other length to perform SLAAC. I say "extremely strong"
>> because the entire description of how an IPv6 Ethernet interface
>> identifier is formed depends on it being composed of the prefix plus an
>> EUI-64 identifier. Later RFCs firm up the requirement and apply it in
>> other contexts.
> 
> But the most popular OS (Windows) completely ignores all of that and makes
> up an identifier not based on EUI-64. Everyone are happy anyway. The RFC
> should have let identifier selection as an implementation detail as the
> risk of collision is almost non existent given a sufficient random
> selection and we have duplicate address detection as a safeguard.

To the best of my knowledge, Windows actually generates three addresses?

1. Subnet Stable quasi-randomized address unrelated (or at least not reversable to) MAC address.
2. Privacy address which rotates frequently (for some definition of frequently).
3. Stable address related to MAC address.

The 3rd one is standard SLAAC.
The second one is standard privacy extensions.
THe first one is unique to Windows. You?ll get the same address every time you connect to the same subnet, but you won?t see that suffix for that host on any other subnet.

Owen


From alarig at swordarmor.fr  Tue Mar  8 00:01:26 2016
From: alarig at swordarmor.fr (Alarig Le Lay)
Date: Tue, 8 Mar 2016 01:01:26 +0100
Subject: IPV6 planning
In-Reply-To: <77735915-D6F5-425D-9147-3447C1F9CAD2@delong.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
 <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
 <77735915-D6F5-425D-9147-3447C1F9CAD2@delong.com>
Message-ID: <20160308000126.GF5234@drscott.swordarmor.fr>

On Mon Mar  7 15:51:06 2016, Owen DeLong wrote:
> To the best of my knowledge, Windows actually generates three
> addresses?
> 
> 1. Subnet Stable quasi-randomized address unrelated (or at least not
> reversable to) MAC address.
> 2. Privacy address which rotates frequently (for some definition of
> frequently).
> 3. Stable address related to MAC address.
> 
> The 3rd one is standard SLAAC.
> The second one is standard privacy extensions.
> THe first one is unique to Windows. You?ll get the same address every
> time you connect to the same subnet, but you won?t see that suffix for
> that host on any other subnet.

It?s not exactly specific to Windows, dhcpcd use a something like that
(my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
there is a RFC related to that, https://tools.ietf.org/html/rfc7217.

-- 
alarig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160308/4b14f16c/attachment.pgp>

From owen at delong.com  Tue Mar  8 00:33:28 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 7 Mar 2016 16:33:28 -0800
Subject: IPV6 planning
In-Reply-To: <20160308000126.GF5234@drscott.swordarmor.fr>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
 <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
 <77735915-D6F5-425D-9147-3447C1F9CAD2@delong.com>
 <20160308000126.GF5234@drscott.swordarmor.fr>
Message-ID: <CF0B92BE-33B5-46F1-9D86-0696A5F9DFA1@delong.com>


> On Mar 7, 2016, at 16:01 , Alarig Le Lay <alarig at swordarmor.fr> wrote:
> 
> On Mon Mar  7 15:51:06 2016, Owen DeLong wrote:
>> To the best of my knowledge, Windows actually generates three
>> addresses?
>> 
>> 1. Subnet Stable quasi-randomized address unrelated (or at least not
>> reversable to) MAC address.
>> 2. Privacy address which rotates frequently (for some definition of
>> frequently).
>> 3. Stable address related to MAC address.
>> 
>> The 3rd one is standard SLAAC.
>> The second one is standard privacy extensions.
>> THe first one is unique to Windows. You?ll get the same address every
>> time you connect to the same subnet, but you won?t see that suffix for
>> that host on any other subnet.
> 
> It?s not exactly specific to Windows, dhcpcd use a something like that
> (my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
> there is a RFC related to that, https://tools.ietf.org/html/rfc7217.

Yes, but in the case of Windows, that happens with SLAAC without DHCP.

TTBOMK, this is unique to windows.

Owen


From tom.kac at gmail.com  Tue Mar  8 03:18:08 2016
From: tom.kac at gmail.com (Tom Kacprzynski)
Date: Mon, 7 Mar 2016 21:18:08 -0600
Subject: 2nd Call - Call for Presentations - CHI-NOG 06
Message-ID: <CAPFZH4BQPwg2A9aSR=GsiD9VFiqDeQRbscSfUUfxT=ZNRUY58Q@mail.gmail.com>

CHI-NOG 06's deadline for the Call for Presentations is next week, March
15th. Please submit your presentation's abstract at
http://chinog.org/meetings/*chi-nog*-06/abstract-submission/
<http://chinog.org/meetings/chi-nog-06/abstract-submission/>. All accepted
speakers will receive complimentary registration. Early bird registration
is already open.

The program committee is looking forward to your applications.


Thank you.

Tom Kacprzynski
CHI-NOG PC Chair

---------------------------------------------------------

*Call for Presentations*

*CHI-NOG* 06 - (Chicago Network Operators Group)

May 12th 2016, Chicago, IL

The Chicago Network Operators Group (*CHI-NOG*) is a vendor neutral
organization. Our goal is to create a regional community of network
professionals by presenting the latest technology trends, enabling
collaboration and providing networking opportunities. *CHI-NOG* will be
hosting its sixth annual conference May 12th, 2016 in downtown Chicago. For
more information please see http://chinog.org.

The *CHI-NOG* Program Committee is seeking proposals for presentations on
relevant networking technologies with a focus on the following topics:

* Network Automation/ DevOps
* Interconnection/Peering/Cloud Exchanges
* Low Latency Networks/Financial Networks
* Network Security
* Internet Monitoring
* Advanced BGP/MPLS Technologies
* Software Defined Networking
* Cloud Networking Technologies
* Network Operation
* Academic Research in Networking and Related Infrastructure Fields
* Open Source Networking Tools
* Optical Networking/Data Center Interconnect
* Data Center Fabric
* Wireless
* IPv6


*Session Format*
Each presentation is 30 minutes, which includes a questions and answers.
The duration can be extended per individual request to 60 minutes and will
be considered by the program committee. Presentations should not contain
any marketing material and should avoid discussion of commercial products
but rather focus on the underlying technology.


*Key Dates*
* Presentation Abstract Submission Deadline ------------------- 3/15/16
* Abstract Selection ----------------------------------------------
3/18/16
* Presentation Full Slides Submission Deadline ----------------- 4/15/16
* Final Selection --------------------------------------------------
4/29/16
* Conference ------------------------------------------------------ 5/12/16


*Submission*
Please submit presentation's abstract proposal by filling out the
submission form at
http://chinog.org/meetings/*chi-nog*-06/abstract-submission/
<http://chinog.org/meetings/chi-nog-06/abstract-submission/> . Once your
presentation is selected please provide the program committee with your
photo and a short bio for web publication. All accepted speakers will
receive complimentary tickets to the conference.

The program committee is looking forward to your submission and attendance
at the conference.

From baldur.norddahl at gmail.com  Tue Mar  8 04:23:01 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Tue, 8 Mar 2016 05:23:01 +0100
Subject: IPV6 planning
In-Reply-To: <20160308000126.GF5234@drscott.swordarmor.fr>
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
 <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
 <77735915-D6F5-425D-9147-3447C1F9CAD2@delong.com>
 <20160308000126.GF5234@drscott.swordarmor.fr>
Message-ID: <CAPkb-7CWe4qpYcqef7ExZnwqVJtAJjxb1cPobEp93KrJhv8sBg@mail.gmail.com>

On 8 March 2016 at 01:01, Alarig Le Lay <alarig at swordarmor.fr> wrote:

> It?s not exactly specific to Windows, dhcpcd use a something like that
> (my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
> there is a RFC related to that, https://tools.ietf.org/html/rfc7217.
>

It appears that RFC 7217 does not actually demand a 64 bit interface
identifier. One could therefore do a non-64 bit RFC 7217 SLAAC on operating
systems that support that.

"We note that [RFC4291] requires that the Interface IDs of all
          unicast addresses (except those that start with the binary
          value 000) be 64 bits long.  However, the method discussed in
          this document could be employed for generating Interface IDs
          of any arbitrary length, albeit at the expense of reduced
          entropy (when employing Interface IDs smaller than 64 bits)."


Regards,

Baldur

From email at edylie.net  Tue Mar  8 08:10:52 2016
From: email at edylie.net (Pui Edylie)
Date: Tue, 8 Mar 2016 16:10:52 +0800
Subject: Any HSBC network admin?
Message-ID: <56DE890C.4030204@edylie.net>

Dear NANOG Member,

Is there any HSBC network admin on this list or do you happen to know one?

We have problem reaching out to HSBC IP segments from our network and 
using the public WHOIS contact went cold.

Thank you.

Regards,
Edy


From greg.whynott at gmail.com  Tue Mar  8 15:30:37 2016
From: greg.whynott at gmail.com (greg whynott)
Date: Tue, 8 Mar 2016 10:30:37 -0500
Subject: remote serial console (IP to Serial)
Message-ID: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>

Recently I have taking over the responsibility of managing about 18 remote
routers and firewalls.   None of these have a console port for 'out of
band' access accessible today.

Most sites has available IPs between the ISP and us (typically a /29) or a
backup DSL connection available for use.     I'd like to purchase a IP to
Serial port device I can use for each location in the event I lock myself
out.   The requirement would be an Ethernet port,  a serial port,  and SSH.


Anyone have any recommendations on something like this?

thanks much,
greg

From morrowc.lists at gmail.com  Tue Mar  8 15:33:39 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Mar 2016 10:33:39 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
Message-ID: <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>

for singular serial .. there are many, do you want something that's
"appliance" or are you willing to deploy 18 raspnberry-pi-like
thingies?

On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com> wrote:
> Recently I have taking over the responsibility of managing about 18 remote
> routers and firewalls.   None of these have a console port for 'out of
> band' access accessible today.
>
> Most sites has available IPs between the ISP and us (typically a /29) or a
> backup DSL connection available for use.     I'd like to purchase a IP to
> Serial port device I can use for each location in the event I lock myself
> out.   The requirement would be an Ethernet port,  a serial port,  and SSH.
>
>
> Anyone have any recommendations on something like this?
>
> thanks much,
> greg

From josh at imaginenetworksllc.com  Tue Mar  8 15:34:20 2016
From: josh at imaginenetworksllc.com (Josh Luthman)
Date: Tue, 8 Mar 2016 10:34:20 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
Message-ID: <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>

AirConsole has an "all in one" solution with software and such.

Mikrotik does rfc2217 and this is their cheapest board today:
http://routerboard.com/RB911-2Hn


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
wrote:

> Recently I have taking over the responsibility of managing about 18 remote
> routers and firewalls.   None of these have a console port for 'out of
> band' access accessible today.
>
> Most sites has available IPs between the ISP and us (typically a /29) or a
> backup DSL connection available for use.     I'd like to purchase a IP to
> Serial port device I can use for each location in the event I lock myself
> out.   The requirement would be an Ethernet port,  a serial port,  and SSH.
>
>
> Anyone have any recommendations on something like this?
>
> thanks much,
> greg
>

From morrowc.lists at gmail.com  Tue Mar  8 15:35:22 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Mar 2016 10:35:22 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
Message-ID: <CAL9jLaYWpSr=y=7mXBfLK_D9rS4uVY41S=JP2N_C1j+pXf9AMQ@mail.gmail.com>

also, serial? or usb? (see previous cisco usb console port discussion)

On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> for singular serial .. there are many, do you want something that's
> "appliance" or are you willing to deploy 18 raspnberry-pi-like
> thingies?
>
> On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com> wrote:
>> Recently I have taking over the responsibility of managing about 18 remote
>> routers and firewalls.   None of these have a console port for 'out of
>> band' access accessible today.
>>
>> Most sites has available IPs between the ISP and us (typically a /29) or a
>> backup DSL connection available for use.     I'd like to purchase a IP to
>> Serial port device I can use for each location in the event I lock myself
>> out.   The requirement would be an Ethernet port,  a serial port,  and SSH.
>>
>>
>> Anyone have any recommendations on something like this?
>>
>> thanks much,
>> greg

From greg.whynott at gmail.com  Tue Mar  8 16:32:16 2016
From: greg.whynott at gmail.com (greg whynott)
Date: Tue, 8 Mar 2016 11:32:16 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
Message-ID: <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>

Thanks to all who responded to me,  quite the flood of suggestions and
options.

Found a lot of 20 Digi CM32's on ebay for 35 dollars each,  overkill but
can't beat the price,  going to look into those to make sure they are still
able to get OS updates.  There will be no firewall in front of this device
so it should have one itself.

I like the raspberry pi idea...  Would ensure perpetual security updates
with the OS running on it,  whereas I'm sure some of the vendors of
commercial console products EOL support at some point.  The fact it runs
linux is inviting as we can add it to our monitoring systems.

have a great day,
greg



On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow <morrowc.lists at gmail.com
> wrote:

> for singular serial .. there are many, do you want something that's
> "appliance" or are you willing to deploy 18 raspnberry-pi-like
> thingies?
>
> On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
> wrote:
> > Recently I have taking over the responsibility of managing about 18
> remote
> > routers and firewalls.   None of these have a console port for 'out of
> > band' access accessible today.
> >
> > Most sites has available IPs between the ISP and us (typically a /29) or
> a
> > backup DSL connection available for use.     I'd like to purchase a IP to
> > Serial port device I can use for each location in the event I lock myself
> > out.   The requirement would be an Ethernet port,  a serial port,  and
> SSH.
> >
> >
> > Anyone have any recommendations on something like this?
> >
> > thanks much,
> > greg
>

From owen at delong.com  Tue Mar  8 16:43:42 2016
From: owen at delong.com (Owen DeLong)
Date: Tue, 8 Mar 2016 08:43:42 -0800
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
 <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>
Message-ID: <3D1C55A4-2E76-4693-96E8-AE28E9D76835@delong.com>

Serial port on the PI is TTL, so you?ll need some level shifters and/or
ideally some opto-isolators or buffers to do a proper implementation.

Owen

> On Mar 8, 2016, at 08:32 , greg whynott <greg.whynott at gmail.com> wrote:
> 
> Thanks to all who responded to me,  quite the flood of suggestions and
> options.
> 
> Found a lot of 20 Digi CM32's on ebay for 35 dollars each,  overkill but
> can't beat the price,  going to look into those to make sure they are still
> able to get OS updates.  There will be no firewall in front of this device
> so it should have one itself.
> 
> I like the raspberry pi idea...  Would ensure perpetual security updates
> with the OS running on it,  whereas I'm sure some of the vendors of
> commercial console products EOL support at some point.  The fact it runs
> linux is inviting as we can add it to our monitoring systems.
> 
> have a great day,
> greg
> 
> 
> 
> On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow <morrowc.lists at gmail.com
>> wrote:
> 
>> for singular serial .. there are many, do you want something that's
>> "appliance" or are you willing to deploy 18 raspnberry-pi-like
>> thingies?
>> 
>> On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
>> wrote:
>>> Recently I have taking over the responsibility of managing about 18
>> remote
>>> routers and firewalls.   None of these have a console port for 'out of
>>> band' access accessible today.
>>> 
>>> Most sites has available IPs between the ISP and us (typically a /29) or
>> a
>>> backup DSL connection available for use.     I'd like to purchase a IP to
>>> Serial port device I can use for each location in the event I lock myself
>>> out.   The requirement would be an Ethernet port,  a serial port,  and
>> SSH.
>>> 
>>> 
>>> Anyone have any recommendations on something like this?
>>> 
>>> thanks much,
>>> greg
>> 


From morrowc.lists at gmail.com  Tue Mar  8 16:48:19 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Mar 2016 11:48:19 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAO0-hXaqyOeTpHDNirOsrMczTnyhFMiWqG1siO8H48LVD-49qQ@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
 <CAL9jLaYWpSr=y=7mXBfLK_D9rS4uVY41S=JP2N_C1j+pXf9AMQ@mail.gmail.com>
 <CAO0-hXaqyOeTpHDNirOsrMczTnyhFMiWqG1siO8H48LVD-49qQ@mail.gmail.com>
Message-ID: <CAL9jLaY=LwPjoQ03tpSYhVLO=XgtRPVwyuGB0my_6F8p8+YwTQ@mail.gmail.com>

On Tue, Mar 8, 2016 at 11:16 AM, Joe Hamelin <joe at nethead.com> wrote:
> This little guy has proven handy for me.
> http://www.amazon.com/iPocket232-RS232-to-Ethernet-Converter/dp/B00K309TKY
>

a number of interesting options exist, but...

1) this will get deployed into 'some third world sh*thole' (aka,
remote equinix facility 15+ minutes from your house)

2) someone has to maintain it long term (security patches,
functionality fixes, dual power supplies?, redundant network access?
gsm/cell/ethernet? )

3) an appliance might pay for itself if you don't want lots of hands-on effort



-chris

> --
> Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474
>
> On Tue, Mar 8, 2016 at 7:35 AM, Christopher Morrow <morrowc.lists at gmail.com>
> wrote:
>>
>> also, serial? or usb? (see previous cisco usb console port discussion)
>>
>> On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow
>> <morrowc.lists at gmail.com> wrote:
>> > for singular serial .. there are many, do you want something that's
>> > "appliance" or are you willing to deploy 18 raspnberry-pi-like
>> > thingies?
>> >
>> > On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
>> > wrote:
>> >> Recently I have taking over the responsibility of managing about 18
>> >> remote
>> >> routers and firewalls.   None of these have a console port for 'out of
>> >> band' access accessible today.
>> >>
>> >> Most sites has available IPs between the ISP and us (typically a /29)
>> >> or a
>> >> backup DSL connection available for use.     I'd like to purchase a IP
>> >> to
>> >> Serial port device I can use for each location in the event I lock
>> >> myself
>> >> out.   The requirement would be an Ethernet port,  a serial port,  and
>> >> SSH.
>> >>
>> >>
>> >> Anyone have any recommendations on something like this?
>> >>
>> >> thanks much,
>> >> greg
>
>

From morrowc.lists at gmail.com  Tue Mar  8 16:49:36 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Mar 2016 11:49:36 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <3D1C55A4-2E76-4693-96E8-AE28E9D76835@delong.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
 <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>
 <3D1C55A4-2E76-4693-96E8-AE28E9D76835@delong.com>
Message-ID: <CAL9jLaZg5CY_oecYvVzuD2OHMwGxWjwj68JsBmn5XLaXKmbGOQ@mail.gmail.com>

On Tue, Mar 8, 2016 at 11:43 AM, Owen DeLong <owen at delong.com> wrote:
> Serial port on the PI is TTL, so you?ll need some level shifters and/or
> ideally some opto-isolators or buffers to do a proper implementation.
>

usb-serial dongle, no?

also keep in mind, 'bad power' can make raspi's a pita :( corrupting
the flash card isn't fun. (maybe this is solved with another media for
root-partition though)

> Owen
>
>> On Mar 8, 2016, at 08:32 , greg whynott <greg.whynott at gmail.com> wrote:
>>
>> Thanks to all who responded to me,  quite the flood of suggestions and
>> options.
>>
>> Found a lot of 20 Digi CM32's on ebay for 35 dollars each,  overkill but
>> can't beat the price,  going to look into those to make sure they are still
>> able to get OS updates.  There will be no firewall in front of this device
>> so it should have one itself.
>>
>> I like the raspberry pi idea...  Would ensure perpetual security updates
>> with the OS running on it,  whereas I'm sure some of the vendors of
>> commercial console products EOL support at some point.  The fact it runs
>> linux is inviting as we can add it to our monitoring systems.
>>
>> have a great day,
>> greg
>>
>>
>>
>> On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow <morrowc.lists at gmail.com
>>> wrote:
>>
>>> for singular serial .. there are many, do you want something that's
>>> "appliance" or are you willing to deploy 18 raspnberry-pi-like
>>> thingies?
>>>
>>> On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
>>> wrote:
>>>> Recently I have taking over the responsibility of managing about 18
>>> remote
>>>> routers and firewalls.   None of these have a console port for 'out of
>>>> band' access accessible today.
>>>>
>>>> Most sites has available IPs between the ISP and us (typically a /29) or
>>> a
>>>> backup DSL connection available for use.     I'd like to purchase a IP to
>>>> Serial port device I can use for each location in the event I lock myself
>>>> out.   The requirement would be an Ethernet port,  a serial port,  and
>>> SSH.
>>>>
>>>>
>>>> Anyone have any recommendations on something like this?
>>>>
>>>> thanks much,
>>>> greg
>>>
>

From mel at beckman.org  Tue Mar  8 16:50:13 2016
From: mel at beckman.org (Mel Beckman)
Date: Tue, 8 Mar 2016 16:50:13 +0000
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>,
 <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>
Message-ID: <E1E21EEC-F1AC-46A5-8509-3A113872BC5D@beckman.org>

I just built a trivial raspberry pi gadget for about $100 that uses the $40 GSM 2G FONA cellular modem card and a ting.com SIM card to tunnel ssh back to my home network via cellular data. It's runs at just 128Kbps, but that's fine for a serial console. I use the Linux screen utility to connect to the local end of the ssh tunnel, and keep each console open (which has the nice side effect of capturing any log entries emitted). 

All the parts and most instructions are available at https://www.adafruit.com/product/1946. The only customization I added was a second USB serial port to access my remote console, and the phone-home ssh script (of which there are many open source examples to choose from). Ting.com has very good cellular data prices and is aimed at IoT connectivity, so it costs very little to deploy one of these gadgets ($6/mo if I use less than a megabyte, but just $15/gigabyte after that). 

 -mel beckman

> On Mar 8, 2016, at 8:33 AM, greg whynott <greg.whynott at gmail.com> wrote:
> 
> Thanks to all who responded to me,  quite the flood of suggestions and
> options.
> 
> Found a lot of 20 Digi CM32's on ebay for 35 dollars each,  overkill but
> can't beat the price,  going to look into those to make sure they are still
> able to get OS updates.  There will be no firewall in front of this device
> so it should have one itself.
> 
> I like the raspberry pi idea...  Would ensure perpetual security updates
> with the OS running on it,  whereas I'm sure some of the vendors of
> commercial console products EOL support at some point.  The fact it runs
> linux is inviting as we can add it to our monitoring systems.
> 
> have a great day,
> greg
> 
> 
> 
> On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow <morrowc.lists at gmail.com
>> wrote:
> 
>> for singular serial .. there are many, do you want something that's
>> "appliance" or are you willing to deploy 18 raspnberry-pi-like
>> thingies?
>> 
>> On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
>> wrote:
>>> Recently I have taking over the responsibility of managing about 18
>> remote
>>> routers and firewalls.   None of these have a console port for 'out of
>>> band' access accessible today.
>>> 
>>> Most sites has available IPs between the ISP and us (typically a /29) or
>> a
>>> backup DSL connection available for use.     I'd like to purchase a IP to
>>> Serial port device I can use for each location in the event I lock myself
>>> out.   The requirement would be an Ethernet port,  a serial port,  and
>> SSH.
>>> 
>>> 
>>> Anyone have any recommendations on something like this?
>>> 
>>> thanks much,
>>> greg
>> 

From mel at beckman.org  Tue Mar  8 16:51:54 2016
From: mel at beckman.org (Mel Beckman)
Date: Tue, 8 Mar 2016 16:51:54 +0000
Subject: remote serial console (IP to Serial)
In-Reply-To: <3D1C55A4-2E76-4693-96E8-AE28E9D76835@delong.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
 <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>,
 <3D1C55A4-2E76-4693-96E8-AE28E9D76835@delong.com>
Message-ID: <F14B2049-39CC-4815-81F2-5167E8A5F15A@beckman.org>

Adafruit.com sells a USB to serial converter for $10 that works great (https://www.adafruit.com/product/954). Plus you can operate multiple serial ports this way. 

 -mel beckman

> On Mar 8, 2016, at 8:45 AM, Owen DeLong <owen at delong.com> wrote:
> 
> Serial port on the PI is TTL, so you?ll need some level shifters and/or
> ideally some opto-isolators or buffers to do a proper implementation.
> 
> Owen
> 
>> On Mar 8, 2016, at 08:32 , greg whynott <greg.whynott at gmail.com> wrote:
>> 
>> Thanks to all who responded to me,  quite the flood of suggestions and
>> options.
>> 
>> Found a lot of 20 Digi CM32's on ebay for 35 dollars each,  overkill but
>> can't beat the price,  going to look into those to make sure they are still
>> able to get OS updates.  There will be no firewall in front of this device
>> so it should have one itself.
>> 
>> I like the raspberry pi idea...  Would ensure perpetual security updates
>> with the OS running on it,  whereas I'm sure some of the vendors of
>> commercial console products EOL support at some point.  The fact it runs
>> linux is inviting as we can add it to our monitoring systems.
>> 
>> have a great day,
>> greg
>> 
>> 
>> 
>> On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow <morrowc.lists at gmail.com
>>> wrote:
>> 
>>> for singular serial .. there are many, do you want something that's
>>> "appliance" or are you willing to deploy 18 raspnberry-pi-like
>>> thingies?
>>> 
>>> On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
>>> wrote:
>>>> Recently I have taking over the responsibility of managing about 18
>>> remote
>>>> routers and firewalls.   None of these have a console port for 'out of
>>>> band' access accessible today.
>>>> 
>>>> Most sites has available IPs between the ISP and us (typically a /29) or
>>> a
>>>> backup DSL connection available for use.     I'd like to purchase a IP to
>>>> Serial port device I can use for each location in the event I lock myself
>>>> out.   The requirement would be an Ethernet port,  a serial port,  and
>>> SSH.
>>>> 
>>>> 
>>>> Anyone have any recommendations on something like this?
>>>> 
>>>> thanks much,
>>>> greg
> 

From list at satchell.net  Tue Mar  8 18:06:59 2016
From: list at satchell.net (Stephen Satchell)
Date: Tue, 8 Mar 2016 10:06:59 -0800
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
Message-ID: <56DF14C3.9070107@satchell.net>

On 03/08/2016 07:30 AM, greg whynott wrote:
>   I'd like to purchase a IP to
> Serial port device I can use for each location in the event I lock myself
> out.   The requirement would be an Ethernet port,  a serial port,  and SSH.

I've used Cisco 2500 routers for this type of service, using the AUX 
port and a roll-over cable to connect to the target device.  I'm talking 
2501s mostly, not the 2511 or 2508, unless you need to control more than 
one device at a specific location.

Ethernet, AUX port, SSH, firewall.  Updates are sketchy, but these are 
mature devices.


From bjorn at mork.no  Tue Mar  8 18:35:55 2016
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 08 Mar 2016 19:35:55 +0100
Subject: IPV6 planning
In-Reply-To: <CF0B92BE-33B5-46F1-9D86-0696A5F9DFA1@delong.com> (Owen DeLong's
 message of "Mon, 7 Mar 2016 16:33:28 -0800")
References: <56DB4D6C.9080504@coldnorthadmin.com>
 <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
 <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
 <77735915-D6F5-425D-9147-3447C1F9CAD2@delong.com>
 <20160308000126.GF5234@drscott.swordarmor.fr>
 <CF0B92BE-33B5-46F1-9D86-0696A5F9DFA1@delong.com>
Message-ID: <87bn6o7r78.fsf@nemi.mork.no>

Owen DeLong <owen at delong.com> writes:
>> On Mar 7, 2016, at 16:01 , Alarig Le Lay <alarig at swordarmor.fr> wrote:
>> 
>> It?s not exactly specific to Windows, dhcpcd use a something like that
>> (my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
>> there is a RFC related to that, https://tools.ietf.org/html/rfc7217.
>
> Yes, but in the case of Windows, that happens with SLAAC without DHCP.

Yes, and SLAAC is what rfc7217 is about

> TTBOMK, this is unique to windows.

Nope.  See for example the stable_secret setting in
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

But Linux doesn't create this in addition to the EUI-64 derived
address.  It creates in instead.  And it won't happen by default.  Only
if you configure a secret. Except for weird interfaces without any
EUI-64 identifier, like raw IP interfaces, which will use this code to
support SLAAC.

How does Windows manage to *use* three addresses? I can understand how
the rfc7217 address and the privacy address can be use for different
purposes, but what do they use the EUI-64 address for?


Bj?rn

From jmaimon at ttec.com  Tue Mar  8 18:36:25 2016
From: jmaimon at ttec.com (Joe Maimon)
Date: Tue, 8 Mar 2016 13:36:25 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <56DF14C3.9070107@satchell.net>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <56DF14C3.9070107@satchell.net>
Message-ID: <56DF1BA9.6070008@ttec.com>

You can use a 2600 or 2800 with the 16 port serial module.

Stephen Satchell wrote:
> On 03/08/2016 07:30 AM, greg whynott wrote:
>>   I'd like to purchase a IP to
>> Serial port device I can use for each location in the event I lock myself
>> out.   The requirement would be an Ethernet port,  a serial port,  and
>> SSH.
>
> I've used Cisco 2500 routers for this type of service, using the AUX
> port and a roll-over cable to connect to the target device.  I'm talking
> 2501s mostly, not the 2511 or 2508, unless you need to control more than
> one device at a specific location.
>
> Ethernet, AUX port, SSH, firewall.  Updates are sketchy, but these are
> mature devices.
>
>

From joelja at bogus.com  Tue Mar  8 18:36:59 2016
From: joelja at bogus.com (joel jaeggli)
Date: Tue, 8 Mar 2016 10:36:59 -0800
Subject: remote serial console (IP to Serial)
In-Reply-To: <56DF14C3.9070107@satchell.net>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <56DF14C3.9070107@satchell.net>
Message-ID: <5c48dcf8-e9c2-7292-8833-79ddec8376c9@bogus.com>

On 3/8/16 10:06 AM, Stephen Satchell wrote:
> On 03/08/2016 07:30 AM, greg whynott wrote:
>>   I'd like to purchase a IP to
>> Serial port device I can use for each location in the event I lock myself
>> out.   The requirement would be an Ethernet port,  a serial port,  and
>> SSH.
> 
> I've used Cisco 2500 routers for this type of service, using the AUX
> port and a roll-over cable to connect to the target device.  I'm talking
> 2501s mostly, not the 2511 or 2508, unless you need to control more than
> one device at a specific location.
> 
> Ethernet, AUX port, SSH, firewall.  Updates are sketchy, but these are
> mature devices.

We use the small opengears for small sites acm5500 for ethernet and serial.

Used to use cisco 25xx 26xx but those are long in the tooth and not
fast. stopped using  avocent because of the value proposition.

I have experimented with raspberry pi for smaller oob server (with
appropriate usb serial breakout ) e.g. digi edgeport box for 8 serials
or ftdi usb serial adapters rather tha stand-alone pc which is what we
use for larger oob/utility server/router. it's considerably smaller than
the rackable equivalent.



-------------- 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/20160308/db032e7b/attachment.pgp>

From andrew.fried at gmail.com  Tue Mar  8 18:45:11 2016
From: andrew.fried at gmail.com (Andrew Fried)
Date: Tue, 8 Mar 2016 13:45:11 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
Message-ID: <56DF1DB7.6070605@gmail.com>

The Lantronix Spiders work well and aren't a "do-it-yourself" option:

http://www.lantronix.com/products/lantronix-spider/

Andrew

Andrew Fried
andrew.fried at gmail.com

On 3/8/16 10:30 AM, greg whynott wrote:
> Recently I have taking over the responsibility of managing about 18 remote
> routers and firewalls.   None of these have a console port for 'out of
> band' access accessible today.
> 
> Most sites has available IPs between the ISP and us (typically a /29) or a
> backup DSL connection available for use.     I'd like to purchase a IP to
> Serial port device I can use for each location in the event I lock myself
> out.   The requirement would be an Ethernet port,  a serial port,  and SSH.
> 
> 
> Anyone have any recommendations on something like this?
> 
> thanks much,
> greg
> 

From erey at ernw.de  Tue Mar  8 19:00:11 2016
From: erey at ernw.de (Enno Rey)
Date: Tue, 8 Mar 2016 20:00:11 +0100
Subject: IPV6 planning
In-Reply-To: <87bn6o7r78.fsf@nemi.mork.no>
References: <1457218790.2036.33.camel@biplane.com.au>
 <CAAeewD8q4QnNgH2dFbvmW=qWForL=stVWy8NgUJxg8u=pdf=mA@mail.gmail.com>
 <1457226535.2036.75.camel@biplane.com.au>
 <CAAeewD8C8Qz_pHiki0p14Q43WbJV81kHntGGZQgmL+TOfQ4Hog@mail.gmail.com>
 <1457267989.5152.23.camel@biplane.com.au>
 <CAPkb-7AnQ1N-hDAc9zgtj-wJuAjo_JuOY2b31Z0xPC=RrYUWGA@mail.gmail.com>
 <77735915-D6F5-425D-9147-3447C1F9CAD2@delong.com>
 <20160308000126.GF5234@drscott.swordarmor.fr>
 <CF0B92BE-33B5-46F1-9D86-0696A5F9DFA1@delong.com>
 <87bn6o7r78.fsf@nemi.mork.no>
Message-ID: <20160308190011.GB75404@ernw.de>

Hi,

On Tue, Mar 08, 2016 at 07:35:55PM +0100, Bj??rn Mork wrote:
> 
> How does Windows manage to *use* three addresses? I can understand how
> the rfc7217 address and the privacy address can be use for different
> purposes, but what do they use the EUI-64 address for?

Windows doesn't use/create a third EUI-64 address. By default it only creates that "kind-of random, kind-of stable" address (unrelated to RFC 2117) and a temporary address. No EUI-64 address (by default).
It *can* create, by a specific setting, an EUI-64 address but that would replace the above mentioned 1st (non-temporary) one.

best

Enno




> 
> 
> Bj??rn

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

From graham at apolix.co.za  Tue Mar  8 19:03:37 2016
From: graham at apolix.co.za (Graham Beneke)
Date: Tue, 8 Mar 2016 21:03:37 +0200
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
Message-ID: <56DF2209.5050607@apolix.co.za>


On 08/03/2016 17:34, Josh Luthman wrote:
> Mikrotik does rfc2217 and this is their cheapest board today:
> http://routerboard.com/RB911-2Hn

Are you perhaps thinking of the http://routerboard.com/RB411 ?
I don't think the model you linked has a serial port.

We've deployed them successfully in a couple of places as a serial console.

For a few extra bucks you can get a http://routerboard.com/RB450 which
you can also use to connect up a few ethernet management ports, handle
some dynamic routing/failover or even build a full OOB network.

-- 
Graham Beneke


From ghenry at suretec.co.uk  Tue Mar  8 19:10:14 2016
From: ghenry at suretec.co.uk (Gavin Henry)
Date: Tue, 8 Mar 2016 19:10:14 +0000
Subject: remote serial console (IP to Serial)
In-Reply-To: <56DF2209.5050607@apolix.co.za>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
Message-ID: <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>

Really love the Opengear IM range. We use IM4216's

From hugo at slabnet.com  Tue Mar  8 19:21:22 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Tue, 8 Mar 2016 11:21:22 -0800
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
Message-ID: <20160308192122.GA24295@bamboo.slabnet.com>

On Tue 2016-Mar-08 19:10:14 +0000, Gavin Henry <ghenry at suretec.co.uk> wrote:

>Really love the Opengear IM range. We use IM4216's

I'm surprised no one's mentioned freetserv[1] yet.  I haven't used them so 
don't consider this an endorsement, but on the surface it looks to be a 
good balance of "open / DIY" and "supportable".

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal

[1] https://freetserv.github.io/
-------------- 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/20160308/0a3f324f/attachment.pgp>

From royce at techsolvency.com  Tue Mar  8 19:45:30 2016
From: royce at techsolvency.com (Royce Williams)
Date: Tue, 8 Mar 2016 10:45:30 -0900
Subject: remote serial console (IP to Serial)
In-Reply-To: <20160308192122.GA24295@bamboo.slabnet.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
 <20160308192122.GA24295@bamboo.slabnet.com>
Message-ID: <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>

On Tue, Mar 8, 2016 at 10:21 AM, Hugo Slabbert <hugo at slabnet.com> wrote:

> On Tue 2016-Mar-08 19:10:14 +0000, Gavin Henry <ghenry at suretec.co.uk>
> wrote:
>
> Really love the Opengear IM range. We use IM4216's
>>
>
> I'm surprised no one's mentioned freetserv[1] yet.  I haven't used them so
> don't consider this an endorsement, but on the surface it looks to be a
> good balance of "open / DIY" and "supportable".
>
> [1] https://freetserv.github.io/
>

This is great!  A mainstream, patchable OS -- not locked into a half-baked
OS or roll-your-own-TCP-stack hell I've seen in some remote serial and
power devices.

Thanks!

Royce

From list at satchell.net  Tue Mar  8 21:06:31 2016
From: list at satchell.net (Stephen Satchell)
Date: Tue, 8 Mar 2016 13:06:31 -0800
Subject: remote serial console (IP to Serial)
In-Reply-To: <56DF1BA9.6070008@ttec.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <56DF14C3.9070107@satchell.net> <56DF1BA9.6070008@ttec.com>
Message-ID: <56DF3ED7.6050902@satchell.net>

On 03/08/2016 10:36 AM, Joe Maimon wrote:
> You can use a 2600 or 2800 with the 16 port serial module.

Or a 32-port module (NM-32A)...but I think that would have been overkill 
for what the OP was originally asking for.  :)



From morrowc.lists at gmail.com  Tue Mar  8 21:13:40 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Mar 2016 16:13:40 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
 <20160308192122.GA24295@bamboo.slabnet.com>
 <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
Message-ID: <CAL9jLaYmsnZP0be9_+5Bthn-_cpUM4DWmG0kn4FHRWvJApYQYQ@mail.gmail.com>

On Tue, Mar 8, 2016 at 2:45 PM, Royce Williams <royce at techsolvency.com> wrote:
> On Tue, Mar 8, 2016 at 10:21 AM, Hugo Slabbert <hugo at slabnet.com> wrote:
>
>> On Tue 2016-Mar-08 19:10:14 +0000, Gavin Henry <ghenry at suretec.co.uk>
>> wrote:
>>
>> Really love the Opengear IM range. We use IM4216's
>>>
>>
>> I'm surprised no one's mentioned freetserv[1] yet.  I haven't used them so
>> don't consider this an endorsement, but on the surface it looks to be a
>> good balance of "open / DIY" and "supportable".
>>
>> [1] https://freetserv.github.io/
>>
>
> This is great!  A mainstream, patchable OS -- not locked into a half-baked
> OS or roll-your-own-TCP-stack hell I've seen in some remote serial and
> power devices.


<thanks jared>

From jra at baylink.com  Tue Mar  8 21:57:48 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 8 Mar 2016 21:57:48 +0000 (UTC)
Subject: [mailop] Google DNS Servers not returning results for Hotmail
 today?
In-Reply-To: <57c3bf35b04542c9906434b9733f06f6@ex13-mbx1-go.e.dexaweb.com>
References: <56DDF2B9.7030002@linuxmagic.com>
 <5c304e3f736a45b391fb4588beb72cdf@ex13-mbx1-go.e.dexaweb.com>
 <BY2PR03MB411192EA9AABE2916B8447C80B10@BY2PR03MB411.namprd03.prod.outlook.com>
 <56DE021B.5050306@linuxmagic.com>
 <57c3bf35b04542c9906434b9733f06f6@ex13-mbx1-go.e.dexaweb.com>
Message-ID: <1571910326.39335.1457474268398.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Tony Bunce" <tonyb at go-concepts.com>

> I just disabled DNSSEC validation on all of our resolvers and that appears to
> have fixed the problem for us.
> 
> I?m far from a DNSSEC expert but I think the issue is with the entire
> 65.in-addr.arpa zone.  I can reproduce the issue on any PTR record inside of
> 65.0.0.0/8.

And Tony wins the Internet (and that means a lot more here, than when I 
award it to funny people on Facebook :-) for Tuesday.

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 bob at FiberInternetCenter.com  Tue Mar  8 23:35:48 2016
From: bob at FiberInternetCenter.com (Bob Evans)
Date: Tue, 8 Mar 2016 15:35:48 -0800
Subject: LighTower - Major issue - Anyone from LIGHTOWER please contact me
 off list.
Message-ID: <7959b6f221132e974323d870cb4812f3.squirrel@66.201.44.180>

Anyone out here from LIGHTOWER please contact me off list.
Thank You
Bob Evans
CTO







From merlyn at geeks.org  Wed Mar  9 05:36:42 2016
From: merlyn at geeks.org (Doug McIntyre)
Date: Tue, 8 Mar 2016 23:36:42 -0600
Subject: remote serial console (IP to Serial)
In-Reply-To: <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
 <20160308192122.GA24295@bamboo.slabnet.com>
 <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
Message-ID: <20160309053642.GB2304@geeks.org>

On Tue, Mar 08, 2016 at 10:45:30AM -0900, Royce Williams wrote:
> On Tue, Mar 8, 2016 at 10:21 AM, Hugo Slabbert <hugo at slabnet.com> wrote:
> > I'm surprised no one's mentioned freetserv[1] yet.  I haven't used them so
> > don't consider this an endorsement, but on the surface it looks to be a
> > good balance of "open / DIY" and "supportable".
..
> This is great!  A mainstream, patchable OS -- not locked into a half-baked
> OS or roll-your-own-TCP-stack hell I've seen in some remote serial and
> power devices.
..

Yes, instead of a hacked together hardwareboard, or appliance with
firmware that never gets updated stuck in SSH v1 days (old Cisco?)..
Freetserv looks interesting, but very costly once you add up the BOM. 

I'd get something like a 1U ATOM server ($120 eBay) with small SSD
($18).  Runup your favorite FOSS OS, and conserver.  For more than the
single real serialport, you can most likely fit a USB hub inside
the case still, and hang a number of USB serial dongles off.

Rackmountable, maintainable, and conserver works great.




From saku at ytti.fi  Wed Mar  9 09:50:11 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 11:50:11 +0200
Subject: remote serial console (IP to Serial)
In-Reply-To: <20160309053642.GB2304@geeks.org>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
 <20160308192122.GA24295@bamboo.slabnet.com>
 <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
 <20160309053642.GB2304@geeks.org>
Message-ID: <CAAeewD_5K_2Gr-Eq_ScFZykkfLj33ygZgYc-O3Z+Huo3kxFDbg@mail.gmail.com>

On 9 March 2016 at 07:36, Doug McIntyre <merlyn at geeks.org> wrote:

Hey,

> I'd get something like a 1U ATOM server ($120 eBay) with small SSD
> ($18).  Runup your favorite FOSS OS, and conserver.  For more than the
> single real serialport, you can most likely fit a USB hub inside
> the case still, and hang a number of USB serial dongles off.
>
> Rackmountable, maintainable, and conserver works great.

+1 on conserver. I think the greatest asset of conserver is, that it
harmonises your OOB network into single interface. You can have
different generation of OOB kit from different vendors with different
level of functionality. Yet you get all the important functions from
all of them.

a) multiplexing of console access (very nice if person has went to
lunch and you really need to access that console now)
b) persistent logging of all console output (might be that crucial
little detail which will allow vendor to solve your service request)


Before I learned about conserver I wanted to use something like
cyclades (or what ever it's name is now after two acquisitions) or
opengear, just to get those two crucial features I need. But after
conserver, I greatly prefer just using Cisco console ports, as then I
can use device which is well known and already toolised by the
organisation, and will offer all the WAN access options I need, with
encryption when needed. But not having multiplexing and persistent
logging earlier was deal-breaker, now it's immaterial.
Sure opengear and cyclades probably can do few WAN options and
probably some encryption, but operationally that would be chore to me,
compared to rocking platform I already know.

Big hand to who ever caused JNPR to add ISIS/CLNS to SRX (I think
DTAG?),  I wish someone would get JNPR to add async ports to SRX too,
so that I'd have other option than CSCO for OOB. Big thanks to CSCO
for still bringing async serial ports to CISCO4321, I know the demand
must be rather small.
-- 
  ++ytti

From elfkin at gmail.com  Wed Mar  9 12:21:28 2016
From: elfkin at gmail.com (Harald F. Karlsen)
Date: Wed, 9 Mar 2016 13:21:28 +0100
Subject: IPV6 planning
In-Reply-To: <56DB4D6C.9080504@coldnorthadmin.com>
References: <56DB4D6C.9080504@coldnorthadmin.com>
Message-ID: <56E01548.2070902@gmail.com>



On 05.03.2016 22:19, Laurent Dumont wrote:
> Hiya,
>
Hi,

> We are currently considering deploying IPv6 for a Lan event in April. We
> are assigned a /48 which we then split into smaller subnets for each
> player vlan. That said, what remains to be decided is how we are going
> to assign the IPv6. Basically, it seems that are two ways, one SLAAC
> where the endpoints uses RA to generate it's own IP and DHCPv6 which is
> basically DHCP but for IPv6.
>
> Large events like Dreamhack have used SLAAC and the feedback has been
> mostly positive. Can anyone comment regarding past experiences with IPv6
> gotchas and things that you don't really expect when running dual-stack
> on a large-ish network?
>

For The Gathering 2015 we used DHCPv6 for IPv6. The reason for this was 
both tracability and security with IPv6 first-hop security 
(DHCPv6-guard, IPv6 source-guard, etc). We did the same for both wired 
and wireless clients which caused Android devices to not get IPv6 
connectivity, but it worked great on iOS devices and Windows Phones. You 
can run SLAAC for wireless clients if you want Android-devices to get 
IPv6 as well, but we wanted the same setup for all clients. IMHO it's 
really up to Google (Lorenzo?) to get their OS to support the same 
standards as everyone else does now.

We had around 5000 participants, ~160 edge switches (Juniper EX2200) and 
we had no issues with dual-stacked clients at all. First-hop security 
worked like a charm and I think more than 85% of all wired clients had 
IPv6 connectivity.

Here are a graph for the IPv4:IPv6 traffic ratio on the internet 
connection for the event (30Gbit/s total capacity):
http://bgp.no/stuff/rs1.tele-tg.png

As you can see we weren't near filling the pipe even though each client 
had 1Gbit/s wired connection and each edge switch had 3*1Gbit/s LAG 
toward the distribution layer (Juniper EX3300-VC). The IPv6 traffic 
ratio are also fairly low, but this is only natural as people attending 
these kinds of event uses a lot of services not available over IPv6 
(Valves Steam, EAs Origin, Torrents, etc).

I also see other people in the thread mentions firewalling. We didn't do 
any sort of inbound filtering. We've always provided the clients with 
public IPv4 addresses (borrowed PI-space from RIPE) and at events like 
this we feel it's up to the participants to secure their machines. We do 
still have a support crew that can assist participants with computer 
issues, but we haven't really had any issues with this since back in the 
days of WinNuke and the Blaster virus.

Feel free to ask any further questions regarding our setup either on- or 
off-list. We're all about openness and all code/config created for the 
event is publicly available online. :-)

Good luck with your event!

-- 
Harald

From lathama at gmail.com  Wed Mar  9 12:40:54 2016
From: lathama at gmail.com (Andrew Latham)
Date: Wed, 9 Mar 2016 06:40:54 -0600
Subject: remote serial console (IP to Serial)
In-Reply-To: <56DF1DB7.6070605@gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <56DF1DB7.6070605@gmail.com>
Message-ID: <CA+qj4S-fHWFy5XBfCB3J-3wp21kuu8r-GWcQTN0Wg=9tk528XA@mail.gmail.com>

+1 on the Lantronix Spider as it is an awesome tool but Lantronix make
devices for very small rollouts also,
http://www.lantronix.com/products/eds1100-eds2100/#tab-features might be
great for only one device and
http://www.lantronix.com/products/lantronix-slb/ for site management with
remote power control might be a good option.

On Tue, Mar 8, 2016 at 12:45 PM, Andrew Fried <andrew.fried at gmail.com>
wrote:

> The Lantronix Spiders work well and aren't a "do-it-yourself" option:
>
> http://www.lantronix.com/products/lantronix-spider/
>
> Andrew
>
> Andrew Fried
> andrew.fried at gmail.com
>
> On 3/8/16 10:30 AM, greg whynott wrote:
> > Recently I have taking over the responsibility of managing about 18
> remote
> > routers and firewalls.   None of these have a console port for 'out of
> > band' access accessible today.
> >
> > Most sites has available IPs between the ISP and us (typically a /29) or
> a
> > backup DSL connection available for use.     I'd like to purchase a IP to
> > Serial port device I can use for each location in the event I lock myself
> > out.   The requirement would be an Ethernet port,  a serial port,  and
> SSH.
> >
> >
> > Anyone have any recommendations on something like this?
> >
> > thanks much,
> > greg
> >
>



-- 
~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~

From ahebert at pubnix.net  Wed Mar  9 13:01:37 2016
From: ahebert at pubnix.net (Alain Hebert)
Date: Wed, 9 Mar 2016 08:01:37 -0500
Subject: mrtg alternative
In-Reply-To: <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
Message-ID: <56E01EB1.1040801@pubnix.net>

    Hi,

    Cacti works... Biggest case I know, ~180 devices.  A few issues with
THold plugin but nothing that can't be fixed.

    And they are working on a new release (available thru github) which
include most of the useful plugins.

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 02/27/16 16:12, Rafael Ganascim wrote:
> I like cacti:
>
> http://www.cacti.net
>
>
>
> 2016-02-26 20:18 GMT-03:00 Baldur Norddahl <baldur.norddahl at gmail.com>:
>
>> Hi
>>
>> I am currently using MRTG and RRD to make traffic graphs. I am searching
>> for more modern alternatives that allows the user to dynamically zoom and
>> scroll the timeline.
>>
>> Bonus points if the user can customize the graphs directly in the
>> webbrowse. For example he might be able to add or remove individual peers
>> from the graph by simply clicking a checkbox.
>>
>> What is the 2016 tool for this?
>>
>> Regards,
>>
>> Baldur
>>


From listas at kurtkraut.net  Wed Mar  9 14:26:35 2016
From: listas at kurtkraut.net (Kurt Kraut)
Date: Wed, 9 Mar 2016 11:26:35 -0300
Subject: Internet Exchanges supporting jumbo frames?
Message-ID: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>

Hi,


I'm trying to convince my local Internet Exchange location (and it is not
small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.
For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
connection/destination.

For IPv4, it requires more planning. For instance, two datacenters tend to
exchange relevant traffic because customers  with disaster recovery in mind
(saving the same content in two different datacenters, two different
suppliers). In most cases, these datacenters are quite far from each other,
even in different countries. In this context, jumbo frames would allow max
speed even the latency is from a tipical international link.

Could anyone share with me Internet Exchanges you know that allow jumbo
frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
from it?


Best regards,


Kurt Kraut

From Grzegorz at Janoszka.pl  Wed Mar  9 14:32:32 2016
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Wed, 9 Mar 2016 15:32:32 +0100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
Message-ID: <56E03400.30706@Janoszka.pl>

On 09/03/2016 15:26, Kurt Kraut via NANOG wrote:
> Could anyone share with me Internet Exchanges you know that allow jumbo
> frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
> from it?

Netnod does it in separate vlan's.

-- 
Grzegorz Janoszka

From job at instituut.net  Wed Mar  9 14:34:19 2016
From: job at instituut.net (Job Snijders)
Date: Wed, 9 Mar 2016 15:34:19 +0100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
Message-ID: <20160309143419.GG1163@22.rev.meerval.net>

Hi Kurt,

On Wed, Mar 09, 2016 at 11:26:35AM -0300, Kurt Kraut via NANOG wrote:
> I'm trying to convince my local Internet Exchange location (and it is not
> small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.
> For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
> connection/destination.
> 
> For IPv4, it requires more planning. For instance, two datacenters tend to
> exchange relevant traffic because customers  with disaster recovery in mind
> (saving the same content in two different datacenters, two different
> suppliers). In most cases, these datacenters are quite far from each other,
> even in different countries. In this context, jumbo frames would allow max
> speed even the latency is from a tipical international link.
> 
> Could anyone share with me Internet Exchanges you know that allow jumbo
> frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
> from it?

You might find this presentation interesting:

    https://www.nanog.org/sites/default/files/wednesday.general.steenbergen.antijumbo.pdf

The presenter argues: "Internet-wide Jumbo Frames will probably cause
infinitely more harm than good under the current technology."

Kind regards,

Job

From nick at foobar.org  Wed Mar  9 14:45:40 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 14:45:40 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
Message-ID: <56E03714.9070700@foobar.org>

Kurt Kraut via NANOG wrote:
> I'm trying to convince my local Internet Exchange location (and it is not
> small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.

this has been tried before at many ixps.  No matter how good an idea it
sounds like, most organisations are welded hard to the idea of a 1500
byte mtu.  Even for those who use larger MTUs on their networks, you're
likely to find that there is no agreement on the mtu that should be
used.  Some will want 9000, some 9200, others ??4470 and some people
will complain that they have some old device somewhere that doesn't
support anything more than 1522, and could everyone kindly agree to that
instead.

Meanwhile, if anyone gets the larger MTU wrong anywhere on their
network, packets will be blackholed and customers will end up unhappy.
Management will demand that the IXP jumbo service is disconnected until
the root cause is fixed, or worse still, will blame the IXP for some
mumble relating to how things worked better before enabling jumbo mtus.

Nick

From listas at kurtkraut.net  Wed Mar  9 14:50:23 2016
From: listas at kurtkraut.net (Kurt Kraut)
Date: Wed, 9 Mar 2016 11:50:23 -0300
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E03714.9070700@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
Message-ID: <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>

2016-03-09 11:45 GMT-03:00 Nick Hilliard <nick at foobar.org>:

> this has been tried before at many ixps.  No matter how good an idea it
> sounds like, most organisations are welded hard to the idea of a 1500
> byte mtu.  Even for those who use larger MTUs on their networks, you're
> likely to find that there is no agreement on the mtu that should be
> used.  Some will want 9000, some 9200, others ??4470 and some people
> will complain that they have some old device somewhere that doesn't
> support anything more than 1522, and could everyone kindly agree to that
> instead.
>



Hi Nick,


Thank you for replying so quickly. I don't see why the consensus for an MTU
must be reached. IPv6 Path MTU Discovery would handle it by itself,
wouldn't it? If one participant supports 9k and another 4k, the traffic
between them would be at 4k with no manual intervention. If to participants
adopts 9k, hooray, it will be 9k thanks do PMTUD.

Am I missing something?


Best regards,


Kurt Kraut

From nanog at ics-il.net  Wed Mar  9 14:53:24 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Wed, 9 Mar 2016 08:53:24 -0600 (CST)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
Message-ID: <562985930.2940.1457535204305.JavaMail.mhammett@ThunderFuck>

Maybe breaking v4 in the process? 




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



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


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

From: "Kurt Kraut via NANOG" <nanog at nanog.org> 
To: "Nick Hilliard" <nick at foobar.org> 
Cc: "NANOG list" <nanog at nanog.org> 
Sent: Wednesday, March 9, 2016 8:50:23 AM 
Subject: Re: Internet Exchanges supporting jumbo frames? 

2016-03-09 11:45 GMT-03:00 Nick Hilliard <nick at foobar.org>: 

> this has been tried before at many ixps. No matter how good an idea it 
> sounds like, most organisations are welded hard to the idea of a 1500 
> byte mtu. Even for those who use larger MTUs on their networks, you're 
> likely to find that there is no agreement on the mtu that should be 
> used. Some will want 9000, some 9200, others ??4470 and some people 
> will complain that they have some old device somewhere that doesn't 
> support anything more than 1522, and could everyone kindly agree to that 
> instead. 
> 



Hi Nick, 


Thank you for replying so quickly. I don't see why the consensus for an MTU 
must be reached. IPv6 Path MTU Discovery would handle it by itself, 
wouldn't it? If one participant supports 9k and another 4k, the traffic 
between them would be at 4k with no manual intervention. If to participants 
adopts 9k, hooray, it will be 9k thanks do PMTUD. 

Am I missing something? 


Best regards, 


Kurt Kraut 


From listas at kurtkraut.net  Wed Mar  9 14:59:22 2016
From: listas at kurtkraut.net (Kurt Kraut)
Date: Wed, 9 Mar 2016 11:59:22 -0300
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <562985930.2940.1457535204305.JavaMail.mhammett@ThunderFuck>
References: <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
 <562985930.2940.1457535204305.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAPbn28nd=HGwQAWj7R5GBfRWK1OeZF9nb3RP1oZ5W8fyFOsyGw@mail.gmail.com>

Hi Mike,



The adoption of jumbo frames in a IXP doesn't brake IPv4. For an ISP, their
corporate and residencial users would still use 1,5k. For datacenters,
their local switches and servers are still set to 1,5k MTU. Nothing will
brake.  When needed, if needed and when supported, from a specific server,
from a specific switch, to a specific router it can raise the MTU up to the
max MTU supported by IXP if the operator know the destination also supports
it, like in the disaster recovery example I gave. For IPv6, the best MTU
will be detected and used with no operational effort.

For those who doesn't care about it, an IXP adopting jumbo frames wouldn't
demand any kind of change for their network. They just set their interfaces
to 1500 bytes and go rest. For those who care like me can take benefit from
it and for that reason I see no reason for not adopting it.


Best regards,

Kurt Kraut

2016-03-09 11:53 GMT-03:00 Mike Hammett <nanog at ics-il.net>:

> Maybe breaking v4 in the process?
>
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
> ----- Original Message -----
>
> From: "Kurt Kraut via NANOG" <nanog at nanog.org>
> To: "Nick Hilliard" <nick at foobar.org>
> Cc: "NANOG list" <nanog at nanog.org>
> Sent: Wednesday, March 9, 2016 8:50:23 AM
> Subject: Re: Internet Exchanges supporting jumbo frames?
>
> 2016-03-09 11:45 GMT-03:00 Nick Hilliard <nick at foobar.org>:
>
> > this has been tried before at many ixps. No matter how good an idea it
> > sounds like, most organisations are welded hard to the idea of a 1500
> > byte mtu. Even for those who use larger MTUs on their networks, you're
> > likely to find that there is no agreement on the mtu that should be
> > used. Some will want 9000, some 9200, others ??4470 and some people
> > will complain that they have some old device somewhere that doesn't
> > support anything more than 1522, and could everyone kindly agree to that
> > instead.
> >
>
>
>
> Hi Nick,
>
>
> Thank you for replying so quickly. I don't see why the consensus for an MTU
> must be reached. IPv6 Path MTU Discovery would handle it by itself,
> wouldn't it? If one participant supports 9k and another 4k, the traffic
> between them would be at 4k with no manual intervention. If to participants
> adopts 9k, hooray, it will be 9k thanks do PMTUD.
>
> Am I missing something?
>
>
> Best regards,
>
>
> Kurt Kraut
>
>

From nanog at stefan-neufeind.de  Wed Mar  9 15:23:08 2016
From: nanog at stefan-neufeind.de (Stefan Neufeind)
Date: Wed, 9 Mar 2016 16:23:08 +0100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28nd=HGwQAWj7R5GBfRWK1OeZF9nb3RP1oZ5W8fyFOsyGw@mail.gmail.com>
References: <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
 <562985930.2940.1457535204305.JavaMail.mhammett@ThunderFuck>
 <CAPbn28nd=HGwQAWj7R5GBfRWK1OeZF9nb3RP1oZ5W8fyFOsyGw@mail.gmail.com>
Message-ID: <56E03FDC.8030802@stefan-neufeind.de>

There is no way to avoid breaking MTU for IPv4 but use PMTUD for IPv6,
is there? Meaning to stick to 1500 for IPv4 and use something larger for
IPv6?


Kind regards,
 Stefan

On 09.03.2016 15:59, Kurt Kraut via NANOG wrote:
> Hi Mike,
> 
> The adoption of jumbo frames in a IXP doesn't brake IPv4. For an ISP, their
> corporate and residencial users would still use 1,5k. For datacenters,
> their local switches and servers are still set to 1,5k MTU. Nothing will
> brake.  When needed, if needed and when supported, from a specific server,
> from a specific switch, to a specific router it can raise the MTU up to the
> max MTU supported by IXP if the operator know the destination also supports
> it, like in the disaster recovery example I gave. For IPv6, the best MTU
> will be detected and used with no operational effort.
> 
> For those who doesn't care about it, an IXP adopting jumbo frames wouldn't
> demand any kind of change for their network. They just set their interfaces
> to 1500 bytes and go rest. For those who care like me can take benefit from
> it and for that reason I see no reason for not adopting it.
> 
> 
> Best regards,
> 
> Kurt Kraut
> 
> 2016-03-09 11:53 GMT-03:00 Mike Hammett <nanog at ics-il.net>:
> 
>> Maybe breaking v4 in the process?
>>
>> -----
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>>
>>
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>>
>>
>> ----- Original Message -----
>>
>> From: "Kurt Kraut via NANOG" <nanog at nanog.org>
>> To: "Nick Hilliard" <nick at foobar.org>
>> Cc: "NANOG list" <nanog at nanog.org>
>> Sent: Wednesday, March 9, 2016 8:50:23 AM
>> Subject: Re: Internet Exchanges supporting jumbo frames?
>>
>> 2016-03-09 11:45 GMT-03:00 Nick Hilliard <nick at foobar.org>:
>>
>>> this has been tried before at many ixps. No matter how good an idea it
>>> sounds like, most organisations are welded hard to the idea of a 1500
>>> byte mtu. Even for those who use larger MTUs on their networks, you're
>>> likely to find that there is no agreement on the mtu that should be
>>> used. Some will want 9000, some 9200, others ??4470 and some people
>>> will complain that they have some old device somewhere that doesn't
>>> support anything more than 1522, and could everyone kindly agree to that
>>> instead.
>>>
>>
>>
>>
>> Hi Nick,
>>
>>
>> Thank you for replying so quickly. I don't see why the consensus for an MTU
>> must be reached. IPv6 Path MTU Discovery would handle it by itself,
>> wouldn't it? If one participant supports 9k and another 4k, the traffic
>> between them would be at 4k with no manual intervention. If to participants
>> adopts 9k, hooray, it will be 9k thanks do PMTUD.
>>
>> Am I missing something?
>>
>>
>> Best regards,
>>
>>
>> Kurt Kraut

From nick at foobar.org  Wed Mar  9 15:51:59 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 15:51:59 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
Message-ID: <56E0469F.7000004@foobar.org>

Kurt Kraut wrote:
> Thank you for replying so quickly. I don't see why the consensus for an
> MTU must be reached. IPv6 Path MTU Discovery would handle it by itself,
> wouldn't it? If one participant supports 9k and another 4k, the traffic
> between them would be at 4k with no manual intervention. If to
> participants adopts 9k, hooray, it will be 9k thanks do PMTUD.
> 
> Am I missing something?

for starters, if you send a 9001 byte packet to a router which has its
interface MTU configured to be 9000 bytes, the packet will be
blackholed, not rejected with a PTB.

Even if it weren't, how many icmp PTB packets per second would a router
be happy to generate before rate limiters kicked in?  Once someone
malicious works that out, they can send that number of crafted packets
per second through the IXP, thereby creating a denial of service situation.

There are many other problems, such as pmtud not working properly in the
general case.

Nick


From swmike at swm.pp.se  Wed Mar  9 15:58:51 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 9 Mar 2016 16:58:51 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E03714.9070700@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
Message-ID: <alpine.DEB.2.02.1603091651460.31096@uplift.swm.pp.se>

On Wed, 9 Mar 2016, Nick Hilliard wrote:

> used.  Some will want 9000, some 9200, others ??4470 and some people

I have a strong opinion for jumboframes=9180bytes (IPv4/IPv6 MTU), partly 
because there are two standards referencing this size (RFC 1209 and 1626), 
and also because all major core router vendors support this size now that 
Juniper has decided (after some pushing) to start supporting it in more 
recent software on all their major platforms (before that they had too low 
L2 MTU to be able to support 9180 L3 MTU).

In order to deploy this to end systems, I however thing we're going to 
need something like 
https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 to make this 
work on mixed-MTU LANs. The whole thing about PMTUD blackhole detection is 
also going to be needed, so hosts try lower PMTU in case larger packets 
are dropped because of L2 misconfiguration in networks.

With IPv6 we have the chance to make PMTUD work properly and also have 
PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in 
my opinion (although it's strange how many hosts that seem to get away 
with 1492 (or is it 1496) MTU because they're using PPPoE).

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

From swmike at swm.pp.se  Wed Mar  9 16:00:07 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 9 Mar 2016 17:00:07 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E0469F.7000004@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
 <56E0469F.7000004@foobar.org>
Message-ID: <alpine.DEB.2.02.1603091659370.31096@uplift.swm.pp.se>

On Wed, 9 Mar 2016, Nick Hilliard wrote:

> interface MTU configured to be 9000 bytes, the packet will be
> blackholed, not rejected with a PTB.

That is only true if the router/host sets MRU=MTU. That is definitely not 
always the case.


From davidbass570 at gmail.com  Wed Mar  9 16:00:55 2016
From: davidbass570 at gmail.com (David Bass)
Date: Wed, 9 Mar 2016 11:00:55 -0500
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E0469F.7000004@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
 <56E0469F.7000004@foobar.org>
Message-ID: <ED84E4A4-0E9A-40D7-8108-FBE483B24910@gmail.com>

Could you do the same with a 1501 byte packet?

> On Mar 9, 2016, at 10:51 AM, Nick Hilliard <nick at foobar.org> wrote:
> 
> Kurt Kraut wrote:
>> Thank you for replying so quickly. I don't see why the consensus for an
>> MTU must be reached. IPv6 Path MTU Discovery would handle it by itself,
>> wouldn't it? If one participant supports 9k and another 4k, the traffic
>> between them would be at 4k with no manual intervention. If to
>> participants adopts 9k, hooray, it will be 9k thanks do PMTUD.
>> 
>> Am I missing something?
> 
> for starters, if you send a 9001 byte packet to a router which has its
> interface MTU configured to be 9000 bytes, the packet will be
> blackholed, not rejected with a PTB.
> 
> Even if it weren't, how many icmp PTB packets per second would a router
> be happy to generate before rate limiters kicked in?  Once someone
> malicious works that out, they can send that number of crafted packets
> per second through the IXP, thereby creating a denial of service situation.
> 
> There are many other problems, such as pmtud not working properly in the
> general case.
> 
> Nick
> 

From dmburgess at linktechs.net  Wed Mar  9 16:01:12 2016
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Wed, 9 Mar 2016 16:01:12 +0000
Subject: Cogent - Google - HE Fun
Message-ID: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent?   If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else?

[DennisBurgessSignature]
www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>


From JJaritsch at anexia-it.com  Wed Mar  9 16:09:52 2016
From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=)
Date: Wed, 9 Mar 2016 16:09:52 +0000
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
Message-ID: <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>

Hi,

mail from Cogent: 
>>>>
Dear Cogent Customer,

Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach.

Google uses transit providers to announce their IPv4 routes to Cogent.

At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers.

We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation.
<<<<

Mail from Google:
>>>>
Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us.

Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers.

For more information in how to peer directly with Google please visit https://peering.google.com
<<<<

best regards

J?rgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: JJaritsch at anexia-it.com 
Web: http://www.anexia-it.com 



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+jjaritsch=anexia-it.com at nanog.org] Im Auftrag von Dennis Burgess
Gesendet: Mittwoch, 09. M?rz 2016 17:01
An: North American Network Operators' Group
Betreff: Cogent - Google - HE Fun

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent?   If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else?

[DennisBurgessSignature]
www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>


From nanog at ics-il.net  Wed Mar  9 16:18:27 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Wed, 9 Mar 2016 10:18:27 -0600 (CST)
Subject: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
Message-ID: <575083343.3151.1457540303390.JavaMail.mhammett@ThunderFuck>

http://mailman.nanog.org/pipermail/nanog/2016-February/084147.html 




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



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


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

From: "Dennis Burgess" <dmburgess at linktechs.net> 
To: "North American Network Operators' Group" <nanog at nanog.org> 
Sent: Wednesday, March 9, 2016 10:01:12 AM 
Subject: Cogent - Google - HE Fun 

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent? If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else? 

[DennisBurgessSignature] 
www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburgess at linktechs.net<mailto:dmburgess at linktechs.net> 



From swmike at swm.pp.se  Wed Mar  9 16:19:57 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 9 Mar 2016 17:19:57 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <ED84E4A4-0E9A-40D7-8108-FBE483B24910@gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
 <56E0469F.7000004@foobar.org>
 <ED84E4A4-0E9A-40D7-8108-FBE483B24910@gmail.com>
Message-ID: <alpine.DEB.2.02.1603091716180.31096@uplift.swm.pp.se>

On Wed, 9 Mar 2016, David Bass wrote:

> Could you do the same with a 1501 byte packet?

I have many times ping:ed with 10000 byte packets on a device that has "ip 
mtu 9000" configured on it, so it sends out two fragments, one being 9000, 
the other one around 1100 bytes, only to get back a stream of fragments, 
none of them larger than 1500 bytes.

MTU and MRU are two different things.

Regarding jumbo usage, the biggest immediate benefit I can see would be if 
two ISPs want to exchange tunneled traffic with each other, even if the 
customer access is 1500, there is definitely benefit in being able to slap 
an L3 tunnel header on that packet, send it as ~1550 bytes to the other 
ISP, and then they take off the header again, without having to handle 
tunnel packet fragments (which tend to be quite resource intensive).

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

From saku at ytti.fi  Wed Mar  9 16:20:05 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 18:20:05 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <20160309143419.GG1163@22.rev.meerval.net>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
Message-ID: <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>

On 9 March 2016 at 16:34, Job Snijders <job at instituut.net> wrote:
>     https://www.nanog.org/sites/default/files/wednesday.general.steenbergen.antijumbo.pdf

IXP can verify if MTU is too large or too small with active poller.

Poller in the IXP has too large MTU, it tries to send ping packets
with max_size+1, if they work, customer has too large MTU. Also it
tries to send max_size, if it does not work, customer has too small
MTU. As icing on top, it tries to send max_size+1 but fragments it to
max_size and 1, and sees what comes back.

IXP is only interface in whole of Internet which collapses MTU to
1500B, private peers regularly have higher MTU, ~everyone runs core at
higher MTU.

I think it's crucial that we stop thinking MTU as single thing, we
should separate edge MTU and core MTU, that is how we already think
and provision when we think about our own network. Then question
becomes, is IXP edge or core? I would say run core MTU in IXP, so edge
MTU can be tunneled without fragmentation over it.
IXP can offer edgeMTU and coreMTU VLANs, so that people who are
religiously against it, can only peer in edgeMTU VLAN.

-- 
  ++ytti

From joelja at bogus.com  Wed Mar  9 16:27:13 2016
From: joelja at bogus.com (joel jaeggli)
Date: Wed, 9 Mar 2016 08:27:13 -0800
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <alpine.DEB.2.02.1603091651460.31096@uplift.swm.pp.se>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <alpine.DEB.2.02.1603091651460.31096@uplift.swm.pp.se>
Message-ID: <0eedf5e0-2551-9073-5c43-3376ccd2f15d@bogus.com>

On 3/9/16 7:58 AM, Mikael Abrahamsson wrote:
> On Wed, 9 Mar 2016, Nick Hilliard wrote:
> 
>> used.  Some will want 9000, some 9200, others ??4470 and some people
> 
> I have a strong opinion for jumboframes=9180bytes (IPv4/IPv6 MTU),
> partly because there are two standards referencing this size (RFC 1209
> and 1626), and also because all major core router vendors support this
> size now that Juniper has decided (after some pushing) to start
> supporting it in more recent software on all their major platforms
> (before that they had too low L2 MTU to be able to support 9180 L3 MTU).
> 
> In order to deploy this to end systems, I however thing we're going to
> need something like
> https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 to make this
> work on mixed-MTU LANs. The whole thing about PMTUD blackhole detection
> is also going to be needed, so hosts try lower PMTU in case larger
> packets are dropped because of L2 misconfiguration in networks.
> 
> With IPv6 we have the chance to make PMTUD work properly and also have

The prospects for that seem relatively dire. of course whats being
discussed here is the mixed L2 case, where the device will probably not
sent icmp6 ptb anyway but rather simply discard the packet as a giant.

> PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in
> my opinion (although it's strange how many hosts that seem to get away
> with 1492 (or is it 1496) MTU because they're using PPPoE).

if your adv_mss is set accordingly you can get away with
 a lot.
> 


-------------- 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/20160309/9c5baaaf/attachment.pgp>

From hugo at slabnet.com  Wed Mar  9 17:06:07 2016
From: hugo at slabnet.com (Hugo Slabbert)
Date: Wed, 9 Mar 2016 09:06:07 -0800
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E03400.30706@Janoszka.pl>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03400.30706@Janoszka.pl>
Message-ID: <20160309170607.GC24295@bamboo.slabnet.com>

On Wed 2016-Mar-09 15:32:32 +0100, Grzegorz Janoszka <Grzegorz at Janoszka.pl> wrote:

>On 09/03/2016 15:26, Kurt Kraut via NANOG wrote:
>>Could anyone share with me Internet Exchanges you know that allow jumbo
>>frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
>>from it?
>
>Netnod does it in separate vlan's.
>
>-- 
>Grzegorz Janoszka

Same for the SIX.

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- 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/20160309/56c7442d/attachment.pgp>

From jlewis at lewis.org  Wed Mar  9 17:25:31 2016
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 9 Mar 2016 12:25:31 -0500 (EST)
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
Message-ID: <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>

In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm 
not surprised.  I suggested it during talks with GOOG roughly 10 years 
ago...not saying I had any influence...I'm pretty sure I did not. :)

GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from 
them or someone else to get to Cogent).  If you're well peered / 
multihomed, it's not much of an issue.  If you're a single-homed Cogent 
customer, you should complain to Cogent that they're not providing full 
IPv6 connectivity.

On Wed, 9 Mar 2016, J?rgen Jaritsch wrote:

> Hi,
>
> mail from Cogent:
>>>>>
> Dear Cogent Customer,
>
> Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach.
>
> Google uses transit providers to announce their IPv4 routes to Cogent.
>
> At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers.
>
> We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation.
> <<<<
>
> Mail from Google:
>>>>>
> Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us.
>
> Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers.
>
> For more information in how to peer directly with Google please visit https://peering.google.com
> <<<<
>
> best regards
>
> J?rgen Jaritsch
> Head of Network & Infrastructure
>
> ANEXIA Internetdienstleistungs GmbH
>
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
>
> E-Mail: JJaritsch at anexia-it.com
> Web: http://www.anexia-it.com
>
>
>
> 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+jjaritsch=anexia-it.com at nanog.org] Im Auftrag von Dennis Burgess
> Gesendet: Mittwoch, 09. M?rz 2016 17:01
> An: North American Network Operators' Group
> Betreff: Cogent - Google - HE Fun
>
> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent?   If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else?
>
> [DennisBurgessSignature]
> www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>
>
>

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

From nick at foobar.org  Wed Mar  9 18:14:29 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 18:14:29 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
Message-ID: <56E06805.9010800@foobar.org>

Saku Ytti wrote:
> Poller in the IXP has too large MTU, it tries to send ping packets
> with max_size+1, if they work, customer has too large MTU. Also it
> tries to send max_size, if it does not work, customer has too small
> MTU. As icing on top, it tries to send max_size+1 but fragments it to
> max_size and 1, and sees what comes back.

you're recommending that routers at IXPs do inflight fragmentation?

Nick


From lyndon at orthanc.ca  Wed Mar  9 18:17:58 2016
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Wed, 9 Mar 2016 10:17:58 -0800 (PST)
Subject: remote serial console (IP to Serial)
In-Reply-To: <20160309053642.GB2304@geeks.org>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
 <20160308192122.GA24295@bamboo.slabnet.com>
 <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
 <20160309053642.GB2304@geeks.org>
Message-ID: <alpine.BSF.2.20.1603091015080.75964@orthanc.ca>

> I'd get something like a 1U ATOM server ($120 eBay) with small SSD
> ($18).  Runup your favorite FOSS OS, and conserver.  For more than the
> single real serialport, you can most likely fit a USB hub inside
> the case still, and hang a number of USB serial dongles off.

We use Raspberry Pi 2s with single- and 8-port USB serial dongles. Works 
like a charm, especially with tmux installed.

--lyndon

From nick at foobar.org  Wed Mar  9 18:18:35 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 18:18:35 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <alpine.DEB.2.02.1603091716180.31096@uplift.swm.pp.se>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
 <56E0469F.7000004@foobar.org>
 <ED84E4A4-0E9A-40D7-8108-FBE483B24910@gmail.com>
 <alpine.DEB.2.02.1603091716180.31096@uplift.swm.pp.se>
Message-ID: <56E068FB.2030303@foobar.org>

Mikael Abrahamsson wrote:
> I have many times ping:ed with 10000 byte packets on a device that has
> "ip mtu 9000" configured on it, so it sends out two fragments, one being
> 9000, the other one around 1100 bytes, only to get back a stream of
> fragments, none of them larger than 1500 bytes.

here's some data on INEX from a server interface with 9000 mtu.  fping
has 40 bytes overhead:

> # wc -l ixp-router-addresses.txt
>       85 ixp-router-addresses.txt
> # fping -b 1460 < ixp-router-addresses.txt | grep -c unreachable
> 0
> # fping -b 1500 < ixp-router-addresses.txt | grep -c unreachable
> 10
> # fping -b 5000 < ixp-router-addresses.txt | grep -c unreachable
> 11
> # fping -b 8960 < ixp-router-addresses.txt | grep -c unreachable
> 12

Out of interest, there were 5 different vendors in the output, according
to the MAC addresses returned.Some of this may be caused by
inappropriate icmp filtering on the routers, but the point is that it
would be unwise to depend on routers doing the right thing here. If
you're going to have a jumbo mtu vlan at an IXP, the VLAN needs to be a
hard specification, not an aspiration with any variance.

Nick


From nick at flhsi.com  Wed Mar  9 18:22:34 2016
From: nick at flhsi.com (Nick Olsen)
Date: Wed, 9 Mar 2016 13:22:34 -0500
Subject: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
Message-ID: <98d24c4feea34a84bb7fe0b623e11900@flhsi.com>

This doesn't surprise me. Cogent get's into Peering Chicken from time to 
time. Just like Cogent and HE still have no IPv6 peering. *Insert picture 
of cake here*.
  
 Can also confirm I'm not learning  AS15169 routes via Cogent v6.

Nick Olsen
Network Operations  (855) FLSPEED  x106

  

----------------------------------------
 From: "Dennis Burgess" <dmburgess at linktechs.net>
Sent: Wednesday, March 09, 2016 11:12 AM
To: "North American Network Operators' Group" <nanog at nanog.org>
Subject: Cogent - Google - HE Fun   
I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at 
all. I was told google pulled all of their peering with Cogent? If I bring 
up a SIT tunnel with HE, I get the prefixes but at horrible speed and 
latency .. anyone else?

[DennisBurgessSignature]
www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - 
dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>

 


From saku at ytti.fi  Wed Mar  9 18:23:15 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 20:23:15 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E06805.9010800@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
Message-ID: <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>

On 9 March 2016 at 20:14, Nick Hilliard <nick at foobar.org> wrote:
> you're recommending that routers at IXPs do inflight fragmentation?

I'm suggesting IXP has active poller which detects customer MTU misconfigs.

-- 
  ++ytti

From nick at foobar.org  Wed Mar  9 18:25:59 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 18:25:59 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
Message-ID: <56E06AB7.7020307@foobar.org>

Saku Ytti wrote:
> I'm suggesting IXP has active poller which detects customer MTU misconfigs.

any ixp configuration which requires active polling to ensure correct
configuration is doomed to failure.  You are completely overestimating
human nature if you believe that the IXP operator can make this work by
harassing people into configuring the correct mtu, even if the data is
clear that their systems are misconfigured.

Nick


From saku at ytti.fi  Wed Mar  9 18:29:05 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 20:29:05 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E06AB7.7020307@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
Message-ID: <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>

On 9 March 2016 at 20:25, Nick Hilliard <nick at foobar.org> wrote:

> any ixp configuration which requires active polling to ensure correct
> configuration is doomed to failure.  You are completely overestimating
> human nature if you believe that the IXP operator can make this work by
> harassing people into configuring the correct mtu, even if the data is
> clear that their systems are misconfigured.

It's not a novel idea, IXPs already do active polling, even ARP
sponges. In a competitive market, hopefully customers will choose the
IXP operator who knows how to ensure minimal pain for the customers.

-- 
  ++ytti

From owen at delong.com  Wed Mar  9 18:44:13 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 9 Mar 2016 10:44:13 -0800
Subject: remote serial console (IP to Serial)
In-Reply-To: <20160309053642.GB2304@geeks.org>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
 <20160308192122.GA24295@bamboo.slabnet.com>
 <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
 <20160309053642.GB2304@geeks.org>
Message-ID: <D406025D-D935-4E6D-9DAD-2D4393938723@delong.com>

If you're going to go that route, a PI is a much cheaper moboard to build on. Also consider the Pine64 (cheaper and more powerful than the PI) 

> On Mar 8, 2016, at 21:36, Doug McIntyre <merlyn at geeks.org> wrote:
> 
>> On Tue, Mar 08, 2016 at 10:45:30AM -0900, Royce Williams wrote:
>>> On Tue, Mar 8, 2016 at 10:21 AM, Hugo Slabbert <hugo at slabnet.com> wrote:
>>> I'm surprised no one's mentioned freetserv[1] yet.  I haven't used them so
>>> don't consider this an endorsement, but on the surface it looks to be a
>>> good balance of "open / DIY" and "supportable".
> ..
>> This is great!  A mainstream, patchable OS -- not locked into a half-baked
>> OS or roll-your-own-TCP-stack hell I've seen in some remote serial and
>> power devices.
> ..
> 
> Yes, instead of a hacked together hardwareboard, or appliance with
> firmware that never gets updated stuck in SSH v1 days (old Cisco?)..
> Freetserv looks interesting, but very costly once you add up the BOM. 
> 
> I'd get something like a 1U ATOM server ($120 eBay) with small SSD
> ($18).  Runup your favorite FOSS OS, and conserver.  For more than the
> single real serialport, you can most likely fit a USB hub inside
> the case still, and hang a number of USB serial dongles off.
> 
> Rackmountable, maintainable, and conserver works great.
> 
> 

From bzs at theworld.com  Wed Mar  9 18:48:06 2016
From: bzs at theworld.com (bzs at theworld.com)
Date: Wed, 9 Mar 2016 13:48:06 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <56DF1BA9.6070008@ttec.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <56DF14C3.9070107@satchell.net> <56DF1BA9.6070008@ttec.com>
Message-ID: <22240.28646.478180.271148@pcls8.std.com>


For a long time I used an Equinox SST which was a PCI card and a
plugboard of (daisy-chain-able up to 128) 16 x RJ-45 serial ports. It
was handy in one machine room, usually a Cat-5 RJ-45 cable with a
D-connector was all that was needed.

Unfortunately the Linux driver seems to have disappeared into the
sands of time though it would work with something like SuSE 9.x, maybe
10.x. That is, 2.4 maybe 2.6 kernels, I don't think SuSE mattered but
that's what I used.

With the driver and hardware installed it would present as a bunch of
/dev/ttyQ?? devices.

I'd use an xterm workalike 'eterm' which could take a device on the
command line and it'd work. I think screen could also work but firing
up separate terminal windows for different ports was convenient. And
eterm was rather pretty, not sure what happened to it, but you could
probably use kermit or cu etc in a pinch with enough magic.

I'm curious if anyone still uses this and perhaps got it working with
more modern kernels? I believe it's mentioned in the newer kernel
build configuration (make xconfig, whatever) but doesn't work.

Not a big deal to install an old OS on a spare machine. Or perhaps
even in a virtual machine with some sort of device passthru? Never
looked into that.

No idea where you'd find the hardware but it was a neat device and if
you can't find their driver stuff I could send it to you as a tarball
tho I think it's still up on whatever Equinox became. Ok here it is I
noted it:

  http://www.connectivity.avocent.com/drivers/superserial/eqnx_4.12d.asp

So you'd just login to that machine and fire up windows to access the
Equinox/SST serial ports (to answer the remote part of the question.)

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From nick at foobar.org  Wed Mar  9 18:59:45 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 9 Mar 2016 18:59:45 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
Message-ID: <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>

On 9 Mar 2016, at 18:29, Saku Ytti <saku at ytti.fi> wrote:
> It's not a novel idea, IXPs already do active polling, even ARP
> sponges. In a competitive market, hopefully customers will choose the
> IXP operator who knows how to ensure minimal pain for the customers.

There is a critical difference between these two situations. In the case of an arp sponge, the ixp operator has control of both the polling and the workaround. In the case of mtu management they would only have control of the polling, not the remediation. The point I was making is that an ixp operator can only control their own infrastructure. Once it's someone else's infrastructure, all you can do is make polite suggestions.

Nick


From saku at ytti.fi  Wed Mar  9 19:17:21 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 21:17:21 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
Message-ID: <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>

On 9 March 2016 at 20:59, Nick Hilliard <nick at foobar.org> wrote:

> There is a critical difference between these two situations. In the case of an arp sponge, the ixp operator has control of both the polling and the workaround. In the case of mtu management they would only have control of the polling, not the remediation. The point I was making is that an ixp operator can only control their own infrastructure. Once it's someone else's infrastructure, all you can do is make polite suggestions.

If customer does not react, put it on quarantine VLAN. This can be
automated too. Wrong MTU => open internal case, contact customers
email, no customer response in N days, quarantine VLAN.

Even the most outrageous success stories in the world, majority of the
people would have said before attempting that it won't work, because
that is safe and easy. And usually they are right, most things don't
work, but it's very difficult to actually know without trying what
works and what does.
Luckily we have actual IXPs running big and small VLAN MTUs, even
without this monitoring capability, and it Internet still works.

-- 
  ++ytti

From effulgence at gmail.com  Wed Mar  9 19:37:06 2016
From: effulgence at gmail.com (Aris Lambrianidis)
Date: Wed, 09 Mar 2016 20:37:06 +0100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
Message-ID: <56E07B62.4080505@gmail.com>

Saku Ytti wrote:
>
> If customer does not react, put it on quarantine VLAN. This can be
> automated too. Wrong MTU => open internal case, contact customers
> email, no customer response in N days, quarantine VLAN.
>
> Even the most outrageous success stories in the world, majority of the
> people would have said before attempting that it won't work, because
> that is safe and easy. And usually they are right, most things don't
> work, but it's very difficult to actually know without trying what
> works and what does.
> Luckily we have actual IXPs running big and small VLAN MTUs, even
> without this monitoring capability, and it Internet still works.
>
Imo, there is not enough value for an IXP to do such monitoring,
especially assuming we agree
on Richard Steenbergen's conclusion in his presentation.

Promoting that kind of monitoring  as a differentiator will surely help
adding an extra bullet
point on marketing material, but will be a trivial part in the decision
process of a potential customer.

--Aris


From nick at foobar.org  Wed Mar  9 19:46:54 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 19:46:54 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
Message-ID: <56E07DAE.5040008@foobar.org>

Saku Ytti wrote:
> If customer does not react, put it on quarantine VLAN. This can be
> automated too. Wrong MTU => open internal case, contact customers
> email, no customer response in N days, quarantine VLAN.

... and then the customer will leave the service down because it the
primary peering lan works fine and they couldn't be bothered fixing
jumbo lan connectivity because the neteng who wanted the 9000 byte mtu
connectivity in the first place got distracted by a squirrel or left the
company or was too busy doing other things.

> work, but it's very difficult to actually know without trying what
> works and what does.

I've spent a good deal of time and effort trying to get a jumbo peering
vlan to work and it didn't work for the reasons that I've mentioned, and
others.

For example, many types of hardware don't allow you to specify a
different MTU for different .1q tags on the same physical interface.
This means that if you want a connection to a jumbo MTU vlan and a
standard mtu vlan, you needed two separate connections into the IXP.  At
that point, the ixp participant is unlikely to want to bother because
there's no cost:value justification in getting the second connection.

Don't get me wrong: jumbo MTU IXPs are a great idea in theory.  In
practice, they cause an inordinate amount of pain.

Nick

From saku at ytti.fi  Wed Mar  9 19:54:10 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 21:54:10 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E07DAE.5040008@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
Message-ID: <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>

On 9 March 2016 at 21:46, Nick Hilliard <nick at foobar.org> wrote:
> I've spent a good deal of time and effort trying to get a jumbo peering
> vlan to work and it didn't work for the reasons that I've mentioned, and
> others.

It works and has worked 2 decades in real IXP.

-- 
  ++ytti, boy who didn't cry wolf

From bill at herrin.us  Wed Mar  9 19:55:31 2016
From: bill at herrin.us (William Herrin)
Date: Wed, 9 Mar 2016 14:55:31 -0500
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <CAPbn28kHTxBvXgOiguxcXp8+d15+LHXcqmFUBZ-61t3vfJ7dzQ@mail.gmail.com>
Message-ID: <CAP-guGWs0t0vkB=Qxn-DKV+=thzE6x+-CLeH=7M89Ej2aiRk+w@mail.gmail.com>

On Wed, Mar 9, 2016 at 9:50 AM, Kurt Kraut via NANOG <nanog at nanog.org> wrote:
> Thank you for replying so quickly. I don't see why the consensus for an MTU
> must be reached. IPv6 Path MTU Discovery would handle it by itself,
> wouldn't it? If one participant supports 9k and another 4k, the traffic
> between them would be at 4k with no manual intervention. If to participants
> adopts 9k, hooray, it will be 9k thanks do PMTUD.
>
> Am I missing something?

Hi Kurt,

As far as I know, there is no "discovery" of MTU on an Ethernet LAN.
That's Link MTU, not Path MTU. Unhappy things happen when the
participants don't agree exactly about the layer-2 MTU. It's a layer 2
thing; IPv6 and layer 3 pmtud can't discover that layer 2 problem.
Pmtud discovers when a link *reports* that the MTU is too small, not
when packets vanish as a result of a layer 2 error. As a result,
non-1500 byte MTUs in a network with multiple connected organizations
can be brittle: human beings are bad at each configuring their router
to exactly the same non-standard configuration as everybody else.

Other than that one problem, high MTUs at an IXP are a good thing, not
a bad one. Because IPv4 path MTU discovery is so badly broken, it's
desirable to maintain a minimum MTU of 1500 bytes across the core,
even as packets travel through tunnels, VPNs and other layered
structures that add bytes to the payload.

Greater than 1500 byte MTUs to the customer, on the other hand, are a
bad thing. The aggravate the problems with PMTUd.

Regards,
Bill Herrin


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

From swmike at swm.pp.se  Wed Mar  9 19:59:55 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 9 Mar 2016 20:59:55 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E07DAE.5040008@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
Message-ID: <alpine.DEB.2.02.1603092057500.31096@uplift.swm.pp.se>

On Wed, 9 Mar 2016, Nick Hilliard wrote:

> For example, many types of hardware don't allow you to specify a
> different MTU for different .1q tags on the same physical interface.

What hardware types typically connected to an IXP would that be, where 
this would be a problem?

On all platforms I've configured and connected to an IXP, they would all 
be configured by setting max L2 MTU on the main interface, and then you 
configure whatever needed IPv4 and IPv6 L3 MTU on the subinterface.

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

From nick at foobar.org  Wed Mar  9 20:28:07 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 20:28:07 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <alpine.DEB.2.02.1603092057500.31096@uplift.swm.pp.se>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <alpine.DEB.2.02.1603092057500.31096@uplift.swm.pp.se>
Message-ID: <56E08757.8050801@foobar.org>

Mikael Abrahamsson wrote:
> On all platforms I've configured and connected to an IXP, they would all
> be configured by setting max L2 MTU on the main interface, and then you
> configure whatever needed IPv4 and IPv6 L3 MTU on the subinterface.

iirc, we had problems with a bunch of ios based platforms.  It worked
fine on junos / xr platforms.  I share your surprise that this could
even have caused a problem, but it did.

Nick

From nick at foobar.org  Wed Mar  9 20:56:43 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 20:56:43 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
Message-ID: <56E08E0B.4040607@foobar.org>

Saku Ytti wrote:
> It works and has worked 2 decades in real IXP.

If you're referring to Netnod, this started out as a fddi platform with
a native max frame size of 4470.  Maintaining something which already
exists is not nearly as difficult as starting something from scratch and
trying to reach a critical mass.  In the case of INEX and several other
IXPs, it failed because of (in no particular order):

- hardware problems
- lack of interest among ixp participants outside individual pushers
- lack of consensus about what MTU should be chosen
- operational problems causing people to "temporarily disable
connectivity until someone can take a look at it", i.e. permanently.
- additional expense in some situations
- the main peering lan worked fine, ie no overriding value proposition
- pmtu problems
- fragile and troublesome to debug when things went wrong

>  ++ytti, boy who didn't cry wolf

Many IXPs have either looked at or attempted to build jumbo peering
lans.  You can see how well they worked out by looking at the number of
successful deployments.  The reason for this tiny number isn't due to
lack of effort on the part of the ixp operators.

Nick, boy who did the jumbo vlan thing and got the t shirt

From swmike at swm.pp.se  Wed Mar  9 21:17:13 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 9 Mar 2016 22:17:13 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E08E0B.4040607@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
 <56E08E0B.4040607@foobar.org>
Message-ID: <alpine.DEB.2.02.1603092212580.31096@uplift.swm.pp.se>

On Wed, 9 Mar 2016, Nick Hilliard wrote:

> Many IXPs have either looked at or attempted to build jumbo peering 
> lans.  You can see how well they worked out by looking at the number of 
> successful deployments.  The reason for this tiny number isn't due to 
> lack of effort on the part of the ixp operators.

I believe all IXP operators should offer higher MTU vlans, so that the 
ISPs who are interested can use them. If individual ISPs are not 
interested, then they don't have to use it. It's available if they gain 
interest.

The whole point of an IX is to be a market place where interested parties 
can talk to each other. The IXP should not limit (to reasonable extent) 
what services the ISPs can run across the infrastructure. If two ISPs need 
higher than 1500 MTU between them, then forcing them to connect outside of 
the IXP L2 infrastructure doesn't make any sense to me, when it's fairly 
easy for the IXP to offer this service.

The IXPs who offer "private lans" between two parties, do they generally 
limit these as well to 1500 L3 MTU?

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

From saku at ytti.fi  Wed Mar  9 21:19:46 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 23:19:46 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E08757.8050801@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <alpine.DEB.2.02.1603092057500.31096@uplift.swm.pp.se>
 <56E08757.8050801@foobar.org>
Message-ID: <CAAeewD9iFXmHcyO=AsNB8pKHF9d=aTnLnUpHV1Gpx+ny0DTPpQ@mail.gmail.com>

On 9 March 2016 at 22:28, Nick Hilliard <nick at foobar.org> wrote:
> iirc, we had problems with a bunch of ios based platforms.  It worked
> fine on junos / xr platforms.  I share your surprise that this could
> even have caused a problem, but it did.

This is very poor reason to kill it for everyone, 'I recall I may have
found platform where it maybe didn't work'.

Yet, it's super common go have L3Termination - L2Aggregation - Customer.

And sell various MTU options to customers, even use the L2Aggregation
as core between two L3Termination. All of these require per
logical-interface L3 MTU, while L2 MTU is usually set to max.
>From Cisco, I've done this at least on 720x, 7301, 7304 NPE/NSE, 7600,
6500, GSR, CRS-1, ASR1k, ASR9k, 2600, 3600, ASR9k, probably some
others too.

-- 
  ++ytti

From bholloway at pavlovmedia.com  Wed Mar  9 21:24:14 2016
From: bholloway at pavlovmedia.com (Bryan Holloway)
Date: Wed, 9 Mar 2016 21:24:14 +0000
Subject: .pro whois registry down?
Message-ID: <D0657056-E9C9-49E4-9028-16097748EC42@pavlovmedia.com>

Anyone else noticing that the .pro TLD is failing for some things, and their WHOIS registry appears to be unavailable?

I appear to be able to resolve, but whois times out, and we're getting reports that mail isn't going through for some folks with this TLD.



From saku at ytti.fi  Wed Mar  9 21:25:32 2016
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 9 Mar 2016 23:25:32 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E08E0B.4040607@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
 <56E08E0B.4040607@foobar.org>
Message-ID: <CAAeewD-w-Oi9--6imcyeCZYsPwcoY2mK2OUk4jorrmkGbevX+A@mail.gmail.com>

On 9 March 2016 at 22:56, Nick Hilliard <nick at foobar.org> wrote:

> - hardware problems

If we build everything on LCD, we'll have Internet where just HTTP/80
works on 576B. You can certainly find platform which has problems
doing else.

> - lack of interest among ixp participants outside individual pushers

They probably want faster horses.

> - lack of consensus about what MTU should be chosen

If we stop thinking of MTU as single entity and start thinking it as
edge MTU and core MTU, it becomes less important, as long as core MTU
covers overhead over edge.
I would go for 1500B edge, and 9100B core, but that's just me.

> - operational problems causing people to "temporarily disable
> connectivity until someone can take a look at it", i.e. permanently.

Vague. But ultimately this is what you will do always when issue is
not solved, sometime you just have to give up, 'ok far end is gone,
let's close this connection'.

> - additional expense in some situations

Vague. 'Sometimes something has some cost which is more than in some
other situation sometimes'.

> - the main peering lan worked fine, ie no overriding value proposition

>99% Internet users likely are happy with 576B HTTP only INET. I'm not still comfortable accepting that it's only thing Internet shoudl be.

> - pmtu problems

Immaterial, it is there regardless.

> - fragile and troublesome to debug when things went wrong

I've proposed automated, fully toolisable solution for IXP to verify
customers have correct config. People who don't want to deal with
this, who don't believe in this, can peer only over edgeMTU VLAN and
have completely same situation as today.

-- 
  ++ytti

From dougb at dougbarton.us  Wed Mar  9 21:51:28 2016
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 9 Mar 2016 13:51:28 -0800
Subject: .pro whois registry down?
In-Reply-To: <D0657056-E9C9-49E4-9028-16097748EC42@pavlovmedia.com>
References: <D0657056-E9C9-49E4-9028-16097748EC42@pavlovmedia.com>
Message-ID: <56E09AE0.1030301@dougbarton.us>

On 03/09/2016 01:24 PM, Bryan Holloway wrote:
> Anyone else noticing that the .pro TLD is failing for some things, and their WHOIS registry appears to be unavailable?

The delegation from the root to PRO, and the PRO name servers 
themselves, seem to be working.

> I appear to be able to resolve, but whois times out, and we're getting reports that mail isn't going through for some folks with this TLD.

The address records for whois.dotproregistry.net are missing.

Doug


From nick at foobar.org  Wed Mar  9 22:01:34 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 22:01:34 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD-w-Oi9--6imcyeCZYsPwcoY2mK2OUk4jorrmkGbevX+A@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
 <56E08E0B.4040607@foobar.org>
 <CAAeewD-w-Oi9--6imcyeCZYsPwcoY2mK2OUk4jorrmkGbevX+A@mail.gmail.com>
Message-ID: <56E09D3E.40807@foobar.org>

Saku Ytti wrote:
> I would go for 1500B edge, and 9100B core, but that's just me.

Other people would be fine with 1522 core because that suits both their
needs and equipment limitations.  So what do you do?  Go with 9100
because it suits you, or 9000 because that's what lots of other people
use?  Or 4470 because of history?  Or 1522 because that enables you to
pad on some extra headers and get 1500 payload, and works for more
people but is too meh for others to contemplate?  Or 9000 and some slop
because you commit to carrying 9000 payload on your network, whereas
other people only commit to 9000 total frame size?

Do you understand how bad humans are at making decisions like this?

And how truly awful some equipment is that people install at IXPs?

> I've proposed automated, fully toolisable solution for IXP to verify
> customers have correct config.

but you haven't solved the human problem.  The IXP operator does not
have enable on IXP participant routers.

Nick


From saku at ytti.fi  Wed Mar  9 22:08:06 2016
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 10 Mar 2016 00:08:06 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E09D3E.40807@foobar.org>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
 <56E08E0B.4040607@foobar.org>
 <CAAeewD-w-Oi9--6imcyeCZYsPwcoY2mK2OUk4jorrmkGbevX+A@mail.gmail.com>
 <56E09D3E.40807@foobar.org>
Message-ID: <CAAeewD9FPg=tCVXW5C-_bMoD6g+CLRjQZVDsDr=R5vE1KOStUg@mail.gmail.com>

On 10 March 2016 at 00:01, Nick Hilliard <nick at foobar.org> wrote:

> Other people would be fine with 1522 core because that suits both their
> needs and equipment limitations.  So what do you do?  Go with 9100
> because it suits you, or 9000 because that's what lots of other people
> use?  Or 4470 because of history?  Or 1522 because that enables you to
> pad on some extra headers and get 1500 payload, and works for more
> people but is too meh for others to contemplate?  Or 9000 and some slop
> because you commit to carrying 9000 payload on your network, whereas
> other people only commit to 9000 total frame size?

I don't think it's super important. IXP will do what they think is
best for the coreMTU.

> And how truly awful some equipment is that people install at IXPs?

People with awful kit are free to do edgeMTU only.

> but you haven't solved the human problem.  The IXP operator does not
> have enable on IXP participant routers.

Member may puke L2 loop to IXP, you must have some channel to deal
with your customers. If that channel fails you quarantine the VLAN or
shut down the port.
If you cannot have any communication with your members I can see how
this seems like particularly difficult problem.

-- 
  ++ytti

From mark.tinka at seacom.mu  Wed Mar  9 22:19:01 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 10 Mar 2016 00:19:01 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
Message-ID: <a0b66e9c-1a35-ec40-af70-03eae52eaeba@seacom.mu>



On 9/Mar/16 16:26, Kurt Kraut via NANOG wrote:

>
> Could anyone share with me Internet Exchanges you know that allow jumbo
> frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
> from it?

NAPAfrica in South Africa support jumbo frames:

    https://www.napafrica.net/

Little benefit to us since the majority of members don't run jumbo
frames. For some that do, it is unclear whether their backbones support
jumbo frames across the board.

Mark.

From nick at foobar.org  Wed Mar  9 22:21:43 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Mar 2016 22:21:43 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD9FPg=tCVXW5C-_bMoD6g+CLRjQZVDsDr=R5vE1KOStUg@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
 <56E08E0B.4040607@foobar.org>
 <CAAeewD-w-Oi9--6imcyeCZYsPwcoY2mK2OUk4jorrmkGbevX+A@mail.gmail.com>
 <56E09D3E.40807@foobar.org>
 <CAAeewD9FPg=tCVXW5C-_bMoD6g+CLRjQZVDsDr=R5vE1KOStUg@mail.gmail.com>
Message-ID: <56E0A1F7.7060607@foobar.org>

Saku Ytti wrote:
> Member may puke L2 loop to IXP, you must have some channel to deal
> with your customers.

First, mac filters.  Second, if someone l2 loops and it causes problems
because of hardware failure on our side, we reserve the right to pull
connectivity:

https://www.inex.ie/technical/maintenance

> In the case of emergencies, INEX reserves the right to perform
> critical maintenance on a 24x7x365 basis without prior notification
> to INEX members. Emergencies are defined as situations where:
[...]
> - member port misconfiguration or hardware/software bug causes loss of
> service or down-time for other INEX members, in the potential
> situation where this is not prevented by INEX port security measures

Fortunately, it's only rarely that this happens.

Third, someone puking an l2 loop to the IXP is a problem which may
affect the ixp infrastructure.  This is not the case when people muck up
their MTU config.  There is a demarcation line here:  one is an IXP
problem; the other is not.

Nick

From achatz at forthnet.gr  Wed Mar  9 22:22:28 2016
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 10 Mar 2016 00:22:28 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
Message-ID: <56E0A224.1050806@forthnet.gr>

I must be missing something very obvious here, because i cannot think of any reason why an IXP shouldn't enable the maximum possible MTU on its infrastructure to be available to its customers. Then it's clearly customers' decision on what MTU to use on their devices, as long as:

  * It fits inside IXP's MTU
  * It suits with any other customer's (exchanging traffic with) MTU


--
Tassos

Kurt Kraut via NANOG wrote on 9/3/16 16:26:
> Hi,
>
>
> I'm trying to convince my local Internet Exchange location (and it is not
> small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.
> For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
> connection/destination.
>
> For IPv4, it requires more planning. For instance, two datacenters tend to
> exchange relevant traffic because customers  with disaster recovery in mind
> (saving the same content in two different datacenters, two different
> suppliers). In most cases, these datacenters are quite far from each other,
> even in different countries. In this context, jumbo frames would allow max
> speed even the latency is from a tipical international link.
>
> Could anyone share with me Internet Exchanges you know that allow jumbo
> frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
> from it?
>
>
> Best regards,
>
>
> Kurt Kraut
>


From dot at dotat.at  Wed Mar  9 22:53:57 2016
From: dot at dotat.at (Tony Finch)
Date: Wed, 9 Mar 2016 22:53:57 +0000
Subject: .pro whois registry down?
In-Reply-To: <56E09AE0.1030301@dougbarton.us>
References: <D0657056-E9C9-49E4-9028-16097748EC42@pavlovmedia.com>
 <56E09AE0.1030301@dougbarton.us>
Message-ID: <alpine.LSU.2.00.1603092242150.8713@hermes-2.csi.cam.ac.uk>

Doug Barton <dougb at dougbarton.us> wrote:

> On 03/09/2016 01:24 PM, Bryan Holloway wrote:
> > Anyone else noticing that the .pro TLD is failing for some things, and
> > their WHOIS registry appears to be unavailable?
>
> The address records for whois.dotproregistry.net are missing.

Well, it depends how you find the .pro whois servers, and I am pleased
that my recent changes to FreeBSD whois handle this case OK.

If you use pro.whois-servers.net aka whois.registrypro.pro the connection
times out. (It is sad that the often excellent whois-servers.net doesn't
work as well as it used to.)

If you use whois.nic.pro then it works. (This is the standard name
required for new gTLDs.)

If you follow the referral from whois.iana.org to whois.afilias.net then
it works.

More on whois at http://fanf.livejournal.com/140505.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
East Dogger, Fisher, German Bight: Southeasterly 4 or 5. Slight or moderate.
Fog patches for a time. Moderate or good, occasionally very poor.

From listas at kurtkraut.net  Wed Mar  9 23:58:08 2016
From: listas at kurtkraut.net (Kurt Kraut)
Date: Wed, 9 Mar 2016 20:58:08 -0300
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E0A224.1050806@forthnet.gr>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
Message-ID: <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>

Hello folks,


First of all, thank you all for this amazing debate. So many important
ideas were exposed here and I wish we keep going on this. I've seen many
opposition to my proposal but I still remain on the side of jumbo frame
adoption for IXP. I'm pretty confident there is no need for a specific MTU
consensus and not all IXP participants are obligated to raise their
interface MTU if the IXP starts allowing jumbo frames.

One of the reasons I'm so surprised with concerns about compatibility and
breaking the internet I've seen here is the offers I get from my IP transit
providers: half of them offered me jumbo frame capable ports by default, it
wasn't a request. When this subject became important to me and I open
support tickets, half of them replied something like 'You don't need to
request it. From our end the max MTU is X'. The lowest X I got was 4400 and
the highest 9260 bytes. All my Tier-1 providers already provided me jumbo
frames IP transit. Even my south american IP Transit provider activated my
link with 9k MTU by default.

So we have Tier-1 backbones moving jumbo frames around continents, why in a
controlled L2 enviroment that usually resides in a single building and
managed by a single controller having jumbo frames is that concerning?

Best regards,


Kurt Kraut

2016-03-09 19:22 GMT-03:00 Tassos Chatzithomaoglou <achatz at forthnet.gr>:

> I must be missing something very obvious here, because i cannot think of
> any reason why an IXP shouldn't enable the maximum possible MTU on its
> infrastructure to be available to its customers. Then it's clearly
> customers' decision on what MTU to use on their devices, as long as:
>
>   * It fits inside IXP's MTU
>   * It suits with any other customer's (exchanging traffic with) MTU
>
>
> --
> Tassos
>
> Kurt Kraut via NANOG wrote on 9/3/16 16:26:
> > Hi,
> >
> >
> > I'm trying to convince my local Internet Exchange location (and it is not
> > small, exceed 1 terabit per second on a daily basis) to adopt jumbo
> frames.
> > For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
> > connection/destination.
> >
> > For IPv4, it requires more planning. For instance, two datacenters tend
> to
> > exchange relevant traffic because customers  with disaster recovery in
> mind
> > (saving the same content in two different datacenters, two different
> > suppliers). In most cases, these datacenters are quite far from each
> other,
> > even in different countries. In this context, jumbo frames would allow
> max
> > speed even the latency is from a tipical international link.
> >
> > Could anyone share with me Internet Exchanges you know that allow jumbo
> > frames (like https://www.gr-ix.gr/specs/ does) and how you notice
> benefit
> > from it?
> >
> >
> > Best regards,
> >
> >
> > Kurt Kraut
> >
>
>

From dougb at dougbarton.us  Thu Mar 10 00:29:08 2016
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 9 Mar 2016 16:29:08 -0800
Subject: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?
In-Reply-To: <CAF1dMVG9CD6vhm77X0qhX7VVjguJ9_nOS2Z1HNfB1Hqfx7p3Zg@mail.gmail.com>
References: <56E09AE0.1030301@dougbarton.us> <56E09B83.7000306@dougbarton.us>
 <d9d005baf983b63af38fe03ba96a168a@mail.gmail.com>
 <CAF1dMVG9CD6vhm77X0qhX7VVjguJ9_nOS2Z1HNfB1Hqfx7p3Zg@mail.gmail.com>
Message-ID: <56E0BFD4.7020403@dougbarton.us>

Joseph,

Thanks for the update. However the current state of things is not good 
... My Ubuntu host tries to use whois.dotproregistry.net, which has no 
address records. FreeBSD by default uses pro.whois-servers.net, which 
resolves to whois.registrypro.pro (which has an A record), but never 
returns with any data (arguably worse than failing immediately with an 
obvious error).

If it were me, I would have done the following:

1. Reach out to the OS vendors and the folks at whois-servers.net with 
information that the proper host name for your whois service is 
changing. Include a drop-dead date of 3 years in the future for the old 
names to stop working.

2. Place a CNAME at the two (or more?) old host names so that the 
service will continue to work in the meantime.

The CNAME costs you nothing, and while I agree that it should be able to 
be removed at some point in the future, having things not work at all in 
the short term is not the right approach.

It's also not realistic to expect folks to be able to chase this down on 
their own ... anyone familiar with using whois on the command line has 
most assuredly grown accustomed to the convenience of having it "just 
work," as it has for the last decade or so. While people certainly *can* 
go back to the "good old days" of having to hunt down each registry's 
whois server individually, it's hard to think of that as the best approach.

Is there some reason that the above can't be/hasn't been done that I'm 
missing?

Doug


On 03/09/2016 02:17 PM, Joseph Yee wrote:
> Hi Doug,
>
> Afilias had updated .PRO whois host in Jan 2016, and we filed the record
> to ICANN & IANA (http://www.iana.org/domains/root/db/pro.html).
>
> The new host is 'whois.afilias.net <http://whois.afilias.net>' and not
> 'whois.dotproregistry.net <http://whois.dotproregistry.net>' anymore.
>
> Some operating systems may not update their whois configuration yet.
> You may need to check and update the configuration manually for PRO
> WHOIS server before official patch were available.
>
> Best Regards,
> Joseph Yee
> Afilias
>
> On Wed, Mar 9, 2016 at 4:56 PM, Michael Flanagan <mflanagan at afilias.info
> <mailto:mflanagan at afilias.info>> wrote:
>
>     -----Original Message-----
>     From: Doug Barton [mailto:dougb at dougbarton.us
>     <mailto:dougb at dougbarton.us>]
>     Sent: Wednesday, March 09, 2016 4:54 PM
>     To: tld-admin-poc at afilias.info <mailto:tld-admin-poc at afilias.info>;
>     tld-tech-poc at afilias.info <mailto:tld-tech-poc at afilias.info>
>     Subject: [tld-admin-poc] Fwd: Re: .pro whois registry down?
>
>     FYI
>
>     -------- Forwarded Message --------
>     Subject: Re: .pro whois registry down?
>     Date: Wed, 9 Mar 2016 13:51:28 -0800
>     From: Doug Barton <dougb at dougbarton.us <mailto:dougb at dougbarton.us>>
>     To: Bryan Holloway <bholloway at pavlovmedia.com
>     <mailto:bholloway at pavlovmedia.com>>, NANOG list <nanog at nanog.org
>     <mailto:nanog at nanog.org>>
>
>     On 03/09/2016 01:24 PM, Bryan Holloway wrote:
>      > Anyone else noticing that the .pro TLD is failing for some
>     things, and
>      > their WHOIS registry appears to be unavailable?
>
>     The delegation from the root to PRO, and the PRO name servers
>     themselves,
>     seem to be working.
>
>      > I appear to be able to resolve, but whois times out, and we're
>     getting
>      > reports that mail isn't going through for some folks with this TLD.
>
>     The address records for whois.dotproregistry.net
>     <http://whois.dotproregistry.net> are missing.
>
>     Doug
>
>


From niels=nanog at bakker.net  Thu Mar 10 00:44:07 2016
From: niels=nanog at bakker.net (Niels Bakker)
Date: Thu, 10 Mar 2016 01:44:07 +0100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
Message-ID: <20160310004407.GA6838@excession.tpb.net>

* nanog at nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]:
>I'm pretty confident there is no need for a specific MTU consensus 
>and not all IXP participants are obligated to raise their interface 
>MTU if the IXP starts allowing jumbo frames.

You're wrong here.  The IXP switch platform cannot send ICMP Packet 
Too Big messages.  That's why everybody must agree on one MTU.


>So we have Tier-1 backbones moving jumbo frames around continents, 
>why in a controlled L2 enviroment that usually resides in a single 
>building and managed by a single controller having jumbo frames is 
>that concerning?

Because the L3 devices connected to it aren't controlled by a single entity.


	-- Niels.

From marka at isc.org  Thu Mar 10 00:54:27 2016
From: marka at isc.org (Mark Andrews)
Date: Thu, 10 Mar 2016 11:54:27 +1100
Subject: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?
In-Reply-To: Your message of "Wed, 09 Mar 2016 16:29:08 -0800."
 <56E0BFD4.7020403@dougbarton.us>
References: <56E09AE0.1030301@dougbarton.us> <56E09B83.7000306@dougbarton.us>
 <d9d005baf983b63af38fe03ba96a168a@mail.gmail.com>
 <CAF1dMVG9CD6vhm77X0qhX7VVjguJ9_nOS2Z1HNfB1Hqfx7p3Zg@mail.gmail.com>
 <56E0BFD4.7020403@dougbarton.us>
Message-ID: <20160310005427.3E818442EC61@rock.dv.isc.org>


Additionally 'whois' is free form text.  Whois doesn't include a
AI to workout what this free form text means so, no, there isn't a
actual referral for a whois application to use.

Additionally we should be publishing where the whois server for the
tld is in the DNS.  whois applications could be looking for this
then falling back to other methods.

e.g.

	_whois._tcp.pro. srv 0 100 43 whois.afilias.net.

If we want machines to follow referrals we have to provide them in
appropriate forms.

Mark

In message <56E0BFD4.7020403 at dougbarton.us>, Doug Barton writes:
> Joseph,
> 
> Thanks for the update. However the current state of things is not good 
> ... My Ubuntu host tries to use whois.dotproregistry.net, which has no 
> address records. FreeBSD by default uses pro.whois-servers.net, which 
> resolves to whois.registrypro.pro (which has an A record), but never 
> returns with any data (arguably worse than failing immediately with an 
> obvious error).
> 
> If it were me, I would have done the following:
> 
> 1. Reach out to the OS vendors and the folks at whois-servers.net with 
> information that the proper host name for your whois service is 
> changing. Include a drop-dead date of 3 years in the future for the old 
> names to stop working.
> 
> 2. Place a CNAME at the two (or more?) old host names so that the 
> service will continue to work in the meantime.
> 
> The CNAME costs you nothing, and while I agree that it should be able to 
> be removed at some point in the future, having things not work at all in 
> the short term is not the right approach.
> 
> It's also not realistic to expect folks to be able to chase this down on 
> their own ... anyone familiar with using whois on the command line has 
> most assuredly grown accustomed to the convenience of having it "just 
> work," as it has for the last decade or so. While people certainly *can* 
> go back to the "good old days" of having to hunt down each registry's 
> whois server individually, it's hard to think of that as the best approach.
> 
> Is there some reason that the above can't be/hasn't been done that I'm 
> missing?
> 
> Doug
> 
> 
> On 03/09/2016 02:17 PM, Joseph Yee wrote:
> > Hi Doug,
> >
> > Afilias had updated .PRO whois host in Jan 2016, and we filed the record
> > to ICANN & IANA (http://www.iana.org/domains/root/db/pro.html).
> >
> > The new host is 'whois.afilias.net <http://whois.afilias.net>' and not
> > 'whois.dotproregistry.net <http://whois.dotproregistry.net>' anymore.
> >
> > Some operating systems may not update their whois configuration yet.
> > You may need to check and update the configuration manually for PRO
> > WHOIS server before official patch were available.
> >
> > Best Regards,
> > Joseph Yee
> > Afilias
> >
> > On Wed, Mar 9, 2016 at 4:56 PM, Michael Flanagan <mflanagan at afilias.info
> > <mailto:mflanagan at afilias.info>> wrote:
> >
> >     -----Original Message-----
> >     From: Doug Barton [mailto:dougb at dougbarton.us
> >     <mailto:dougb at dougbarton.us>]
> >     Sent: Wednesday, March 09, 2016 4:54 PM
> >     To: tld-admin-poc at afilias.info <mailto:tld-admin-poc at afilias.info>;
> >     tld-tech-poc at afilias.info <mailto:tld-tech-poc at afilias.info>
> >     Subject: [tld-admin-poc] Fwd: Re: .pro whois registry down?
> >
> >     FYI
> >
> >     -------- Forwarded Message --------
> >     Subject: Re: .pro whois registry down?
> >     Date: Wed, 9 Mar 2016 13:51:28 -0800
> >     From: Doug Barton <dougb at dougbarton.us <mailto:dougb at dougbarton.us>>
> >     To: Bryan Holloway <bholloway at pavlovmedia.com
> >     <mailto:bholloway at pavlovmedia.com>>, NANOG list <nanog at nanog.org
> >     <mailto:nanog at nanog.org>>
> >
> >     On 03/09/2016 01:24 PM, Bryan Holloway wrote:
> >      > Anyone else noticing that the .pro TLD is failing for some
> >     things, and
> >      > their WHOIS registry appears to be unavailable?
> >
> >     The delegation from the root to PRO, and the PRO name servers
> >     themselves,
> >     seem to be working.
> >
> >      > I appear to be able to resolve, but whois times out, and we're
> >     getting
> >      > reports that mail isn't going through for some folks with this TLD.
> >
> >     The address records for whois.dotproregistry.net
> >     <http://whois.dotproregistry.net> are missing.
> >
> >     Doug
> >
> >
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

From royce at techsolvency.com  Thu Mar 10 01:20:24 2016
From: royce at techsolvency.com (Royce Williams)
Date: Wed, 9 Mar 2016 16:20:24 -0900
Subject: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?
In-Reply-To: <20160310005427.3E818442EC61@rock.dv.isc.org>
References: <56E09AE0.1030301@dougbarton.us> <56E09B83.7000306@dougbarton.us>
 <d9d005baf983b63af38fe03ba96a168a@mail.gmail.com>
 <CAF1dMVG9CD6vhm77X0qhX7VVjguJ9_nOS2Z1HNfB1Hqfx7p3Zg@mail.gmail.com>
 <56E0BFD4.7020403@dougbarton.us> <20160310005427.3E818442EC61@rock.dv.isc.org>
Message-ID: <CA+E3k935BY8_30Pvr1CCe5ErTpc+qZ5JaU7jJ-ZXvhXPpRkBAg@mail.gmail.com>

On Wed, Mar 9, 2016 at 3:54 PM, Mark Andrews <marka at isc.org> wrote:
>
> Additionally 'whois' is free form text.  Whois doesn't include a
> AI to workout what this free form text means so, no, there isn't a
> actual referral for a whois application to use.

I'm not affiliated, but there are a couple of companies that normalize
whois data.  It's a whackamole game, but it sucks less than trying to
do it yourself.

> Additionally we should be publishing where the whois server for the
> tld is in the DNS.  whois applications could be looking for this
> then falling back to other methods.
>
> e.g.
>
>         _whois._tcp.pro. srv 0 100 43 whois.afilias.net.
>
> If we want machines to follow referrals we have to provide them in
> appropriate forms.

That's a great idea.

Royce

From ops.lists at gmail.com  Thu Mar 10 01:53:21 2016
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Thu, 10 Mar 2016 07:23:21 +0530
Subject: [tld-admin-poc] Fwd: Re: .pro whois registry down?
In-Reply-To: <CA+E3k935BY8_30Pvr1CCe5ErTpc+qZ5JaU7jJ-ZXvhXPpRkBAg@mail.gmail.com>
References: <56E09AE0.1030301@dougbarton.us> <56E09B83.7000306@dougbarton.us>
 <d9d005baf983b63af38fe03ba96a168a@mail.gmail.com>
 <CAF1dMVG9CD6vhm77X0qhX7VVjguJ9_nOS2Z1HNfB1Hqfx7p3Zg@mail.gmail.com>
 <56E0BFD4.7020403@dougbarton.us>
 <20160310005427.3E818442EC61@rock.dv.isc.org>
 <CA+E3k935BY8_30Pvr1CCe5ErTpc+qZ5JaU7jJ-ZXvhXPpRkBAg@mail.gmail.com>
Message-ID: <C7F5A8E4-F843-433A-ABA2-53616A98B701@gmail.com>

Worst comes to worst there's a python based whois client called pwhois that lets you dump whois data into json 

--srs

> On 10-Mar-2016, at 6:50 AM, Royce Williams <royce at techsolvency.com> wrote:
> 
> I'm not affiliated, but there are a couple of companies that normalize
> whois data.  It's a whackamole game, but it sucks less than trying to
> do it yourself.

From dougb at dougbarton.us  Thu Mar 10 02:34:13 2016
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 9 Mar 2016 18:34:13 -0800
Subject: .pro whois registry down?
In-Reply-To: <20160310005427.3E818442EC61@rock.dv.isc.org>
References: <56E09AE0.1030301@dougbarton.us> <56E09B83.7000306@dougbarton.us>
 <d9d005baf983b63af38fe03ba96a168a@mail.gmail.com>
 <CAF1dMVG9CD6vhm77X0qhX7VVjguJ9_nOS2Z1HNfB1Hqfx7p3Zg@mail.gmail.com>
 <56E0BFD4.7020403@dougbarton.us>
 <20160310005427.3E818442EC61@rock.dv.isc.org>
Message-ID: <56E0DD25.7010408@dougbarton.us>

On 03/09/2016 04:54 PM, Mark Andrews wrote:
> Additionally we should be publishing where the whois server for the
> tld is in the DNS.  whois applications could be looking for this
> then falling back to other methods.
>
> e.g.
>
> 	_whois._tcp.pro. srv 0 100 43 whois.afilias.net.
>
> If we want machines to follow referrals we have to provide them in
> appropriate forms.

Brilliant, wish I'd thought of it :)

Doug


From Sam at SanDiegoBroadband.com  Thu Mar 10 03:53:16 2016
From: Sam at SanDiegoBroadband.com (Sam Norris)
Date: Wed, 9 Mar 2016 19:53:16 -0800
Subject: Facebook & Traceroute
Message-ID: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>

Why does Facebook spoof the source IP address of the hop before this server?
They spoof the source IP address that is performing the traceroute.

66.220.156.68

---
 7  FACEBOOK-IN.ear1.Atlanta2.Level3.net (4.16.185.58)  51.736 ms  51.678 ms
52.075 ms
 8  ae2.bb01.atl1.tfbnw.net (74.119.78.214)  51.636 ms  51.584 ms  51.720 ms
 9  be36.bb01.frc3.tfbnw.net (31.13.26.199)  58.669 ms ae4.bb05.frc3.tfbnw.net
(31.13.27.129)  61.085 ms ae16.bb06.frc3.tfbnw.net (74.119.76.117)  59.731 ms
10  ae5.bb04.iad3.tfbnw.net (31.13.26.57)  111.338 ms ae7.bb04.iad3.tfbnw.net
(31.13.31.245)  110.007 ms  110.015 ms
11  ae9.dr07.ash3.tfbnw.net (31.13.29.29)  68.692 ms ae10.dr08.ash2.tfbnw.net
(31.13.28.207)  67.846 ms ae12.dr08.ash3.tfbnw.net (31.13.29.191)  68.629 ms
12  * * *
13  * * *
14  8.25.38.1 (8.25.38.1)  68.571 ms  68.718 ms  68.132 ms
15  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  67.903 ms  67.752
ms  68.071 ms
---

Hop 14 is the source ip of the traceroute which is forged. This essentially
makes hop 14 reply using the same ip for src and dst.

Sam


From morrowc.lists at gmail.com  Thu Mar 10 04:13:08 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 9 Mar 2016 23:13:08 -0500
Subject: Facebook & Traceroute
In-Reply-To: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
References: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
Message-ID: <CAL9jLaZwVgxQ9A7AkEUF3UMi6LUBGdyb4P-rchTbuDN0BO7dpQ@mail.gmail.com>

On Wed, Mar 9, 2016 at 10:53 PM, Sam Norris <Sam at sandiegobroadband.com> wrote:
> Why does Facebook spoof the source IP address of the hop before this server?
> They spoof the source IP address that is performing the traceroute.
>
> 66.220.156.68
>
> ---
>  7  FACEBOOK-IN.ear1.Atlanta2.Level3.net (4.16.185.58)  51.736 ms  51.678 ms
> 52.075 ms
>  8  ae2.bb01.atl1.tfbnw.net (74.119.78.214)  51.636 ms  51.584 ms  51.720 ms
>  9  be36.bb01.frc3.tfbnw.net (31.13.26.199)  58.669 ms ae4.bb05.frc3.tfbnw.net
> (31.13.27.129)  61.085 ms ae16.bb06.frc3.tfbnw.net (74.119.76.117)  59.731 ms
> 10  ae5.bb04.iad3.tfbnw.net (31.13.26.57)  111.338 ms ae7.bb04.iad3.tfbnw.net
> (31.13.31.245)  110.007 ms  110.015 ms
> 11  ae9.dr07.ash3.tfbnw.net (31.13.29.29)  68.692 ms ae10.dr08.ash2.tfbnw.net
> (31.13.28.207)  67.846 ms ae12.dr08.ash3.tfbnw.net (31.13.29.191)  68.629 ms
> 12  * * *
> 13  * * *
> 14  8.25.38.1 (who)  68.571 ms  68.718 ms  68.132 ms
> 15  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  67.903 ms  67.752
> ms  68.071 ms
> ---
>
> Hop 14 is the source ip of the traceroute which is forged. This essentially
> makes hop 14 reply using the same ip for src and dst.

maybe their loadbalancer is a little wonky? (I don't see this in
traceroutes from a few places, but I also don't end up at IAD for
'www.facebook.com' traceroutes... here's my last 4 hops though to the
dest-ip you had:

.13.28.75)  0.597 ms ae0.dr08.ash2.tfbnw.net (31.13.26.235)  0.576 ms
 8  * * *
 9  * * *
10  * * *
11  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  0.774 ms
0.755 ms  0.701 ms

From lists.nanog at monmotha.net  Thu Mar 10 04:16:25 2016
From: lists.nanog at monmotha.net (Brandon Martin)
Date: Wed, 09 Mar 2016 23:16:25 -0500
Subject: Facebook & Traceroute
In-Reply-To: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
References: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
Message-ID: <56E0F519.6020607@monmotha.net>

On 03/09/2016 10:53 PM, Sam Norris wrote:
> Why does Facebook spoof the source IP address of the hop before this server?
> They spoof the source IP address that is performing the traceroute.
...
> (31.13.28.207)  67.846 ms ae12.dr08.ash3.tfbnw.net (31.13.29.191)  68.629 ms
> 12  * * *
> 13  * * *
> 14  8.25.38.1 (8.25.38.1)  68.571 ms  68.718 ms  68.132 ms
> 15  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  67.903 ms  67.752
> ms  68.071 ms
> ---
>
> Hop 14 is the source ip of the traceroute which is forged. This essentially
> makes hop 14 reply using the same ip for src and dst.

If intentional, I would speculate that this might be something to help 
their support staff by giving them confirmation of where the traceroute 
actually originated from in the public Internet view given that the 
originator might actually be behind possibly several layers of NAT.  The 
two missing hops could be a marker or perhaps other info that got eaten 
due to various source filters?

-- 
Brandon Martin

From Sam at SanDiegoBroadband.com  Thu Mar 10 04:22:01 2016
From: Sam at SanDiegoBroadband.com (Sam Norris)
Date: Wed, 9 Mar 2016 20:22:01 -0800
Subject: Facebook & Traceroute
In-Reply-To: <CAL9jLaZwVgxQ9A7AkEUF3UMi6LUBGdyb4P-rchTbuDN0BO7dpQ@mail.gmail.com>
References: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
 <CAL9jLaZwVgxQ9A7AkEUF3UMi6LUBGdyb4P-rchTbuDN0BO7dpQ@mail.gmail.com>
Message-ID: <095f01d17a84$66cb8260$34628720$@SanDiegoBroadband.com>

> maybe their loadbalancer is a little wonky? (I don't see this in
> traceroutes from a few places, but I also don't end up at IAD for
> 'www.facebook.com' traceroutes... here's my last 4 hops though to the
> dest-ip you had:
> 
> .13.28.75)  0.597 ms ae0.dr08.ash2.tfbnw.net (31.13.26.235)  0.576 ms
>  8  * * *
>  9  * * *
> 10  * * *
> 11  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  0.774 ms
> 0.755 ms  0.701 ms

This is probably because you are properly filtering your own prefixes from being sourced outside coming in?


From achatz at forthnet.gr  Thu Mar 10 06:23:30 2016
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 10 Mar 2016 08:23:30 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <20160310004407.GA6838@excession.tpb.net>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
Message-ID: <56E112E2.5090306@forthnet.gr>

Niels Bakker wrote on 10/3/16 02:44:
> * nanog at nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]:
>> I'm pretty confident there is no need for a specific MTU consensus and not all IXP participants are obligated to raise their interface MTU if the IXP starts allowing jumbo frames.
>
> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too Big messages.  That's why everybody must agree on one MTU.
>
>
Isn't that the case for IXP's current/default MTU?
If an IXP currently uses 1500, what effect will it have to its customers if it's increased to 9200 but not announced to them?

--
Tassos




From mark.tinka at seacom.mu  Thu Mar 10 06:29:52 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 10 Mar 2016 08:29:52 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E0A224.1050806@forthnet.gr>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
Message-ID: <5535906c-7219-f96a-bfc7-f0de6e19e25b@seacom.mu>



On 10/Mar/16 00:22, Tassos Chatzithomaoglou wrote:

> I must be missing something very obvious here, because i cannot think of any reason why an IXP shouldn't enable the maximum possible MTU on its infrastructure to be available to its customers. Then it's clearly customers' decision on what MTU to use on their devices, as long as:
>
>   * It fits inside IXP's MTU
>   * It suits with any other customer's (exchanging traffic with) MTU

This is a valid point.

Mark.

From saku at ytti.fi  Thu Mar 10 09:20:58 2016
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 10 Mar 2016 11:20:58 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <20160310004407.GA6838@excession.tpb.net>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
Message-ID: <CAAeewD-7qQ28AxoSXnGEwP8xkXoUbBCNvvDZQppL1PviCKS5aQ@mail.gmail.com>

On 10 March 2016 at 02:44, Niels Bakker <niels=nanog at bakker.net> wrote:
> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too Big
> messages.  That's why everybody must agree on one MTU.

I think what was meant, no global consensus is needed, each IXP can
decide themselves what is edgeMTU and coreMTU VLAN MTU sizes in /this/
IXP. Heck, have customers vote on webpage. I guess edgeMTU obviously
will be 1500, coreMTU something else, 4470, 9000 and 9100 seem like
reasonable suspects. And to me it really isn't super important what it
is, as long as it allows tunneling overhead over edgeMTU. I would use
use the coreMTU in any IXP offering it, regardless what the exact MTU
in that IXP is.

-- 
  ++ytti

From dot at dotat.at  Thu Mar 10 11:28:08 2016
From: dot at dotat.at (Tony Finch)
Date: Thu, 10 Mar 2016 11:28:08 +0000
Subject: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?
In-Reply-To: <20160310005427.3E818442EC61@rock.dv.isc.org>
References: <56E09AE0.1030301@dougbarton.us> <56E09B83.7000306@dougbarton.us>
 <d9d005baf983b63af38fe03ba96a168a@mail.gmail.com>
 <CAF1dMVG9CD6vhm77X0qhX7VVjguJ9_nOS2Z1HNfB1Hqfx7p3Zg@mail.gmail.com>
 <56E0BFD4.7020403@dougbarton.us>
 <20160310005427.3E818442EC61@rock.dv.isc.org>
Message-ID: <alpine.LSU.2.00.1603101123440.11434@hermes-2.csi.cam.ac.uk>

Mark Andrews <marka at isc.org> wrote:
>
> Additionally 'whois' is free form text.  Whois doesn't include a
> AI to workout what this free form text means so, no, there isn't a
> actual referral for a whois application to use.

Yes, the whois data format is bullshit, but there are only a few simple
referral patterns in use, so in practice following referrals works OK.

> Additionally we should be publishing where the whois server for the
> tld is in the DNS.

> 	_whois._tcp.pro. srv 0 100 43 whois.afilias.net.

That would be nice, but in practice the requirement is a whois.nic.TLD
host rather than a SRV record. And we don't really need yet another way
to find whois servers - we already have more than enough.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Humber, Thames: East or southeast 3 or 4. Slight. Mainly fair. Moderate or
good.

From nanog at ics-il.net  Thu Mar 10 13:24:15 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Thu, 10 Mar 2016 07:24:15 -0600 (CST)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E07DAE.5040008@foobar.org>
Message-ID: <749494599.4226.1457616252024.JavaMail.mhammett@ThunderFuck>

Until you've ran an IXP, you have no idea how finicky or clueless some network operators are. 




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



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


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

From: "Nick Hilliard" <nick at foobar.org> 
To: "Saku Ytti" <saku at ytti.fi> 
Cc: "NANOG list" <nanog at nanog.org> 
Sent: Wednesday, March 9, 2016 1:46:54 PM 
Subject: Re: Internet Exchanges supporting jumbo frames? 

Saku Ytti wrote: 
> If customer does not react, put it on quarantine VLAN. This can be 
> automated too. Wrong MTU => open internal case, contact customers 
> email, no customer response in N days, quarantine VLAN. 

... and then the customer will leave the service down because it the 
primary peering lan works fine and they couldn't be bothered fixing 
jumbo lan connectivity because the neteng who wanted the 9000 byte mtu 
connectivity in the first place got distracted by a squirrel or left the 
company or was too busy doing other things. 

> work, but it's very difficult to actually know without trying what 
> works and what does. 

I've spent a good deal of time and effort trying to get a jumbo peering 
vlan to work and it didn't work for the reasons that I've mentioned, and 
others. 

For example, many types of hardware don't allow you to specify a 
different MTU for different .1q tags on the same physical interface. 
This means that if you want a connection to a jumbo MTU vlan and a 
standard mtu vlan, you needed two separate connections into the IXP. At 
that point, the ixp participant is unlikely to want to bother because 
there's no cost:value justification in getting the second connection. 

Don't get me wrong: jumbo MTU IXPs are a great idea in theory. In 
practice, they cause an inordinate amount of pain. 

Nick 


From johnl at iecc.com  Thu Mar 10 13:32:21 2016
From: johnl at iecc.com (John Levine)
Date: 10 Mar 2016 13:32:21 -0000
Subject: finding whois servers, was .pro whois registry down?
In-Reply-To: <20160310005427.3E818442EC61@rock.dv.isc.org>
Message-ID: <20160310133221.5849.qmail@ary.lan>

>	_whois._tcp.pro. srv 0 100 43 whois.afilias.net.

A swell idea, but unfortunately the idea of putting SRV records in
gTLD zones makes heads at ICANN explode.  For RDAP there's a registry
at IANA but it's not populated yet and it's not obvious that registries
will be any more diligent about updating it than they are for the WHOIS
entries in the TLD database.

>If we want machines to follow referrals we have to provide them in
>appropriate forms.

<domain.whois-servers.net is OK but not updated very often.

I've set up <domain>.ws.sp.am (that's ws for Whois Server) which is
updated every day from a variety of sources so it's pretty accurate.
It's had the right server for pro.ws.sp.am all along.

R's,
John

From achatz at forthnet.gr  Thu Mar 10 14:43:47 2016
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 10 Mar 2016 16:43:47 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <20160310151555.65178a3d@pels-Latitude-E5450>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net> <56E112E2.5090306@forthnet.gr>
 <20160310151555.65178a3d@pels-Latitude-E5450>
Message-ID: <56E18823.9070702@forthnet.gr>



Martin Pels wrote on 10/3/2016 4:15 ??:
> On Thu, 10 Mar 2016 08:23:30 +0200
> Tassos Chatzithomaoglou <achatz at forthnet.gr> wrote:
>
>> Niels Bakker wrote on 10/3/16 02:44:
>>> * nanog at nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59
>>> CET]:
>>>> I'm pretty confident there is no need for a specific MTU consensus
>>>> and not all IXP participants are obligated to raise their
>>>> interface MTU if the IXP starts allowing jumbo frames.
>>> You're wrong here.  The IXP switch platform cannot send ICMP Packet
>>> Too Big messages.  That's why everybody must agree on one MTU.
>>>
>>>
>> Isn't that the case for IXP's current/default MTU?
>> If an IXP currently uses 1500, what effect will it have to its
>> customers if it's increased to 9200 but not announced to them?
> None. Until someone actually tries to make use of the higher MTU. Then
> things start breaking.
>

I can understand the above issue. But as i said that's customer's decision.
Exactly the same will happen if the customer increases its mtu now.
> In order for Jumboframes to be successful on IXPs _on a large scale_
> the technology has to change. There needs to be a mechanism to negotiate
> MTU for each L2 neighbor individually. Something like
> draft-van-beijnum-multi-mtu-03, which was mentioned before in this
> thread. With this in place individual sets of peers could safely use
> different MTUs on the same VLAN, and IXPs would have a migration path
> towards supporting larger framesizes.

Agreed. But that doesn't forbid the IXPs to use the max MTU now.


--
Tassos

From jmaslak at antelope.net  Thu Mar 10 14:58:29 2016
From: jmaslak at antelope.net (Joel Maslak)
Date: Thu, 10 Mar 2016 07:58:29 -0700
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <0eedf5e0-2551-9073-5c43-3376ccd2f15d@bogus.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <alpine.DEB.2.02.1603091651460.31096@uplift.swm.pp.se>
 <0eedf5e0-2551-9073-5c43-3376ccd2f15d@bogus.com>
Message-ID: <CADb+6TAqqYc2yLUGV7n4Qiioq8qasriNsBtCRNNvB2K1A-t1rw@mail.gmail.com>

On Wed, Mar 9, 2016 at 9:27 AM, joel jaeggli <joelja at bogus.com> wrote:

> PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in
> > my opinion (although it's strange how many hosts that seem to get away
> > with 1492 (or is it 1496) MTU because they're using PPPoE).
>
> if your adv_mss is set accordingly you can get away with
>  a lot.
>

At least for TCP.  EDNS with sizes > 14xx bytes just plain doesn't
universally work across the internet, yet it's the default everywhere.

From dmburgess at linktechs.net  Thu Mar 10 15:09:15 2016
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Thu, 10 Mar 2016 15:09:15 +0000
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
Message-ID: <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>

Not wishing to get into a pissing war with who is right or wrong, but it sounds like google already pays or has an agreement with cogent for v4, as that's unaffected, cogent says google is simply not advertising v6 prefixes to them, so, how is that cogent's fault?


-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org] 
Sent: Wednesday, March 9, 2016 11:26 AM
To: J?rgen Jaritsch <JJaritsch at anexia-it.com>
Cc: Dennis Burgess <dmburgess at linktechs.net>; North American Network Operators' Group <nanog at nanog.org>
Subject: Re: AW: Cogent - Google - HE Fun

In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm not surprised.  I suggested it during talks with GOOG roughly 10 years ago...not saying I had any influence...I'm pretty sure I did not. :)

GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them or someone else to get to Cogent).  If you're well peered / multihomed, it's not much of an issue.  If you're a single-homed Cogent customer, you should complain to Cogent that they're not providing full
IPv6 connectivity.

On Wed, 9 Mar 2016, J?rgen Jaritsch wrote:

> Hi,
>
> mail from Cogent:
>>>>>
> Dear Cogent Customer,
>
> Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach.
>
> Google uses transit providers to announce their IPv4 routes to Cogent.
>
> At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers.
>
> We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation.
> <<<<
>
> Mail from Google:
>>>>>
> Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us.
>
> Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers.
>
> For more information in how to peer directly with Google please visit 
> https://peering.google.com <<<<
>
> best regards
>
> J?rgen Jaritsch
> Head of Network & Infrastructure
>
> ANEXIA Internetdienstleistungs GmbH
>
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
>
> E-Mail: JJaritsch at anexia-it.com
> Web: http://www.anexia-it.com
>
>
>
> 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+jjaritsch=anexia-it.com at nanog.org] Im 
> Auftrag von Dennis Burgess
> Gesendet: Mittwoch, 09. M?rz 2016 17:01
> An: North American Network Operators' Group
> Betreff: Cogent - Google - HE Fun
>
> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent?   If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else?
>
> [DennisBurgessSignature]
> www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - 
> dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>
>
>

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

From jlewis at lewis.org  Thu Mar 10 15:25:25 2016
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 10 Mar 2016 10:25:25 -0500 (EST)
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
Message-ID: <Pine.LNX.4.61.1603101016110.6833@soloth.lewis.org>

My guess is that GOOG is playing peering chicken with Cogent on "the IPv6 
Internet" because doing so is low impact.  Doing this with v4 routing 
would be far more painful to both GOOG and single-homed Cogent customers 
(probably make the news and make one or both look bad).  Doing this with 
v6 keeps it off in the shadows...both parties know its an issue, but its 
likely not seriously impacting anyone yet.  GOOG likely thinks they're big 
enough and their content desirable enough, that Cogent should peer with 
them.  Cogent clearly disagrees.  I'm sure GOOG would prefer SFI with 
Cogent for v4 and v6...but they're working on getting v6 first.

On Thu, 10 Mar 2016, Dennis Burgess wrote:

> Not wishing to get into a pissing war with who is right or wrong, but it sounds like google already pays or has an agreement with cogent for v4, as that's unaffected, cogent says google is simply not advertising v6 prefixes to them, so, how is that cogent's fault?
>
>
> -----Original Message-----
> From: Jon Lewis [mailto:jlewis at lewis.org]
> Sent: Wednesday, March 9, 2016 11:26 AM
> To: J?rgen Jaritsch <JJaritsch at anexia-it.com>
> Cc: Dennis Burgess <dmburgess at linktechs.net>; North American Network Operators' Group <nanog at nanog.org>
> Subject: Re: AW: Cogent - Google - HE Fun
>
> In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm not surprised.  I suggested it during talks with GOOG roughly 10 years ago...not saying I had any influence...I'm pretty sure I did not. :)
>
> GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them or someone else to get to Cogent).  If you're well peered / multihomed, it's not much of an issue.  If you're a single-homed Cogent customer, you should complain to Cogent that they're not providing full
> IPv6 connectivity.
>
> On Wed, 9 Mar 2016, J?rgen Jaritsch wrote:
>
>> Hi,
>>
>> mail from Cogent:
>>>>>>
>> Dear Cogent Customer,
>>
>> Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach.
>>
>> Google uses transit providers to announce their IPv4 routes to Cogent.
>>
>> At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers.
>>
>> We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation.
>> <<<<
>>
>> Mail from Google:
>>>>>>
>> Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us.
>>
>> Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers.
>>
>> For more information in how to peer directly with Google please visit
>> https://peering.google.com <<<<
>>
>> best regards
>>
>> J?rgen Jaritsch
>> Head of Network & Infrastructure
>>
>> ANEXIA Internetdienstleistungs GmbH
>>
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>>
>> E-Mail: JJaritsch at anexia-it.com
>> Web: http://www.anexia-it.com
>>
>>
>>
>> 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+jjaritsch=anexia-it.com at nanog.org] Im
>> Auftrag von Dennis Burgess
>> Gesendet: Mittwoch, 09. M?rz 2016 17:01
>> An: North American Network Operators' Group
>> Betreff: Cogent - Google - HE Fun
>>
>> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent?   If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else?
>>
>> [DennisBurgessSignature]
>> www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 -
>> dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>
>>
>>
>
> ----------------------------------------------------------------------
>  Jon Lewis, MCP :)           |  I route
>                              |  therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>

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

From morrowc.lists at gmail.com  Thu Mar 10 15:32:25 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 10 Mar 2016 10:32:25 -0500
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
Message-ID: <CAL9jLaZj7mFQtHwXtKxeyhvijEWDPuN8nKg1T6kJLoXBMUAvRA@mail.gmail.com>

On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess
<dmburgess at linktechs.net> wrote:
> Not wishing to get into a pissing war with who is right or wrong, but it sounds like google already pays or has an agreement with cogent for v4, as that's unaffected, cogent says google is simply not advertising v6 prefixes to them, so, how is that cogent's fault?
>

Did you check that on Cogent's LookingGlass?

"BGP routing table entry for 216.239.32.0/24, version 3740382954
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  6453 15169
    154.54.13.206 (metric 10102020) from 154.54.66.21 (154.54.66.21)
      Origin IGP, metric 4294967294, localpref 100, valid, internal, best
      Community: 174:10031 174:20666 174:21000 174:22013
      Originator: 66.28.1.9, Cluster list: 154.54.66.21"

is a lookup on: http://www.cogentco.com/en/network/looking-glass

if 216.239.32.0 - which holds ns1.google.com... I'd expect that
ns1.google.com would be routed via the majority of links 15169 has
with the world.

>
> -----Original Message-----
> From: Jon Lewis [mailto:jlewis at lewis.org]
> Sent: Wednesday, March 9, 2016 11:26 AM
> To: J?rgen Jaritsch <JJaritsch at anexia-it.com>
> Cc: Dennis Burgess <dmburgess at linktechs.net>; North American Network Operators' Group <nanog at nanog.org>
> Subject: Re: AW: Cogent - Google - HE Fun
>
> In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm not surprised.  I suggested it during talks with GOOG roughly 10 years ago...not saying I had any influence...I'm pretty sure I did not. :)
>
> GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them or someone else to get to Cogent).  If you're well peered / multihomed, it's not much of an issue.  If you're a single-homed Cogent customer, you should complain to Cogent that they're not providing full
> IPv6 connectivity.
>
> On Wed, 9 Mar 2016, J?rgen Jaritsch wrote:
>
>> Hi,
>>
>> mail from Cogent:
>>>>>>
>> Dear Cogent Customer,
>>
>> Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach.
>>
>> Google uses transit providers to announce their IPv4 routes to Cogent.
>>
>> At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers.
>>
>> We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation.
>> <<<<
>>
>> Mail from Google:
>>>>>>
>> Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us.
>>
>> Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers.
>>
>> For more information in how to peer directly with Google please visit
>> https://peering.google.com <<<<
>>
>> best regards
>>
>> J?rgen Jaritsch
>> Head of Network & Infrastructure
>>
>> ANEXIA Internetdienstleistungs GmbH
>>
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>>
>> E-Mail: JJaritsch at anexia-it.com
>> Web: http://www.anexia-it.com
>>
>>
>>
>> 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+jjaritsch=anexia-it.com at nanog.org] Im
>> Auftrag von Dennis Burgess
>> Gesendet: Mittwoch, 09. M?rz 2016 17:01
>> An: North American Network Operators' Group
>> Betreff: Cogent - Google - HE Fun
>>
>> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent?   If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else?
>>
>> [DennisBurgessSignature]
>> www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 -
>> dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>
>>
>>
>
> ----------------------------------------------------------------------
>   Jon Lewis, MCP :)           |  I route
>                               |  therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From morrowc.lists at gmail.com  Thu Mar 10 15:35:15 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 10 Mar 2016 10:35:15 -0500
Subject: Facebook & Traceroute
In-Reply-To: <095f01d17a84$66cb8260$34628720$@SanDiegoBroadband.com>
References: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
 <CAL9jLaZwVgxQ9A7AkEUF3UMi6LUBGdyb4P-rchTbuDN0BO7dpQ@mail.gmail.com>
 <095f01d17a84$66cb8260$34628720$@SanDiegoBroadband.com>
Message-ID: <CAL9jLaZZhuu-VA_1Pph4rFrj7xE9RSg_cZ0B1sfEt-frCzZCEA@mail.gmail.com>

On Wed, Mar 9, 2016 at 11:22 PM, Sam Norris <Sam at sandiegobroadband.com> wrote:
>> maybe their loadbalancer is a little wonky? (I don't see this in
>> traceroutes from a few places, but I also don't end up at IAD for
>> 'www.facebook.com' traceroutes... here's my last 4 hops though to the
>> dest-ip you had:
>>
>> .13.28.75)  0.597 ms ae0.dr08.ash2.tfbnw.net (31.13.26.235)  0.576 ms
>>  8  * * *
>>  9  * * *
>> 10  * * *
>> 11  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  0.774 ms
>> 0.755 ms  0.701 ms
>
> This is probably because you are properly filtering your own prefixes from being sourced outside coming in?
>

unclear, that traceroute was from someplace I don't own the network for...
from another place I do though...

 5  ae0.dr07.ash2.tfbnw.net (31.13.26.233)  4 ms
ae0.dr05.ash3.tfbnw.net (31.13.29.21)  4 ms ae0.dr08.ash2.tfbnw.net
(31.13.26.235)  2 ms
 6  * * *
 7  * * *
 8  * * *
 9  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  3 ms  3 ms  2 ms

same-ish results, no spoofed bits.

From royce at techsolvency.com  Thu Mar 10 15:35:20 2016
From: royce at techsolvency.com (Royce Williams)
Date: Thu, 10 Mar 2016 06:35:20 -0900
Subject: finding whois servers, was .pro whois registry down?
In-Reply-To: <20160310133221.5849.qmail@ary.lan>
References: <20160310005427.3E818442EC61@rock.dv.isc.org>
 <20160310133221.5849.qmail@ary.lan>
Message-ID: <CA+E3k909rwH5EEMK07DESSaOKOAORg2yqbi5oH5tAgqS1_jpWQ@mail.gmail.com>

On Thu, Mar 10, 2016 at 4:32 AM, John Levine <johnl at iecc.com> wrote:

> >       _whois._tcp.pro. srv 0 100 43 whois.afilias.net.
>
> A swell idea, but unfortunately the idea of putting SRV records in
> gTLD zones makes heads at ICANN explode.  For RDAP there's a registry
> at IANA but it's not populated yet and it's not obvious that registries
> will be any more diligent about updating it than they are for the WHOIS
> entries in the TLD database.
>
> >If we want machines to follow referrals we have to provide them in
> >appropriate forms.
>
> <domain.whois-servers.net is OK but not updated very often.
>
> I've set up <domain>.ws.sp.am (that's ws for Whois Server) which is
> updated every day from a variety of sources so it's pretty accurate.
> It's had the right server for pro.ws.sp.am all along.
>

Hey, that's fantastic!

Feature request: could you provide a human- and machine-readable one-stop
extract at the top-level page (ws.sp.am) ?

Royce

From owen at delong.com  Thu Mar 10 15:51:42 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 10 Mar 2016 07:51:42 -0800
Subject: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
Message-ID: <BC7F2770-5439-47A7-AD2F-99A7FD0A81BF@delong.com>

I think it?s a little different from what you say?

I think Google already reaches Cogent for IPv4 via transit.

Google, long ago, announced that they would not be purchasing IPv6 transit and that they have an open peering policy for anyone who wishes to reach them. In order to avoid significant disruption, they haven?t terminated their IPv4 transit contracts, but it certainly makes sense that they would not be pursuing IPv6 transit contracts.

The situation with Hurricane Electric is somewhat similar.

Google and HE are two of the most significant IPv6 networks out there. In the IPv6 world, Cogent is basically an also-ran so far.

The peering dynamics are different in IPv4 and IPv6 because the adoption rates and deployments in various networks have been different.

Cogent is sticking their head in the sand and pretending that their IPv4 peering status should carry over into IPv6 automatically.

One of two things will eventually happen?

Either Cogent will win this game of chicken and the IPv6 networks that are not paying to reach them by transit now will start paying to do so, or, Cogent will lose this game of chicken and become progressively less relevant in the IPv6 internet.

Personally, my bet is on the latter. For historical precedent, I refer you to SPRINT (AS1239).

Owen

> On Mar 10, 2016, at 07:09 , Dennis Burgess <dmburgess at linktechs.net> wrote:
> 
> Not wishing to get into a pissing war with who is right or wrong, but it sounds like google already pays or has an agreement with cogent for v4, as that's unaffected, cogent says google is simply not advertising v6 prefixes to them, so, how is that cogent's fault?
> 
> 
> -----Original Message-----
> From: Jon Lewis [mailto:jlewis at lewis.org] 
> Sent: Wednesday, March 9, 2016 11:26 AM
> To: J?rgen Jaritsch <JJaritsch at anexia-it.com>
> Cc: Dennis Burgess <dmburgess at linktechs.net>; North American Network Operators' Group <nanog at nanog.org>
> Subject: Re: AW: Cogent - Google - HE Fun
> 
> In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm not surprised.  I suggested it during talks with GOOG roughly 10 years ago...not saying I had any influence...I'm pretty sure I did not. :)
> 
> GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them or someone else to get to Cogent).  If you're well peered / multihomed, it's not much of an issue.  If you're a single-homed Cogent customer, you should complain to Cogent that they're not providing full
> IPv6 connectivity.
> 
> On Wed, 9 Mar 2016, J?rgen Jaritsch wrote:
> 
>> Hi,
>> 
>> mail from Cogent:
>>>>>> 
>> Dear Cogent Customer,
>> 
>> Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach.
>> 
>> Google uses transit providers to announce their IPv4 routes to Cogent.
>> 
>> At this time however, Google has chosen not to announce their IPv6 routes to Cogent through transit providers.
>> 
>> We apologize for any inconvenience this may cause you and will notify you if there is an update to the situation.
>> <<<<
>> 
>> Mail from Google:
>>>>>> 
>> Unfortunately it seems that your transit provider does not have IPv6 connectivity with Google. We suggest you ask your transit provider to look for alternatives to interconnect with us.
>> 
>> Google maintains an open interconnect policy for IPv6 and welcomes any network to peer with us for access via IPv6 (and IPv4). For those networks that aren't able, or chose not to peer with Google via IPv6, they are able to reach us through any of a large number of transit providers.
>> 
>> For more information in how to peer directly with Google please visit 
>> https://peering.google.com <<<<
>> 
>> best regards
>> 
>> J?rgen Jaritsch
>> Head of Network & Infrastructure
>> 
>> ANEXIA Internetdienstleistungs GmbH
>> 
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>> 
>> E-Mail: JJaritsch at anexia-it.com
>> Web: http://www.anexia-it.com
>> 
>> 
>> 
>> 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+jjaritsch=anexia-it.com at nanog.org] Im 
>> Auftrag von Dennis Burgess
>> Gesendet: Mittwoch, 09. M?rz 2016 17:01
>> An: North American Network Operators' Group
>> Betreff: Cogent - Google - HE Fun
>> 
>> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent?   If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else?
>> 
>> [DennisBurgessSignature]
>> www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - 
>> dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>
>> 
>> 
> 
> ----------------------------------------------------------------------
>  Jon Lewis, MCP :)           |  I route
>                              |  therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From bill at herrin.us  Thu Mar 10 15:55:30 2016
From: bill at herrin.us (William Herrin)
Date: Thu, 10 Mar 2016 10:55:30 -0500
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
Message-ID: <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>

On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess
<dmburgess at linktechs.net> wrote:
> Not wishing to get into a pissing war with who is right or wrong, but it sounds like
> google already pays or has an agreement with cogent for v4, as that's unaffected,
> cogent says google is simply not advertising v6 prefixes to them, so, how is
> that cogent's fault?

Hi Dennis,

It's Cogent's fault because: double-billing. Google should not have to
pay Cogent for a service which you have already paid Cogent to provide
to you. Cogent's demand is unethical. They intentionally fail to
deliver on the basic service expectation you pay them for and refuse
to do so unless a third party to your contract also pays them.

Google, by contrast, makes no demand that Cogent pay them even though
you are not paying Google for service. They offer "open peering," a
free interconnect via many neutral data centers.

If you're not single-homed to Cogent and you have the balls for it, I
would file an outage with Cogent and demand service credit until they
resolve their IPv6 access problem with Google. And then refuse to pay
until they connect with Google.

If you are single-homed to Cogent, it's *very* important that you do
something about that before you get burned in a way that matters.

Regards,
Bill Herrin



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

From johnl at iecc.com  Thu Mar 10 15:57:32 2016
From: johnl at iecc.com (John R. Levine)
Date: 10 Mar 2016 16:57:32 +0100
Subject: finding whois servers, was .pro whois registry down?
In-Reply-To: <CA+E3k909rwH5EEMK07DESSaOKOAORg2yqbi5oH5tAgqS1_jpWQ@mail.gmail.com>
References: <20160310005427.3E818442EC61@rock.dv.isc.org>
 <20160310133221.5849.qmail@ary.lan>
 <CA+E3k909rwH5EEMK07DESSaOKOAORg2yqbi5oH5tAgqS1_jpWQ@mail.gmail.com>
Message-ID: <alpine.OSX.2.11.1603101656370.8733@ary.local>

>> I've set up <domain>.ws.sp.am (that's ws for Whois Server) which is
>> updated every day from a variety of sources so it's pretty accurate.
>> It's had the right server for pro.ws.sp.am all along.

> Hey, that's fantastic!
>
> Feature request: could you provide a human- and machine-readable one-stop
> extract at the top-level page (ws.sp.am) ?

I can make a web page, but not sure what you mean by one-stop extract.  If 
you mean a proxy that will do the whois lookups, no, because it'd get 
abused and I'd get rate limited.

R's,
John

From josh at kyneticwifi.com  Thu Mar 10 16:07:30 2016
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Thu, 10 Mar 2016 10:07:30 -0600
Subject: anyone from google email / net ops here?
Message-ID: <CAC6=tfYET4N7W6dra8VoJq23Hg4b6RWgc+mE_Hs7FL9NM8iQAg@mail.gmail.com>

It seems like one of your email servers is on SORBS which is causing
any email outbound from said server to be blocked by those using
SORBS.

IP in question is 209.85.214.170

Offlist responses are fine, thanks

From royce at techsolvency.com  Thu Mar 10 16:07:18 2016
From: royce at techsolvency.com (Royce Williams)
Date: Thu, 10 Mar 2016 07:07:18 -0900
Subject: finding whois servers, was .pro whois registry down?
In-Reply-To: <alpine.OSX.2.11.1603101656370.8733@ary.local>
References: <20160310005427.3E818442EC61@rock.dv.isc.org>
 <20160310133221.5849.qmail@ary.lan>
 <CA+E3k909rwH5EEMK07DESSaOKOAORg2yqbi5oH5tAgqS1_jpWQ@mail.gmail.com>
 <alpine.OSX.2.11.1603101656370.8733@ary.local>
Message-ID: <CA+E3k90uXA4c5LeD5T4ekh-R-YWksgf6yb0saCbe7e7rGv4B=w@mail.gmail.com>

On Thu, Mar 10, 2016 at 6:57 AM, John R. Levine <johnl at iecc.com> wrote:
>>>
>>> I've set up <domain>.ws.sp.am (that's ws for Whois Server) which is
>>> updated every day from a variety of sources so it's pretty accurate.
>>> It's had the right server for pro.ws.sp.am all along.
>
>
>> Hey, that's fantastic!
>>
>> Feature request: could you provide a human- and machine-readable one-stop
>> extract at the top-level page (ws.sp.am) ?
>
>
> I can make a web page, but not sure what you mean by one-stop extract.  If you mean a proxy that will do the whois lookups, no, because it'd get abused and I'd get rate limited.

Definitely not a proxy request - I know exactly what that would mean.

The goal would be to provide a unified list of the servers for each
TLD, to help people who cannot change their whois client for
administrative/political/inertia reasons, but have control over their
whois.conf, a la:

https://superuser.com/questions/758647/how-to-whois-new-tlds

So in an ideal world:

- a top-level landing page that would explain briefly what it's for, and

- a link from that top-level page to the whole list, in regex-aware,
whois.conf-compatible format

Royce

From johnl at iecc.com  Thu Mar 10 16:11:53 2016
From: johnl at iecc.com (John R. Levine)
Date: 10 Mar 2016 17:11:53 +0100
Subject: finding whois servers, was .pro whois registry down?
In-Reply-To: <CA+E3k90uXA4c5LeD5T4ekh-R-YWksgf6yb0saCbe7e7rGv4B=w@mail.gmail.com>
References: <20160310005427.3E818442EC61@rock.dv.isc.org>
 <20160310133221.5849.qmail@ary.lan>
 <CA+E3k909rwH5EEMK07DESSaOKOAORg2yqbi5oH5tAgqS1_jpWQ@mail.gmail.com>
 <alpine.OSX.2.11.1603101656370.8733@ary.local>
 <CA+E3k90uXA4c5LeD5T4ekh-R-YWksgf6yb0saCbe7e7rGv4B=w@mail.gmail.com>
Message-ID: <alpine.OSX.2.11.1603101710100.8743@ary.local>

> - a link from that top-level page to the whole list, in regex-aware,
> whois.conf-compatible format

What uses whois.conf?   Not the whois on my FreeBSD or Mac.

Or you can just use this shell script:

  #!/bin/bash
  WHOISHOST=${1##*.}.ws.sp.am
  exec whois -h $WHOISHOST $*

R's,
John


From owen at delong.com  Thu Mar 10 16:14:43 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 10 Mar 2016 08:14:43 -0800
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
Message-ID: <55AD7CF5-4935-4710-835B-BE3F9E370E4C@delong.com>


> On Mar 10, 2016, at 07:55 , William Herrin <bill at herrin.us> wrote:
> 
> On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess
> <dmburgess at linktechs.net> wrote:
>> Not wishing to get into a pissing war with who is right or wrong, but it sounds like
>> google already pays or has an agreement with cogent for v4, as that's unaffected,
>> cogent says google is simply not advertising v6 prefixes to them, so, how is
>> that cogent's fault?
> 
> Hi Dennis,
> 
> It's Cogent's fault because: double-billing. Google should not have to
> pay Cogent for a service which you have already paid Cogent to provide
> to you. Cogent's demand is unethical. They intentionally fail to
> deliver on the basic service expectation you pay them for and refuse
> to do so unless a third party to your contract also pays them.
> 
> Google, by contrast, makes no demand that Cogent pay them even though
> you are not paying Google for service. They offer "open peering," a
> free interconnect via many neutral data centers.

In fairness, however, this is because he is not Google?s customer, he
is Google?s product. Google is selling him (well, information about him
anyway) to their customers. They gather this information by offering
certain things he wants in exchange for him allowing them to collect
and redistribute this data.

Everything you say above is true, but let?s be clear where the customer
vs. product relationships truly are.

Owen



From raymond at prolocation.net  Thu Mar 10 16:18:21 2016
From: raymond at prolocation.net (Raymond Dijkxhoorn)
Date: Thu, 10 Mar 2016 17:18:21 +0100 (CET)
Subject: finding whois servers, was .pro whois registry down?
In-Reply-To: <alpine.OSX.2.11.1603101710100.8743@ary.local>
References: <20160310005427.3E818442EC61@rock.dv.isc.org>
 <20160310133221.5849.qmail@ary.lan>
 <CA+E3k909rwH5EEMK07DESSaOKOAORg2yqbi5oH5tAgqS1_jpWQ@mail.gmail.com>
 <alpine.OSX.2.11.1603101656370.8733@ary.local>
 <CA+E3k90uXA4c5LeD5T4ekh-R-YWksgf6yb0saCbe7e7rGv4B=w@mail.gmail.com>
 <alpine.OSX.2.11.1603101710100.8743@ary.local>
Message-ID: <alpine.LFD.2.00.1603101717510.11065@noc.prolocation.net>

Hai!

>> whois.conf-compatible format

> What uses whois.conf?   Not the whois on my FreeBSD or Mac.
>
> Or you can just use this shell script:
>
> #!/bin/bash
> WHOISHOST=${1##*.}.ws.sp.am
> exec whois -h $WHOISHOST $*

I just a slightly different one but still my fav one... jwhois

Has a whois.conf style list.

Bye,
Raymond.

From dot at dotat.at  Thu Mar 10 16:20:02 2016
From: dot at dotat.at (Tony Finch)
Date: Thu, 10 Mar 2016 16:20:02 +0000
Subject: finding whois servers, was .pro whois registry down?
In-Reply-To: <20160310133221.5849.qmail@ary.lan>
References: <20160310133221.5849.qmail@ary.lan>
Message-ID: <alpine.LSU.2.00.1603101613460.11434@hermes-2.csi.cam.ac.uk>

John Levine <johnl at iecc.com> wrote:
>
> I've set up <domain>.ws.sp.am (that's ws for Whois Server) which is
> updated every day from a variety of sources so it's pretty accurate.
> It's had the right server for pro.ws.sp.am all along.

It would be extra super helpful if every entry were a wildcard, so you
could look up (say) example.com.ws.sp.am and get a CNAME for the right
whois server. The reason for this is that the relevant whois server is not
always keyed off just the TLD, and sometimes the TLD doesn't provide a
referral. A particular case I know of is ac.uk vs. uk. You could have

*.uk.ws.sp.am.    CNAME whois.nic.uk.
*.ac.uk.ws.sp.am. CNAME whois.ja.net.

Then I could look up cambridge.ac.uk.ws.sp.am and
cambridge.net.uk.ws.sp.am and get the right pointer in each case with a
single DNS lookup.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Southeast Fitzroy: Northerly 5 or 6, becoming variable 4 in north and west.
Rough becoming moderate later. Mainly fair. Good.

From swmike at swm.pp.se  Thu Mar 10 16:21:25 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 10 Mar 2016 17:21:25 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <20160310004407.GA6838@excession.tpb.net>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
Message-ID: <alpine.DEB.2.02.1603101719120.31096@uplift.swm.pp.se>

On Thu, 10 Mar 2016, Niels Bakker wrote:

> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too 
> Big messages.  That's why everybody must agree on one MTU.

"Someone" should do an inventory of the market to find out how many 
commonly used platforms limit MRU to less than 9180 (L3), if MTU is set to 
1500.

Because if most platforms do not limit MRU, then the impact of MTU 
mismatch on the peering LAN is actually a lot less than otherwise.

However, I stand by my earlier statement that we need to include MTU/MRU 
in ND messages, so that this can be negotiated on a LAN where not all 
devices support large MTU.

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

From swmike at swm.pp.se  Thu Mar 10 16:22:34 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 10 Mar 2016 17:22:34 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <CAAeewD-7qQ28AxoSXnGEwP8xkXoUbBCNvvDZQppL1PviCKS5aQ@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
 <CAAeewD-7qQ28AxoSXnGEwP8xkXoUbBCNvvDZQppL1PviCKS5aQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1603101721490.31096@uplift.swm.pp.se>

On Thu, 10 Mar 2016, Saku Ytti wrote:

> On 10 March 2016 at 02:44, Niels Bakker <niels=nanog at bakker.net> wrote:
>> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too Big
>> messages.  That's why everybody must agree on one MTU.
>
> I think what was meant, no global consensus is needed, each IXP can
> decide themselves what is edgeMTU and coreMTU VLAN MTU sizes in /this/
> IXP. Heck, have customers vote on webpage. I guess edgeMTU obviously
> will be 1500, coreMTU something else, 4470, 9000 and 9100 seem like

9180 (L3 MTU) is the obvious choice. All major core routing platforms 
support it, and it's used in at least two "classic" L2 protocols (see my 
earlier email).

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

From cma at cmadams.net  Thu Mar 10 16:24:11 2016
From: cma at cmadams.net (Chris Adams)
Date: Thu, 10 Mar 2016 10:24:11 -0600
Subject: Cogent - Google - HE Fun
In-Reply-To: <55AD7CF5-4935-4710-835B-BE3F9E370E4C@delong.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <55AD7CF5-4935-4710-835B-BE3F9E370E4C@delong.com>
Message-ID: <20160310162411.GB8694@cmadams.net>

Once upon a time, Owen DeLong <owen at delong.com> said:
> In fairness, however, this is because he is not Google?s customer, he
> is Google?s product. Google is selling him (well, information about him
> anyway) to their customers. They gather this information by offering
> certain things he wants in exchange for him allowing them to collect
> and redistribute this data.

False supposition; Google does actually sell services as well.  $DAYJOB
pays Google for services, and has paid Cogent for network access.

-- 
Chris Adams <cma at cmadams.net>

From nick at foobar.org  Thu Mar 10 16:38:41 2016
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 10 Mar 2016 16:38:41 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <alpine.DEB.2.02.1603101719120.31096@uplift.swm.pp.se>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
 <alpine.DEB.2.02.1603101719120.31096@uplift.swm.pp.se>
Message-ID: <56E1A311.6020407@foobar.org>

Mikael Abrahamsson wrote:
> However, I stand by my earlier statement that we need to include MTU/MRU
> in ND messages, so that this can be negotiated on a LAN where not all
> devices support large MTU.

this would introduce a degree of network complexity that is unnecessary
and would be prone to problems.  It might be nice to have an
auto-configurable maximum frame size per broadcast domain, though.

Nick



From achatz at forthnet.gr  Thu Mar 10 16:56:30 2016
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 10 Mar 2016 18:56:30 +0200
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <alpine.DEB.2.02.1603101719120.31096@uplift.swm.pp.se>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
 <alpine.DEB.2.02.1603101719120.31096@uplift.swm.pp.se>
Message-ID: <56E1A73E.9090804@forthnet.gr>

Mikael Abrahamsson wrote on 10/3/16 18:21:
>
> However, I stand by my earlier statement that we need to include MTU/MRU in ND messages, so that this can be negotiated on a LAN where not all devices support large MTU.
>

Isn't this already supported?
https://tools.ietf.org/html/rfc4861#section-4.6.4

--
Tassos


From owen at delong.com  Thu Mar 10 16:56:51 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 10 Mar 2016 08:56:51 -0800
Subject: Cogent - Google - HE Fun
In-Reply-To: <20160310162411.GB8694@cmadams.net>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <55AD7CF5-4935-4710-835B-BE3F9E370E4C@delong.com>
 <20160310162411.GB8694@cmadams.net>
Message-ID: <F79C20C5-CDDF-4A54-AAF9-3860947AA806@delong.com>


> On Mar 10, 2016, at 08:24 , Chris Adams <cma at cmadams.net> wrote:
> 
> Once upon a time, Owen DeLong <owen at delong.com> said:
>> In fairness, however, this is because he is not Google?s customer, he
>> is Google?s product. Google is selling him (well, information about him
>> anyway) to their customers. They gather this information by offering
>> certain things he wants in exchange for him allowing them to collect
>> and redistribute this data.
> 
> False supposition; Google does actually sell services as well.  $DAYJOB
> pays Google for services, and has paid Cogent for network access.

Not my assumption? Assumption included from Bill Herrin?s message?

> Google, by contrast, makes no demand that Cogent pay them even though
> you are not paying Google for service. 

(Underline added for emphasis)

Owen


From swmike at swm.pp.se  Thu Mar 10 17:16:46 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 10 Mar 2016 18:16:46 +0100 (CET)
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E1A73E.9090804@forthnet.gr>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
 <alpine.DEB.2.02.1603101719120.31096@uplift.swm.pp.se>
 <56E1A73E.9090804@forthnet.gr>
Message-ID: <alpine.DEB.2.02.1603101815090.31096@uplift.swm.pp.se>

On Thu, 10 Mar 2016, Tassos Chatzithomaoglou wrote:

> Mikael Abrahamsson wrote on 10/3/16 18:21:
>>
>> However, I stand by my earlier statement that we need to include MTU/MRU in ND messages, so that this can be negotiated on a LAN where not all devices support large MTU.
>>
>
> Isn't this already supported?
> https://tools.ietf.org/html/rfc4861#section-4.6.4

That is in RAs, and pertains to a prefix. Also, if a device can't use the 
advertised MTU, they will keep lower MTU which might be causing MTU 
mismatch.

For instance, if I announce 9000 as MTU and a device is bridged via wifi, 
wifi chips generally only supports around 2300 in MTU, so you'll have MTU 
mismatch with MTU blackholing within the same L2 network. This is bad.

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

From bill at herrin.us  Thu Mar 10 17:29:26 2016
From: bill at herrin.us (William Herrin)
Date: Thu, 10 Mar 2016 12:29:26 -0500
Subject: Cogent - Google - HE Fun
In-Reply-To: <F79C20C5-CDDF-4A54-AAF9-3860947AA806@delong.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <55AD7CF5-4935-4710-835B-BE3F9E370E4C@delong.com>
 <20160310162411.GB8694@cmadams.net>
 <F79C20C5-CDDF-4A54-AAF9-3860947AA806@delong.com>
Message-ID: <CAP-guGXVxZGAQdqjRz9QRGjPndOXNAkjEpqS2bxv0Rb=hL+MMg@mail.gmail.com>

On Thu, Mar 10, 2016 at 11:56 AM, Owen DeLong <owen at delong.com> wrote:
>> On Mar 10, 2016, at 08:24 , Chris Adams <cma at cmadams.net> wrote:
>> Once upon a time, Owen DeLong <owen at delong.com> said:
>>> In fairness, however, this is because he is not Google?s customer, he
>>> is Google?s product.
>>
>> False supposition; Google does actually sell services as well.  $DAYJOB
>> pays Google for services, and has paid Cogent for network access.
>
> Not my assumption? Assumption included from Bill Herrin?s message?
>
>> Google, by contrast, makes no demand that Cogent pay them even though
>> you are not paying Google for service.


Guys, that would be an important distinction if Cogent were providing
Dennis with free service. They're not. Regardless of what Google does
or doesn't do, Dennis pays Cogent to connect him to the wide Internet
which emphatically includes Google. I'm sorry I said anything at all
about Dennis' relationship with Google because that is immaterial to
whether Cogent is honorably fulfilling its contract with Dennis.

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  Thu Mar 10 17:31:00 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 10 Mar 2016 09:31:00 -0800
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGXVxZGAQdqjRz9QRGjPndOXNAkjEpqS2bxv0Rb=hL+MMg@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <55AD7CF5-4935-4710-835B-BE3F9E370E4C@delong.com>
 <20160310162411.GB8694@cmadams.net>
 <F79C20C5-CDDF-4A54-AAF9-3860947AA806@delong.com>
 <CAP-guGXVxZGAQdqjRz9QRGjPndOXNAkjEpqS2bxv0Rb=hL+MMg@mail.gmail.com>
Message-ID: <DA896903-2FDE-4828-A8B7-2221B714523B@delong.com>


> On Mar 10, 2016, at 09:29 , William Herrin <bill at herrin.us> wrote:
> 
> On Thu, Mar 10, 2016 at 11:56 AM, Owen DeLong <owen at delong.com> wrote:
>>> On Mar 10, 2016, at 08:24 , Chris Adams <cma at cmadams.net> wrote:
>>> Once upon a time, Owen DeLong <owen at delong.com> said:
>>>> In fairness, however, this is because he is not Google?s customer, he
>>>> is Google?s product.
>>> 
>>> False supposition; Google does actually sell services as well.  $DAYJOB
>>> pays Google for services, and has paid Cogent for network access.
>> 
>> Not my assumption? Assumption included from Bill Herrin?s message?
>> 
>>> Google, by contrast, makes no demand that Cogent pay them even though
>>> you are not paying Google for service.
> 
> 
> Guys, that would be an important distinction if Cogent were providing
> Dennis with free service. They're not. Regardless of what Google does
> or doesn't do, Dennis pays Cogent to connect him to the wide Internet
> which emphatically includes Google. I'm sorry I said anything at all
> about Dennis' relationship with Google because that is immaterial to
> whether Cogent is honorably fulfilling its contract with Dennis.

Which doesn?t disagree with anything I said.

Owen


From sfrost at snowman.net  Thu Mar 10 18:30:32 2016
From: sfrost at snowman.net (Stephen Frost)
Date: Thu, 10 Mar 2016 13:30:32 -0500
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGXVxZGAQdqjRz9QRGjPndOXNAkjEpqS2bxv0Rb=hL+MMg@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <55AD7CF5-4935-4710-835B-BE3F9E370E4C@delong.com>
 <20160310162411.GB8694@cmadams.net>
 <F79C20C5-CDDF-4A54-AAF9-3860947AA806@delong.com>
 <CAP-guGXVxZGAQdqjRz9QRGjPndOXNAkjEpqS2bxv0Rb=hL+MMg@mail.gmail.com>
Message-ID: <20160310183032.GZ3127@tamriel.snowman.net>

* William Herrin (bill at herrin.us) wrote:
> Guys, that would be an important distinction if Cogent were providing
> Dennis with free service. They're not. Regardless of what Google does
> or doesn't do, Dennis pays Cogent to connect him to the wide Internet
> which emphatically includes Google. I'm sorry I said anything at all
> about Dennis' relationship with Google because that is immaterial to
> whether Cogent is honorably fulfilling its contract with Dennis.

Please tell me when I can get Verizon FiOS to agree that they're
supposed to provide me with access to the wide Internet, which includes
everything IPv6.

Thanks!

Stephen
-------------- 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/20160310/6c17bbec/attachment.pgp>

From nanog at ics-il.net  Thu Mar 10 18:37:11 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Thu, 10 Mar 2016 12:37:11 -0600 (CST)
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
Message-ID: <394811280.4839.1457635031077.JavaMail.mhammett@ThunderFuck>

Anyone that complains about double billing doesn't apparently know how the Internet works and should relegate themselves to writing articles for GigaOm. Oh.... 




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



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


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

From: "William Herrin" <bill at herrin.us> 
To: "Dennis Burgess" <dmburgess at linktechs.net> 
Cc: "North American Network Operators' Group" <nanog at nanog.org> 
Sent: Thursday, March 10, 2016 9:55:30 AM 
Subject: Re: AW: Cogent - Google - HE Fun 

On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess 
<dmburgess at linktechs.net> wrote: 
> Not wishing to get into a pissing war with who is right or wrong, but it sounds like 
> google already pays or has an agreement with cogent for v4, as that's unaffected, 
> cogent says google is simply not advertising v6 prefixes to them, so, how is 
> that cogent's fault? 

Hi Dennis, 

It's Cogent's fault because: double-billing. Google should not have to 
pay Cogent for a service which you have already paid Cogent to provide 
to you. Cogent's demand is unethical. They intentionally fail to 
deliver on the basic service expectation you pay them for and refuse 
to do so unless a third party to your contract also pays them. 

Google, by contrast, makes no demand that Cogent pay them even though 
you are not paying Google for service. They offer "open peering," a 
free interconnect via many neutral data centers. 

If you're not single-homed to Cogent and you have the balls for it, I 
would file an outage with Cogent and demand service credit until they 
resolve their IPv6 access problem with Google. And then refuse to pay 
until they connect with Google. 

If you are single-homed to Cogent, it's *very* important that you do 
something about that before you get burned in a way that matters. 

Regards, 
Bill Herrin 



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


From damien at supremebytes.com  Thu Mar 10 21:25:31 2016
From: damien at supremebytes.com (Damien Burke)
Date: Thu, 10 Mar 2016 21:25:31 +0000
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
Message-ID: <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>

Anyone who is multihomed with cogent ipv6 in their mix should shutdown their IPv6 bgp session. Let?s see if we can make their graph freefall.



[cid:image001.png at 01D17AD0.248335A0]



http://bgp.he.net/AS174#_asinfo





-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin
Sent: Thursday, March 10, 2016 7:56 AM
To: Dennis Burgess
Cc: North American Network Operators' Group
Subject: Re: AW: Cogent - Google - HE Fun



On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess <dmburgess at linktechs.net<mailto:dmburgess at linktechs.net>> wrote:

> Not wishing to get into a pissing war with who is right or wrong, but

> it sounds like google already pays or has an agreement with cogent for

> v4, as that's unaffected, cogent says google is simply not advertising

> v6 prefixes to them, so, how is that cogent's fault?



Hi Dennis,



It's Cogent's fault because: double-billing. Google should not have to pay Cogent for a service which you have already paid Cogent to provide to you. Cogent's demand is unethical. They intentionally fail to deliver on the basic service expectation you pay them for and refuse to do so unless a third party to your contract also pays them.



Google, by contrast, makes no demand that Cogent pay them even though you are not paying Google for service. They offer "open peering," a free interconnect via many neutral data centers.



If you're not single-homed to Cogent and you have the balls for it, I would file an outage with Cogent and demand service credit until they resolve their IPv6 access problem with Google. And then refuse to pay until they connect with Google.



If you are single-homed to Cogent, it's *very* important that you do something about that before you get burned in a way that matters.



Regards,

Bill Herrin







--

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

From kuenzler at init7.net  Thu Mar 10 21:47:34 2016
From: kuenzler at init7.net (Fredy Kuenzler)
Date: Thu, 10 Mar 2016 22:47:34 +0100
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
Message-ID: <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>

Am 10.03.2016 um 22:25 schrieb Damien Burke <damien at supremebytes.com>:
> Anyone who is multihomed with cogent ipv6 in their mix should shutdown their IPv6 bgp session. Let?s see if we can make their graph freefall.


Alternative:

set community [do not announce to Cogent]

*SCNR*

From mhardeman at ipifony.com  Thu Mar 10 22:19:23 2016
From: mhardeman at ipifony.com (Matthew D. Hardeman)
Date: Thu, 10 Mar 2016 16:19:23 -0600
Subject: Cogent - Google - HE Fun
In-Reply-To: <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
Message-ID: <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>

I have contemplated whether such mechanisms matter to Cogent, etc.

I?m inclined to think that if Google is willing to pull the routes and they still don?t blink, then certainly us smaller shops aren?t going to impact them?

However?  If enough prefixes disappear from the _apparent_ Cogent table as viewed by outsiders, this may ultimately impact their sales of new interconnection?.

For those of us multihomed with Cogent and other transit providers on IPv6 there is a less drastic way to impact the perceived value of Cogent?s IPv6 routing table to outsiders and especially to Cogent?s peers ? and one that still doesn?t negatively impact the single-home customers of Cogent:

"set community 174:3000" on your IPv6 advertisement to Cogent.  This will constrain the advertisement to Cogent and Cogent?s customers only.  For good measure, prepend your own AS to this advertisement at least a couple of times, potentially discouraging even Cogent customers who see the route from using it if they have other transit.  It will prevent the path via Cogent being selected by Cogent IPv6 peers versus your other transit providers.


> On Mar 10, 2016, at 3:47 PM, Fredy Kuenzler <kuenzler at init7.net> wrote:
> 
> Am 10.03.2016 um 22:25 schrieb Damien Burke <damien at supremebytes.com>:
>> Anyone who is multihomed with cogent ipv6 in their mix should shutdown their IPv6 bgp session. Let?s see if we can make their graph freefall.
> 
> 
> Alternative:
> 
> set community [do not announce to Cogent]
> 
> *SCNR*

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4190 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160310/c94354cd/attachment.bin>

From marka at isc.org  Thu Mar 10 22:29:57 2016
From: marka at isc.org (Mark Andrews)
Date: Fri, 11 Mar 2016 09:29:57 +1100
Subject: Cogent - Google - HE Fun
In-Reply-To: Your message of "Thu, 10 Mar 2016 16:19:23 -0600."
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
Message-ID: <20160310222957.C2B8D44412DD@rock.dv.isc.org>


I don't think anyone should be colluding to hurt Cogent or anyone
else for that matter and this thread appears to be heading in this
direction.

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

From kuenzler at init7.net  Thu Mar 10 22:42:05 2016
From: kuenzler at init7.net (Fredy Kuenzler)
Date: Thu, 10 Mar 2016 23:42:05 +0100
Subject: Cogent - Google - HE Fun
In-Reply-To: <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
Message-ID: <7840B98C-81FB-407C-91A3-98EC566C61AD@init7.net>

This would work for those which are using IPv6 transit from Cogent.

For anyone else which is using IPv6 transit from Hurricane Electric and some other suppliers such as L3 or NTT: to set the community 'do not announce to Cogent' only on every other transit but HE would help to isolate Cogent without much collateral damage. It would support Google/HE's position. And maybe help to bring back Cogent onto a cooperative track, after all.

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
St.-Georgen-Strasse 70
CH-8400 Winterthur
Switzerland

http://www.init7.net/


> Am 10.03.2016 um 23:19 schrieb Matthew D. Hardeman <mhardeman at ipifony.com>:
> 
> I have contemplated whether such mechanisms matter to Cogent, etc.
> 
> I?m inclined to think that if Google is willing to pull the routes and they still don?t blink, then certainly us smaller shops aren?t going to impact them?
> 
> However?  If enough prefixes disappear from the _apparent_ Cogent table as viewed by outsiders, this may ultimately impact their sales of new interconnection?.
> 
> For those of us multihomed with Cogent and other transit providers on IPv6 there is a less drastic way to impact the perceived value of Cogent?s IPv6 routing table to outsiders and especially to Cogent?s peers ? and one that still doesn?t negatively impact the single-home customers of Cogent:
> 
> "set community 174:3000" on your IPv6 advertisement to Cogent.  This will constrain the advertisement to Cogent and Cogent?s customers only.  For good measure, prepend your own AS to this advertisement at least a couple of times, potentially discouraging even Cogent customers who see the route from using it if they have other transit.  It will prevent the path via Cogent being selected by Cogent IPv6 peers versus your other transit providers.
> 
> 
>> On Mar 10, 2016, at 3:47 PM, Fredy Kuenzler <kuenzler at init7.net> wrote:
>> 
>> Am 10.03.2016 um 22:25 schrieb Damien Burke <damien at supremebytes.com>:
>>> Anyone who is multihomed with cogent ipv6 in their mix should shutdown their IPv6 bgp session. Let?s see if we can make their graph freefall.
>> 
>> 
>> Alternative:
>> 
>> set community [do not announce to Cogent]
>> 
>> *SCNR*
> 

From mhardeman at ipifony.com  Thu Mar 10 22:53:31 2016
From: mhardeman at ipifony.com (Matthew D. Hardeman)
Date: Thu, 10 Mar 2016 16:53:31 -0600
Subject: Cogent - Google - HE Fun
In-Reply-To: <20160310222957.C2B8D44412DD@rock.dv.isc.org>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
 <20160310222957.C2B8D44412DD@rock.dv.isc.org>
Message-ID: <A2E44AE0-5A51-4E2D-88D8-76B55D10AF3C@ipifony.com>

Mark,

I certainly agree that intentional harm of a purely malicious nature is to be discouraged.

What I proposed, as an alternative to some of the more extreme mechanisms being discussed, is a mechanism whereby IPv6 _customers_ of Cogent transit services--and who also receive IPv6 transit from at least one other relationship--can modify their IPv6 advertisements to Cogent such that they utilize that transit link with Cogent for the one thing you can reliably count on it for in the IPv6 world: reaching other Cogent IPv6 customers, especially the single-homed ones.

In essence, adding BGP community ?174:3000? to your IPv6 advertisements to Cogent instructs Cogent that this route should only be advertised internal to Cogent and to Cogent?s customers.  It should not be announced to peers.  Combining that with prepends of your own AS in the IPv6 advertisements to Cogent also reduces traffic from other multi-homed Cogent IPv6 customers.  In any event, if enough Cogent customers do this, it does greatly reduce the amount of traffic that Cogent gets to transit from their various IPv6 peers while still avoiding harm to innocent end-users (or for that matter, to guilty end users).

The mechanism I proposed has numerous benefits:

1.  It utilizes only a mechanism created by Cogent and documented for use by Cogent transit customers to achieve routing policy that benefits IPv6 customers of Cogent.
2.  It causes no harm to single-homed Cogent customers.
3.  It causes no direct harm to Cogent.  The sole indirect harm that it might bring upon Cogent if adopted en-masse would be to significantly drop the amount of traffic crossing Cogent?s SFI peerings on IPv6, which I acknowledge may have consequences for Cogent.  If it did have such consequences, it?s Cogent?s game and Cogent?s rules.  They could change it any time.  If it indirectly harms Cogent by lowering overall traffic volume on paid multi-homed customer transit connections, Cogent could easily remedy that by becoming an IPv6 network that one would want to exchange IPv6 transit traffic with rather than being an IPv6 network that one begrudgingly pays because one does business with others who are Cogent single-homed.

I do reiterate, however, that I would strongly discourage any kind of routing tricks that leave the innocent Cogent customers out in the cold.  That hurts those Cogent customers as well as you and/or your own customers and users.  Please, someone, think of the end-users here.

My advice to Cogent would be to remember something real simple:  When Big Boss #1 at RandomCorp has no trouble reaching Google services all night every night at home and then he comes to work and his office Internet does everything but Google?.  What he?ll remember is ?Charter works with Google, whoever we?re using at the office doesn?t.  Let?s switch.?  It?s shocking to me that an ISP with a retail segment thinks you can survive if Google doesn?t work, no matter what Google did to ensure it played out that way.  Frankly, Google could scream that they cut Cogent off because they didn?t like Cogent?s face and no one at retail would care.  They just want their Gmail back.  If Google wanted to force the issue faster, they could just stop the IPv4 transit routes to Cogent.  I think they?re taking a more balanced and conservative approach though.

Thanks,

Matt Hardeman

> On Mar 10, 2016, at 4:29 PM, Mark Andrews <marka at isc.org> wrote:
> 
> 
> I don't think anyone should be colluding to hurt Cogent or anyone
> else for that matter and this thread appears to be heading in this
> direction.
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4190 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160310/0d769164/attachment.bin>

From mhardeman at ipifony.com  Thu Mar 10 22:58:20 2016
From: mhardeman at ipifony.com (Matthew D. Hardeman)
Date: Thu, 10 Mar 2016 16:58:20 -0600
Subject: Cogent - Google - HE Fun
In-Reply-To: <7840B98C-81FB-407C-91A3-98EC566C61AD@init7.net>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
 <7840B98C-81FB-407C-91A3-98EC566C61AD@init7.net>
Message-ID: <222F44CC-715F-4F8C-8AEE-ECAD8FE59CF7@ipifony.com>

Freddy,

As there is no IPv6 transit between HE and Cogent, this would have the effect of isolating ones network services from the single-homed customers of Cogent.  I?m not sure that many of us could get away with that.  Further, I?m not sure that it?s appropriate to punish the single-homed Cogent customers.  I?ll grant, this is just what Google has done, but they?re well positioned to weather that storm and have a level of visibility and brand loyalty that will allow them to have a chance of success at it.

I think the softer approach of reducing the relevancy of Cogent?s IPv6 transit service and indeed the relevancy of peering with Cogent for IPv6 is a way forward that more of us could get behind.

Thanks,

Matt Hardeman

> On Mar 10, 2016, at 4:42 PM, Fredy Kuenzler <kuenzler at init7.net> wrote:
> 
> This would work for those which are using IPv6 transit from Cogent.
> 
> For anyone else which is using IPv6 transit from Hurricane Electric and some other suppliers such as L3 or NTT: to set the community 'do not announce to Cogent' only on every other transit but HE would help to isolate Cogent without much collateral damage. It would support Google/HE's position. And maybe help to bring back Cogent onto a cooperative track, after all.
> 
> --
> Fredy Kuenzler
> Init7 (Switzerland) Ltd.
> St.-Georgen-Strasse 70
> CH-8400 Winterthur
> Switzerland
> 
> http://www.init7.net/
> 
> 
>> Am 10.03.2016 um 23:19 schrieb Matthew D. Hardeman <mhardeman at ipifony.com>:
>> 
>> I have contemplated whether such mechanisms matter to Cogent, etc.
>> 
>> I?m inclined to think that if Google is willing to pull the routes and they still don?t blink, then certainly us smaller shops aren?t going to impact them?
>> 
>> However?  If enough prefixes disappear from the _apparent_ Cogent table as viewed by outsiders, this may ultimately impact their sales of new interconnection?.
>> 
>> For those of us multihomed with Cogent and other transit providers on IPv6 there is a less drastic way to impact the perceived value of Cogent?s IPv6 routing table to outsiders and especially to Cogent?s peers ? and one that still doesn?t negatively impact the single-home customers of Cogent:
>> 
>> "set community 174:3000" on your IPv6 advertisement to Cogent.  This will constrain the advertisement to Cogent and Cogent?s customers only.  For good measure, prepend your own AS to this advertisement at least a couple of times, potentially discouraging even Cogent customers who see the route from using it if they have other transit.  It will prevent the path via Cogent being selected by Cogent IPv6 peers versus your other transit providers.
>> 
>> 
>>> On Mar 10, 2016, at 3:47 PM, Fredy Kuenzler <kuenzler at init7.net> wrote:
>>> 
>>> Am 10.03.2016 um 22:25 schrieb Damien Burke <damien at supremebytes.com>:
>>>> Anyone who is multihomed with cogent ipv6 in their mix should shutdown their IPv6 bgp session. Let?s see if we can make their graph freefall.
>>> 
>>> 
>>> Alternative:
>>> 
>>> set community [do not announce to Cogent]
>>> 
>>> *SCNR*
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4190 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160310/cd0925ef/attachment.bin>

From bill at herrin.us  Thu Mar 10 23:42:41 2016
From: bill at herrin.us (William Herrin)
Date: Thu, 10 Mar 2016 18:42:41 -0500
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <394811280.4839.1457635031077.JavaMail.mhammett@ThunderFuck>
References: <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <394811280.4839.1457635031077.JavaMail.mhammett@ThunderFuck>
Message-ID: <CAP-guGUhs6QGGxt2pf9GLjHYFSXZkZh+=heOLNN=T5+KhOPpXQ@mail.gmail.com>

On Thu, Mar 10, 2016 at 1:37 PM, Mike Hammett <nanog at ics-il.net> wrote:

> Anyone that complains about double billing doesn't apparently know how the
> Internet works and should relegate themselves to writing articles for
> GigaOm.
>

Mike,

I picture you saying that with a Godfather voice and going on to talk about
friendship and respect.

Some very popular practices on the Internet are also very corrupt. That
they have 'always' been that way makes them no less corrupt.

-Bill

<https://www.facebook.com/ICSIL>
<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
<https://www.linkedin.com/company/intelligent-computing-solutions>
-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From motamedi at cs.uoregon.edu  Fri Mar 11 00:24:41 2016
From: motamedi at cs.uoregon.edu (Reza Motamedi)
Date: Thu, 10 Mar 2016 16:24:41 -0800
Subject: Figuring out traceroute
Message-ID: <CACGuEhH0h=47T266SBc0oX7xUvWQsddZDXO2g76r=Z1K1H+dfA@mail.gmail.com>

Hi guys,

This might seem a bit of a trivial question, but I guess there is no harm
in asking. I am looking at a collection of traceroutes all go through the
following consecutive hops (* >> 213.248.98.238), as shown here (I kept the
DNSname just for completeness):

+ From >> To
+ (213.155.130.125:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.130.127:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.75:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.83:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.85:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.251:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.77:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.57:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.59:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.114.111:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.168:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.170:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.174:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.176:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.178:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.180:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.182:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.184:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.186:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.188:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.190:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.255:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)

Given the way traceroute works (most of the times), which reports back the
ingress port of the router it hits, do you think it fair to assume that all
the hops that I see on the `From` hop are all different ports of one
router? I think the other explanation is that there is switch (or something
that does not have IP footprint) between `From` side and `To` side. How
probable do you think this second explanation is?

Best Regards
Reza Motamedi (R.M)

From yang.yu.list at gmail.com  Fri Mar 11 00:57:54 2016
From: yang.yu.list at gmail.com (Yang Yu)
Date: Thu, 10 Mar 2016 18:57:54 -0600
Subject: Facebook & Traceroute
In-Reply-To: <CAL9jLaZZhuu-VA_1Pph4rFrj7xE9RSg_cZ0B1sfEt-frCzZCEA@mail.gmail.com>
References: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
 <CAL9jLaZwVgxQ9A7AkEUF3UMi6LUBGdyb4P-rchTbuDN0BO7dpQ@mail.gmail.com>
 <095f01d17a84$66cb8260$34628720$@SanDiegoBroadband.com>
 <CAL9jLaZZhuu-VA_1Pph4rFrj7xE9RSg_cZ0B1sfEt-frCzZCEA@mail.gmail.com>
Message-ID: <CAFwKRnT8aS12X_fRuBp-4P_3S++EeHEHZ_vAAG7G94sjyw=0jA@mail.gmail.com>

On Thu, Mar 10, 2016 at 9:35 AM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:

> unclear, that traceroute was from someplace I don't own the network for...
> from another place I do though...
>
>  5  ae0.dr07.ash2.tfbnw.net (31.13.26.233)  4 ms
> ae0.dr05.ash3.tfbnw.net (31.13.29.21)  4 ms ae0.dr08.ash2.tfbnw.net
> (31.13.26.235)  2 ms
>  6  * * *
>  7  * * *
>  8  * * *
>  9  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  3 ms  3 ms  2 ms
>
> same-ish results, no spoofed bits.

https://atlas.ripe.net/measurements/3612424/#!probes

I did a atlas measurement of 500 probes, 104 probes (21%) had their
outside IP shown in traceroute. Some peers of AS32934 don't have
ingress filtering. It seems all prefixes advertised by Facebook are
ROA signed and valid tho.

From JJaritsch at anexia-it.com  Fri Mar 11 06:07:28 2016
From: JJaritsch at anexia-it.com (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=)
Date: Fri, 11 Mar 2016 06:07:28 +0000
Subject: Figuring out traceroute
In-Reply-To: <CACGuEhH0h=47T266SBc0oX7xUvWQsddZDXO2g76r=Z1K1H+dfA@mail.gmail.com>
References: <CACGuEhH0h=47T266SBc0oX7xUvWQsddZDXO2g76r=Z1K1H+dfA@mail.gmail.com>
Message-ID: <e1e775d68bbf4b31ba3cb3390beb8fc3@anx-i-dag02.anx.local>

Looks like the device is always las-b3 (Los Angeles, border 3). As far as I know Telia works with IS-IS and multiple load balanced links from each bb (backbone) router to each border router. Usually they don't deal with L2 in case of customer BGP downlinks.



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: Reza Motamedi [motamedi at cs.uoregon.edu]
Received: Freitag, 11 M?rz 2016, 1:26
To: nanog at nanog.org [nanog at nanog.org]
Subject: Figuring out traceroute

Hi guys,

This might seem a bit of a trivial question, but I guess there is no harm
in asking. I am looking at a collection of traceroutes all go through the
following consecutive hops (* >> 213.248.98.238), as shown here (I kept the
DNSname just for completeness):

+ From >> To
+ (213.155.130.125:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.130.127:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.75:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.83:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.85:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.251:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.77:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.57:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.59:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.114.111:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.168:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.170:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.174:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.176:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.178:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.180:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.182:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.184:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.186:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.188:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.190:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.255:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)

Given the way traceroute works (most of the times), which reports back the
ingress port of the router it hits, do you think it fair to assume that all
the hops that I see on the `From` hop are all different ports of one
router? I think the other explanation is that there is switch (or something
that does not have IP footprint) between `From` side and `To` side. How
probable do you think this second explanation is?

Best Regards
Reza Motamedi (R.M)

From mark.tinka at seacom.mu  Fri Mar 11 07:52:55 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 11 Mar 2016 09:52:55 +0200
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <20160311073353.793A23087FA8_6E274E1B@mx1.seacom.mu>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.793A23087FA8_6E274E1B@mx1.seacom.mu>
Message-ID: <06d9287d-21d7-c603-6059-5031a9aeea69@seacom.mu>



On 10/Mar/16 17:25, Jon Lewis wrote:

> My guess is that GOOG is playing peering chicken with Cogent on "the
> IPv6 Internet" because doing so is low impact.  Doing this with v4
> routing would be far more painful to both GOOG and single-homed Cogent
> customers (probably make the news and make one or both look bad). 
> Doing this with v6 keeps it off in the shadows...both parties know its
> an issue, but its likely not seriously impacting anyone yet.  GOOG
> likely thinks they're big enough and their content desirable enough,
> that Cogent should peer with them.  Cogent clearly disagrees.  I'm
> sure GOOG would prefer SFI with Cogent for v4 and v6...but they're
> working on getting v6 first.

Assuming the IPv6 traffic is traversing the same physical ports as IPv4
between both networks, it is actually unnecessary pain to not pass IPv6
traffic across their interconnect relationship, unless removal of IPv6
peering lowers traffic utilization significantly to negate the need for
Google to pay a higher rate to Cogent, and/or delay physical port speed
upgrades.

Mark.

From mark.tinka at seacom.mu  Fri Mar 11 07:55:13 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Fri, 11 Mar 2016 09:55:13 +0200
Subject: Cogent - Google - HE Fun
In-Reply-To: <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
Message-ID: <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>



On 10/Mar/16 17:51, Owen DeLong wrote:

> I think it?s a little different from what you say?
>
> I think Google already reaches Cogent for IPv4 via transit.
>
> Google, long ago, announced that they would not be purchasing IPv6 transit and that they have an open peering policy for anyone who wishes to reach them. In order to avoid significant disruption, they haven?t terminated their IPv4 transit contracts, but it certainly makes sense that they would not be pursuing IPv6 transit contracts.

Understandable, but sort of moot if interconnect ports are dual-stack
and there are no discrete charges for IPv4 or IPv6.

Of course, if removal of IPv6 traffic saves bandwidth and operational
costs for Google interconnect with Cogent, then that makes sense to do.

Mark.

From jlewis at lewis.org  Fri Mar 11 12:40:26 2016
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 11 Mar 2016 07:40:26 -0500 (EST)
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1603110731270.6833@soloth.lewis.org>

On Thu, 10 Mar 2016, William Herrin wrote:

> It's Cogent's fault because: double-billing. Google should not have to
> pay Cogent for a service which you have already paid Cogent to provide
> to you. Cogent's demand is unethical. They intentionally fail to
> deliver on the basic service expectation you pay them for and refuse
> to do so unless a third party to your contract also pays them.

That's one way of looking at it.

However, which of your transits don't bill for bits exchanged with other 
customers of theirs...and how are they or you accounting for that traffic?

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

From me at geordish.org  Fri Mar 11 12:57:30 2016
From: me at geordish.org (Dave Bell)
Date: Fri, 11 Mar 2016 12:57:30 +0000
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
Message-ID: <CACXVQYApLX9X6wwK6dDXkh78N28_7gDnqkTNFdz1O9GitHXRJA@mail.gmail.com>

On 10 March 2016 at 15:55, William Herrin <bill at herrin.us> wrote:
> It's Cogent's fault because: double-billing. Google should not have to
> pay Cogent for a service which you have already paid Cogent to provide
> to you. Cogent's demand is unethical. They intentionally fail to
> deliver on the basic service expectation you pay them for and refuse
> to do so unless a third party to your contract also pays them.
>
> Google, by contrast, makes no demand that Cogent pay them even though
> you are not paying Google for service. They offer "open peering," a
> free interconnect via many neutral data centers.

I don't get this. Google are basically a hosting provider. If I set up
my own website, I would expect to have to pay transit for it. If I ran
a hosting business I would expect to pay transit. Why are google
different?

Its Google's decision to decide not to pay for transit for v6.
Considering how open they are to peering, and how large their network
it, it probably makes a lot of sense. If you need to connect to a
transit provider, you can probably peer with google at the same
location.

Cogent is in the business of trying to provide transit. I understand
there are probably good business cases where you may want to set up an
SFI with someone like google, but at the end of the day that's their
choice.

I get the arguments that Cogent are supposed to be supplying a full
view of the DFZ, but if Joe's Hosting Company refuses to pay anyone
for transit, surely it is their own fault that their reachability is
compromised?

Regards,
Dave

From bill at herrin.us  Fri Mar 11 14:16:18 2016
From: bill at herrin.us (William Herrin)
Date: Fri, 11 Mar 2016 09:16:18 -0500
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <Pine.LNX.4.61.1603110731270.6833@soloth.lewis.org>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <Pine.LNX.4.61.1603110731270.6833@soloth.lewis.org>
Message-ID: <CAP-guGUqXWvgKNckGODXwLWo9fZfQSSafzawVhBFOefWqbnHBA@mail.gmail.com>

On Fri, Mar 11, 2016 at 7:40 AM, Jon Lewis <jlewis at lewis.org> wrote:
> On Thu, 10 Mar 2016, William Herrin wrote:
>> It's Cogent's fault because: double-billing. Google should not have to
>> pay Cogent for a service which you have already paid Cogent to provide
>> to you. Cogent's demand is unethical. They intentionally fail to
>> deliver on the basic service expectation you pay them for and refuse
>> to do so unless a third party to your contract also pays them.
>
> That's one way of looking at it.
>
> However, which of your transits don't bill for bits exchanged with other
> customers of theirs...and how are they or you accounting for that traffic?

Hi Jon,

As you know, there is a technology limitation in how routing works
which says that for any given block of addresses you can, absent
extraordinary measures, have a peering relationship or a transit
relationship but not both. If both parties choose to have a transit
relationship, that excludes a peering relationship for the relevant
blocks of addresses. And that's OK when _both sides_ choose it.

In related news, no ethical conundrum demands defiance of the law of gravity.

Regards,
Bill Herrin

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

From swmike at swm.pp.se  Fri Mar 11 14:22:25 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 11 Mar 2016 15:22:25 +0100 (CET)
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <CACXVQYApLX9X6wwK6dDXkh78N28_7gDnqkTNFdz1O9GitHXRJA@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <CACXVQYApLX9X6wwK6dDXkh78N28_7gDnqkTNFdz1O9GitHXRJA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1603111521000.31096@uplift.swm.pp.se>

On Fri, 11 Mar 2016, Dave Bell wrote:

> I don't get this. Google are basically a hosting provider. If I set up 
> my own website, I would expect to have to pay transit for it. If I ran a 
> hosting business I would expect to pay transit. Why are google 
> different?

If you had presence all across the world and were providing a sizable 
chunk of the world total traffic, you would probably reason differently.

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

From rjacobs at pslightwave.com  Fri Mar 11 15:18:44 2016
From: rjacobs at pslightwave.com (Robert Jacobs)
Date: Fri, 11 Mar 2016 15:18:44 +0000
Subject: Cogent - Google - HE Fun
In-Reply-To: <A2E44AE0-5A51-4E2D-88D8-76B55D10AF3C@ipifony.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
 <20160310222957.C2B8D44412DD@rock.dv.isc.org>
 <A2E44AE0-5A51-4E2D-88D8-76B55D10AF3C@ipifony.com>
Message-ID: <BN1PR06MB2324D843A1B02F356FAD39FA9B50@BN1PR06MB232.namprd06.prod.outlook.com>

Don't like what Cogent is doing but just to bring this back to reality Matthew and others out there... What content do you think Google has or any other big content provider that is IPV6 only or gives an IPV6 only response to a query from Cogent that would not work via normal IPV4 routes and IP's.. Till we have exclusive content on IPV6 or it is a shorter, faster, bigger, better path then we are still fighting this uphill battle to get more adoption of IPV6 and it will not matter to the majority of Cogent customers that they can't get full IPV6 routes and connections from Cogent.

Robert Jacobs?|?Network Architect Director

Direct:??832-615-7742
Main:?? 832-615-8000
Fax:????713-510-1650

5959 Corporate Dr. Suite 3300; Houston, TX 77036



 

?

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew D. Hardeman
Sent: Thursday, March 10, 2016 4:54 PM
To: Mark Andrews <marka at isc.org>
Cc: North American Network Operators' Group <nanog at nanog.org>
Subject: Re: Cogent - Google - HE Fun

Mark,

I certainly agree that intentional harm of a purely malicious nature is to be discouraged.

What I proposed, as an alternative to some of the more extreme mechanisms being discussed, is a mechanism whereby IPv6 _customers_ of Cogent transit services--and who also receive IPv6 transit from at least one other relationship--can modify their IPv6 advertisements to Cogent such that they utilize that transit link with Cogent for the one thing you can reliably count on it for in the IPv6 world: reaching other Cogent IPv6 customers, especially the single-homed ones.

In essence, adding BGP community ?174:3000? to your IPv6 advertisements to Cogent instructs Cogent that this route should only be advertised internal to Cogent and to Cogent?s customers.  It should not be announced to peers.  Combining that with prepends of your own AS in the IPv6 advertisements to Cogent also reduces traffic from other multi-homed Cogent IPv6 customers.  In any event, if enough Cogent customers do this, it does greatly reduce the amount of traffic that Cogent gets to transit from their various IPv6 peers while still avoiding harm to innocent end-users (or for that matter, to guilty end users).

The mechanism I proposed has numerous benefits:

1.  It utilizes only a mechanism created by Cogent and documented for use by Cogent transit customers to achieve routing policy that benefits IPv6 customers of Cogent.
2.  It causes no harm to single-homed Cogent customers.
3.  It causes no direct harm to Cogent.  The sole indirect harm that it might bring upon Cogent if adopted en-masse would be to significantly drop the amount of traffic crossing Cogent?s SFI peerings on IPv6, which I acknowledge may have consequences for Cogent.  If it did have such consequences, it?s Cogent?s game and Cogent?s rules.  They could change it any time.  If it indirectly harms Cogent by lowering overall traffic volume on paid multi-homed customer transit connections, Cogent could easily remedy that by becoming an IPv6 network that one would want to exchange IPv6 transit traffic with rather than being an IPv6 network that one begrudgingly pays because one does business with others who are Cogent single-homed.

I do reiterate, however, that I would strongly discourage any kind of routing tricks that leave the innocent Cogent customers out in the cold.  That hurts those Cogent customers as well as you and/or your own customers and users.  Please, someone, think of the end-users here.

My advice to Cogent would be to remember something real simple:  When Big Boss #1 at RandomCorp has no trouble reaching Google services all night every night at home and then he comes to work and his office Internet does everything but Google?.  What he?ll remember is ?Charter works with Google, whoever we?re using at the office doesn?t.  Let?s switch.?  It?s shocking to me that an ISP with a retail segment thinks you can survive if Google doesn?t work, no matter what Google did to ensure it played out that way.  Frankly, Google could scream that they cut Cogent off because they didn?t like Cogent?s face and no one at retail would care.  They just want their Gmail back.  If Google wanted to force the issue faster, they could just stop the IPv4 transit routes to Cogent.  I think they?re taking a more balanced and conservative approach though.

Thanks,

Matt Hardeman

> On Mar 10, 2016, at 4:29 PM, Mark Andrews <marka at isc.org> wrote:
> 
> 
> I don't think anyone should be colluding to hurt Cogent or anyone
> else for that matter and this thread appears to be heading in this
> direction.
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From morrowc.lists at gmail.com  Fri Mar 11 15:35:16 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 11 Mar 2016 10:35:16 -0500
Subject: Cogent - Google - HE Fun
In-Reply-To: <BN1PR06MB2324D843A1B02F356FAD39FA9B50@BN1PR06MB232.namprd06.prod.outlook.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
 <20160310222957.C2B8D44412DD@rock.dv.isc.org>
 <A2E44AE0-5A51-4E2D-88D8-76B55D10AF3C@ipifony.com>
 <BN1PR06MB2324D843A1B02F356FAD39FA9B50@BN1PR06MB232.namprd06.prod.outlook.com>
Message-ID: <CAL9jLaa87TpU1m_irrQ=W3xK=0WQ0xjw+SRiTLYR8yBVWXyODA@mail.gmail.com>

On Fri, Mar 11, 2016 at 10:18 AM, Robert Jacobs <rjacobs at pslightwave.com> wrote:
> Don't like what Cogent is doing but just to bring this back to reality Matthew and others out there... What content do you think Google has or any other big content provider that is IPV6 only or gives an IPV6 only response to a query from Cogent that would not work
via normal IPV4 routes and IP's.. Till we have exclusive content on
IPV6 or it is a shorter,

it's not relevant (really) that 'you can still get there over v4',
because if your clients have ipv6, they'll ask for both, not
everything happy-eyeballs it's way to success, so
timeouts/frustration/pain occur.

I bet that's where the OP's original questions stem.

-chris

From tknchris at gmail.com  Fri Mar 11 16:30:53 2016
From: tknchris at gmail.com (chris)
Date: Fri, 11 Mar 2016 11:30:53 -0500
Subject: Verizon Voice Engineering Contact?
Message-ID: <CAKnNFz86SqEjDU_P_GKG5ketp=W2XjGkK7vSVOz7_-jVsMaQBg@mail.gmail.com>

Anyone from Verizon on the voice side on the list or if anyone has any good
contacts they can share?

We have customers in LATA 224 who cannot complete calls to a common carrier
and are hearing an audible verizon message "we're sorry all circuits are
busy now"

Please contact offlist

Thanks
chris

From jra at baylink.com  Fri Mar 11 16:52:27 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Fri, 11 Mar 2016 16:52:27 +0000 (UTC)
Subject: Cogent - Google - HE Fun
In-Reply-To: <20160310222957.C2B8D44412DD@rock.dv.isc.org>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
 <20160310222957.C2B8D44412DD@rock.dv.isc.org>
Message-ID: <1029507163.46532.1457715147924.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Mark Andrews" <marka at isc.org>

> I don't think anyone should be colluding to hurt Cogent or anyone
> else for that matter and this thread appears to be heading in this
> direction.

I suspect a distinction could be made in court by a competent attorney between

"colluding to hurt Cogent"

and

"collaborating to keep Cogent's ill-chosen policies from hurting the utility 
of the greater Internet".

The Law does not guarantee *any* business the unsullied right to conduct its
business in any particular way and expect that always to work; companies
much newer than buggy-whip manufacturers have long since learned that.

[ I am not an attorney; if my advice breaks something, you get to keep both pieces. ]

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 sean at donelan.com  Fri Mar 11 17:03:43 2016
From: sean at donelan.com (Sean Donelan)
Date: Fri, 11 Mar 2016 12:03:43 -0500 (EST)
Subject: Why the US Government has so many data centers
Message-ID: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>

If you've wondered why the U.S. Government has so many data centers, ok I 
know no one has ever asked.

The U.S. Government has an odd defintion of what is a data center, which
ends up with a lot of things no rational person would call a data center.

If you call every room with even one server a "data center," you'll end up 
with tens of thousands of rooms now data centers.  With this defintiion, I 
probably have two data centers in my home.  Its important because 
Inspectors General auditors will go around and count things, because 
that's what they do, and write reports about insane numbers of data 
centers.


https://datacenters.cio.gov/optimization/

"For the purposes of this memorandum, rooms with at least one server, 
providing services (whether in a production, test, stage, development, or 
any other environment), are considered data centers. However, rooms 
containing only routing equipment, switches, security devices (such as 
firewalls), or other telecommunications components shall not be considered 
data centers."

From rdobbins at arbor.net  Fri Mar 11 17:21:52 2016
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 12 Mar 2016 00:21:52 +0700
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
Message-ID: <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>

On 12 Mar 2016, at 0:03, Sean Donelan wrote:

> The U.S. Government has an odd defintion of what is a data center, 
> which ends up with a lot of things no rational person would call a 
> data center.

There's also a case to be made that governmental organizations really 
oughtn't to have servers just lying around in random rooms, and that 
those rooms are de facto government data centers, whether those who're 
responsible for said rooms/servers know it or not . . .

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

From cscora at apnic.net  Fri Mar 11 18:11:15 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 12 Mar 2016 04:11:15 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201603111811.u2BIBFnK025161@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

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

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

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

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

Analysis Summary
----------------

BGP routing table entries examined:                              586718
    Prefixes after maximum aggregation (per Origin AS):          215597
    Deaggregation factor:                                          2.72
    Unique aggregates announced (without unneeded subnets):      285921
Total ASes present in the Internet Routing Table:                 53056
    Prefixes per ASN:                                             11.06
Origin-only ASes present in the Internet Routing Table:           36592
Origin ASes announcing only one prefix:                           15789
Transit ASes present in the Internet Routing Table:                6412
Transit-only ASes present in the Internet Routing Table:            167
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      39
    Max AS path prepend of ASN ( 40285)                              34
Prefixes from unregistered ASNs in the Routing Table:              1062
    Unregistered ASNs in the Routing Table:                         367
Number of 32-bit ASNs allocated by the RIRs:                      13030
Number of 32-bit ASNs visible in the Routing Table:               10052
Prefixes from 32-bit ASNs in the Routing Table:                   39223
Number of bogon 32-bit ASNs visible in the Routing Table:            15
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            345
Number of addresses announced to Internet:                   2808944324
    Equivalent to 167 /8s, 109 /16s and 22 /24s
    Percentage of available address space announced:               75.9
    Percentage of allocated address space announced:               75.9
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.0
Total number of prefixes smaller than registry allocations:      192220

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   150355
    Total APNIC prefixes after maximum aggregation:               41706
    APNIC Deaggregation factor:                                    3.61
Prefixes being announced from the APNIC address blocks:          160207
    Unique aggregates announced from the APNIC address blocks:    64684
APNIC Region origin ASes present in the Internet Routing Table:    5153
    APNIC Prefixes per ASN:                                       31.09
APNIC Region origin ASes announcing only one prefix:               1192
APNIC Region transit ASes present in the Internet Routing Table:    905
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         39
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1931
Number of APNIC addresses announced to Internet:              753310980
    Equivalent to 44 /8s, 230 /16s and 157 /24s
    Percentage of available APNIC address space announced:         88.0

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:                    179827
    Total ARIN prefixes after maximum aggregation:                88882
    ARIN Deaggregation factor:                                     2.02
Prefixes being announced from the ARIN address blocks:           184828
    Unique aggregates announced from the ARIN address blocks:     87774
ARIN Region origin ASes present in the Internet Routing Table:    16409
    ARIN Prefixes per ASN:                                        11.26
ARIN Region origin ASes announcing only one prefix:                5890
ARIN Region transit ASes present in the Internet Routing Table:    1699
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          37
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1069
Number of ARIN addresses announced to Internet:              1102423104
    Equivalent to 65 /8s, 181 /16s and 164 /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:                    141090
    Total RIPE prefixes after maximum aggregation:                69682
    RIPE Deaggregation factor:                                     2.02
Prefixes being announced from the RIPE address blocks:           149636
    Unique aggregates announced from the RIPE address blocks:     92320
RIPE Region origin ASes present in the Internet Routing Table:    18052
    RIPE Prefixes per ASN:                                         8.29
RIPE Region origin ASes announcing only one prefix:                7939
RIPE Region transit ASes present in the Internet Routing Table:    3012
Average RIPE Region AS path length visible:                         4.8
    Max RIPE Region AS path length visible:                          30
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4538
Number of RIPE addresses announced to Internet:               703641472
    Equivalent to 41 /8s, 240 /16s and 183 /24s
    Percentage of available RIPE address space announced:         102.3

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:                   61670
    Total LACNIC prefixes after maximum aggregation:              12115
    LACNIC Deaggregation factor:                                   5.09
Prefixes being announced from the LACNIC address blocks:          75505
    Unique aggregates announced from the LACNIC address blocks:   35198
LACNIC Region origin ASes present in the Internet Routing Table:   2458
    LACNIC Prefixes per ASN:                                      30.72
LACNIC Region origin ASes announcing only one prefix:               578
LACNIC Region transit ASes present in the Internet Routing Table:   556
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2324
Number of LACNIC addresses announced to Internet:             171050752
    Equivalent to 10 /8s, 50 /16s and 7 /24s
    Percentage of available LACNIC address space announced:       102.0

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:                  14441
    Total AfriNIC prefixes after maximum aggregation:              3171
    AfriNIC Deaggregation factor:                                  4.55
Prefixes being announced from the AfriNIC address blocks:         16197
    Unique aggregates announced from the AfriNIC address blocks:   5641
AfriNIC Region origin ASes present in the Internet Routing Table:   739
    AfriNIC Prefixes per ASN:                                     21.92
AfriNIC Region origin ASes announcing only one prefix:              190
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:                       18
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  190
Number of AfriNIC addresses announced to Internet:             78155264
    Equivalent to 4 /8s, 168 /16s and 142 /24s
    Percentage of available AfriNIC address space announced:       77.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
 4538     5590       4192          76   China Education and Research 
 4766     3144      11142        1115   Korea Telecom
 7545     3089        351         184   TPG Telecom Limited
17974     2903        914          96   PT Telekomunikasi Indonesia
 9829     2390       1449         427   National Internet Backbone
 4755     2096        432         245   TATA Communications formerly 
 9808     1855       8717          30   Guangdong Mobile Communicatio
45899     1692       1094         170   VNNIC
 4808     1641       2287         522   CNCGROUP IP network China169 
 4788     1520        645          64   TM Net, Internet Service Prov

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     3343       2948         143   Cox Communications Inc.
 6389     2394       3687          42   BellSouth.net Inc.
18566     2211        394         276   MegaPath Corporation
20115     1914       1921         401   Charter Communications
30036     1730        342         253   Mediacom Communications Corp
 6983     1690        849         232   EarthLink, Inc.
 4323     1585       1004         392   tw telecom holdings, inc.
  209     1502       4483        1212   Qwest Communications Company,
  701     1391      11453         660   MCI Communications Services, 
11492     1259        234         594   CABLE ONE, INC.

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     2515        135           9   SaudiNet, Saudi Telecom Compa
20940     2404        925        1729   Akamai International B.V.
34984     1952        322         414   TELLCOM ILETISIM HIZMETLERI A
 8551     1230        376          54   Bezeq International-Ltd
 6849     1179        355          21   JSC "Ukrtelecom"
12479     1144        980          86   France Telecom Espana SA
 8402     1125        544          15   OJSC "Vimpelcom"
13188     1077         98          78   TOV "Bank-Inform"
31148     1041         47          41   Freenet Ltd.
 9198      949        352          25   JSC Kazakhtelecom

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     3447        542         122   Telmex Colombia S.A.
 8151     2221       3412         551   Uninet S.A. de C.V.
 7303     1521        941         238   Telecom Argentina S.A.
11830     1442        366          25   Instituto Costarricense de El
 6503     1432        453          56   Axtel, S.A.B. de C.V.
 6147     1036        377          27   Telefonica del Peru S.A.A.
 3816      994        478         185   COLOMBIA TELECOMUNICACIONES S
 7738      994       1882          41   Telemar Norte Leste S.A.
26615      994       2325          34   Tim Celular S.A.
28573      991       2172         159   NET Servi?os de Comunica??o S

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     1201        402          35   Link Egypt (Link.NET)
 8452     1008       1472          15   TE-AS
37611      633         48           2   Afrihost-Brevis Computer Serv
36903      584        294         104   Office National des Postes et
36992      505       1357          25   ETISALAT MISR
37492      377        217          64   Orange Tunisie
24835      338        146          12   Vodafone Data
29571      267         21          12   Cote d'Ivoire Telecom
 2018      250        327          74   TENET (The UNINET Project)
36947      231        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
 4538     5590       4192          76   China Education and Research 
10620     3447        542         122   Telmex Colombia S.A.
22773     3343       2948         143   Cox Communications Inc.
 4766     3144      11142        1115   Korea Telecom
 7545     3089        351         184   TPG Telecom Limited
17974     2903        914          96   PT Telekomunikasi Indonesia
39891     2515        135           9   SaudiNet, Saudi Telecom Compa
20940     2404        925        1729   Akamai International B.V.
 6389     2394       3687          42   BellSouth.net Inc.
 9829     2390       1449         427   National Internet Backbone

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
10620      3447        3325      Telmex Colombia S.A.
22773      3343        3200      Cox Communications Inc.
 7545      3089        2905      TPG Telecom Limited
17974      2903        2807      PT Telekomunikasi Indonesia
39891      2515        2506      SaudiNet, Saudi Telecom Compa
 6389      2394        2352      BellSouth.net Inc.
 4766      3144        2029      Korea Telecom
 9829      2390        1963      National Internet Backbone
18566      2211        1935      MegaPath Corporation
 4755      2096        1851      TATA Communications formerly 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
65001   PRIVATE      5.143.176.0/20       15468       OJSC Rostelecom
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         3356       Level 3 Communicatio
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
16589   UNALLOCATED  8.20.247.0/24        35838       CCANET Limited
16589   UNALLOCATED  8.26.56.0/24         35838       CCANET Limited
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.
37.46.15.0/24        36351     SoftLayer Technologies Inc.
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.3.0/24         37004     >>UNKNOWN<<
41.73.4.0/24         37004     >>UNKNOWN<<

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:101     /12:267     
/13:517     /14:1030    /15:1763    /16:12978   /17:7575    /18:12702   
/19:25792   /20:38135   /21:40194   /22:65126   /23:56317   /24:322554  
/25:542     /26:585     /27:404     /28:19      /29:16      /30:13      
/31:0       /32:23      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2527          3343      Cox Communications Inc.
39891     2472          2515      SaudiNet, Saudi Telecom Compa
18566     2113          2211      MegaPath Corporation
30036     1545          1730      Mediacom Communications Corp
 6389     1521          2394      BellSouth.net Inc.
 6983     1340          1690      EarthLink, Inc.
10620     1332          3447      Telmex Colombia S.A.
34984     1241          1952      TELLCOM ILETISIM HIZMETLERI A
11492     1169          1259      CABLE ONE, INC.
 6849      997          1179      JSC "Ukrtelecom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1640      2:737       4:20        5:2075      6:26        8:917    
  12:1774     13:38       14:1617     15:45       16:2        17:72     
  18:20       20:49       23:1407     24:1742     27:2259     31:1746   
  32:54       33:2        34:3        35:4        36:240      37:2339   
  38:1177     39:26       40:88       41:2956     42:385      43:1658   
  44:40       45:1706     46:2451     47:71       49:1116     50:836    
  51:8        52:83       54:197      55:3        56:6        57:44     
  58:1515     59:861      60:562      61:1796     62:1477     63:1927   
  64:4437     65:2165     66:4011     67:2107     68:1100     69:3263   
  70:1063     71:468      72:1971     74:2543     75:340      76:439    
  77:1373     78:1273     79:833      80:1314     81:1363     82:913    
  83:675      84:800      85:1586     86:466      87:1053     88:570    
  89:1943     90:167      91:6047     92:857      93:2296     94:2368   
  95:2307     96:459      97:352      98:959      99:45      100:70     
 101:1002    103:9873    104:2230    105:178     106:393     107:1146   
 108:656     109:2116    110:1263    111:1613    112:940     113:1279   
 114:1058    115:1692    116:1530    117:1383    118:2131    119:1565   
 120:513     121:1163    122:2224    123:2015    124:1613    125:1741   
 128:725     129:376     130:430     131:1257    132:605     133:171    
 134:448     135:122     136:353     137:332     138:1696    139:212    
 140:338     141:468     142:630     143:874     144:607     145:160    
 146:851     147:636     148:1467    149:482     150:659     151:827    
 152:604     153:270     154:555     155:902     156:489     157:444    
 158:347     159:1098    160:427     161:727     162:2293    163:531    
 164:727     165:1123    166:311     167:1075    168:1568    169:611    
 170:1571    171:267     172:493     173:1667    174:721     175:888    
 176:1515    177:4061    178:2237    179:1089    180:2084    181:1674   
 182:1953    183:672     184:809     185:5907    186:3018    187:2036   
 188:2101    189:1761    190:7682    191:1244    192:8906    193:5729   
 194:4370    195:3765    196:1648    197:1173    198:5497    199:5614   
 200:6845    201:3706    202:10121   203:9587    204:4627    205:2705   
 206:2968    207:3103    208:4063    209:3889    210:3945    211:2030   
 212:2668    213:2192    214:828     215:73      216:5748    217:1902   
 218:762     219:568     220:1653    221:856     222:675     223:930    


End of report

From morrowc.lists at gmail.com  Fri Mar 11 18:21:31 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 11 Mar 2016 13:21:31 -0500
Subject: Why the US Government has so many data centers
In-Reply-To: <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
Message-ID: <CAL9jLaarySvKH1wVJAc_MnH=mfZfL-iwHjA+G2cbQ8WO9sUS+A@mail.gmail.com>

On Fri, Mar 11, 2016 at 12:21 PM, Roland Dobbins <rdobbins at arbor.net> wrote:
> On 12 Mar 2016, at 0:03, Sean Donelan wrote:
>
>> The U.S. Government has an odd defintion of what is a data center, which
>> ends up with a lot of things no rational person would call a data center.
>
>
> There's also a case to be made that governmental organizations really
> oughtn't to have servers just lying around in random rooms, and that those
> rooms are de facto government data centers, whether those who're responsible
> for said rooms/servers know it or not . . .


because .... at least:
  o safe handling of media is important (did the janitor just walk off
with backup tapes/ disks/etc?)
  o 'a machine under your desk' is not a production operation.
     (if you think it is, please stop, think again and move that
service to conditioned power/cooling/ethernet)

I'm sure there are other reasons, but honestly those 2 are great starters...

From nick at foobar.org  Fri Mar 11 19:30:29 2016
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 11 Mar 2016 19:30:29 +0000
Subject: Why the US Government has so many data centers
In-Reply-To: <CAL9jLaarySvKH1wVJAc_MnH=mfZfL-iwHjA+G2cbQ8WO9sUS+A@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <CAL9jLaarySvKH1wVJAc_MnH=mfZfL-iwHjA+G2cbQ8WO9sUS+A@mail.gmail.com>
Message-ID: <56E31CD5.4090306@foobar.org>

Christopher Morrow wrote:
> because .... at least:
>   o safe handling of media is important (did the janitor just walk off
> with backup tapes/ disks/etc?)
>   o 'a machine under your desk' is not a production operation.
>      (if you think it is, please stop, think again and move that
> service to conditioned power/cooling/ethernet)
> 
> I'm sure there are other reasons, but honestly those 2 are great starters...

The alternative may be:

- issue RFT for hosting / colocation facilities + high speed resilient
connectivity between colo and local network + associated equipment to
make this work, or

- building out enterprise-grade comms room in local office

This can be hard for public sector bodies to do and depending on the
value of the data hosting or the amount of kit that needed to be hosted,
it may also not be easy to justify.

Nick


From owen at delong.com  Fri Mar 11 19:30:18 2016
From: owen at delong.com (Owen DeLong)
Date: Fri, 11 Mar 2016 11:30:18 -0800
Subject: Cogent - Google - HE Fun
In-Reply-To: <CACXVQYApLX9X6wwK6dDXkh78N28_7gDnqkTNFdz1O9GitHXRJA@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <CACXVQYApLX9X6wwK6dDXkh78N28_7gDnqkTNFdz1O9GitHXRJA@mail.gmail.com>
Message-ID: <619917C7-7EB8-46C7-8472-0585295C4AA9@delong.com>


> On Mar 11, 2016, at 04:57 , Dave Bell <me at geordish.org> wrote:
> 
> On 10 March 2016 at 15:55, William Herrin <bill at herrin.us> wrote:
>> It's Cogent's fault because: double-billing. Google should not have to
>> pay Cogent for a service which you have already paid Cogent to provide
>> to you. Cogent's demand is unethical. They intentionally fail to
>> deliver on the basic service expectation you pay them for and refuse
>> to do so unless a third party to your contract also pays them.
>> 
>> Google, by contrast, makes no demand that Cogent pay them even though
>> you are not paying Google for service. They offer "open peering," a
>> free interconnect via many neutral data centers.
> 
> I don't get this. Google are basically a hosting provider. If I set up
> my own website, I would expect to have to pay transit for it. If I ran
> a hosting business I would expect to pay transit. Why are google
> different?

No matter what kind of business I build, I don?t expect to pay transit
unless I am asking you to deliver packets to people who are not already
paying you.

Yes, if I make that request, I may also be paying transit for packets that
go to some or all of the users that are already paying you, but I would
expect in most cases, that is an artifact.

If I have content that your paying customers want and your paying customers
have enough demand for my content that it would fill one or more
interconnection-sized pipes (whatever your standard minimum interconnect
is, be that 1G, 10G, 100G, etc.), then I think it is reasonable to ask
for settlement free peering to reach those customers. If there isn?t
enough demand from your customers to justify that, then there are a few
other possibilities? Exchange points in common and public peering,
I give up on those customers, or, I pay you (or someone else) for transit.

I?m pretty sure in the case of Cogent<->Google the traffic level more than
justifies a reasonable number of PNIs in a diversity of locations.
 
> Its Google's decision to decide not to pay for transit for v6.
> Considering how open they are to peering, and how large their network
> it, it probably makes a lot of sense. If you need to connect to a
> transit provider, you can probably peer with google at the same
> location.

Depends on how you connect to said transit provider, but yeah, you can
either peer with Google yourself, or, you should be able to expect that
anyone you are paying for transit peers with Google as part of providing
you transit service to ?the internet?.

It?s very hard to make a case that ?Internet Access? can be sold if that
doesn?t include access to Google.

> Cogent is in the business of trying to provide transit. I understand
> there are probably good business cases where you may want to set up an
> SFI with someone like google, but at the end of the day that's their
> choice.

Sure, it?s their choice, but in so doing, there?s a valid case to be
made that they are not providing the contracted service to their transit
customers.

I don?t think anyone is saying ?Cogent can?t do this?. I think we are
saying ?Cogent?s customers may want to consider their rights and their
contracts with Cogent in this process.?

> I get the arguments that Cogent are supposed to be supplying a full
> view of the DFZ, but if Joe's Hosting Company refuses to pay anyone
> for transit, surely it is their own fault that their reachability is
> compromised?

Yes and no? How many of the Alexa 10, 50, 100, 500, 1000 are hosted
at Joe?s?

I think those numbers are a bit different from Google and like it or not,
there?s meaning to that.

Owen


From owen at delong.com  Fri Mar 11 19:34:36 2016
From: owen at delong.com (Owen DeLong)
Date: Fri, 11 Mar 2016 11:34:36 -0800
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGUqXWvgKNckGODXwLWo9fZfQSSafzawVhBFOefWqbnHBA@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <Pine.LNX.4.61.1603110731270.6833@soloth.lewis.org>
 <CAP-guGUqXWvgKNckGODXwLWo9fZfQSSafzawVhBFOefWqbnHBA@mail.gmail.com>
Message-ID: <CDB28663-C6A2-41C1-98A5-992D67B20767@delong.com>


> On Mar 11, 2016, at 06:16 , William Herrin <bill at herrin.us> wrote:
> 
> On Fri, Mar 11, 2016 at 7:40 AM, Jon Lewis <jlewis at lewis.org> wrote:
>> On Thu, 10 Mar 2016, William Herrin wrote:
>>> It's Cogent's fault because: double-billing. Google should not have to
>>> pay Cogent for a service which you have already paid Cogent to provide
>>> to you. Cogent's demand is unethical. They intentionally fail to
>>> deliver on the basic service expectation you pay them for and refuse
>>> to do so unless a third party to your contract also pays them.
>> 
>> That's one way of looking at it.
>> 
>> However, which of your transits don't bill for bits exchanged with other
>> customers of theirs...and how are they or you accounting for that traffic?
> 
> Hi Jon,
> 
> As you know, there is a technology limitation in how routing works
> which says that for any given block of addresses you can, absent
> extraordinary measures, have a peering relationship or a transit
> relationship but not both. If both parties choose to have a transit

Not really.

If you have both, then there?s no easy way to guarantee that you get
paid for every piece of transit (though relatively simple localpref
tactics will actually make it likely that you also get paid for
many bits of peering).

> relationship, that excludes a peering relationship for the relevant
> blocks of addresses. And that's OK when _both sides_ choose it.

Your premise is flawed.

> In related news, no ethical conundrum demands defiance of the law of gravity.

True, but gravity is real. Your law of peering vs. transit above is
purely artificial and fails utterly if you don?t accept that an approximation
of which bits fall into which category is ?close enough? for billing
purposes.

I?m not making any value judgments on whether accepting that idea is good
or bad. I know that there are networks that act in various ways on both
sides of this idea.

However, equating it to ?the law of gravity? is rather silly given that it
is 100% mutable if we take the accounting out of the picture.

No amount of monetary policy change can counteract gravity.

Owen


From damien at supremebytes.com  Fri Mar 11 19:50:54 2016
From: damien at supremebytes.com (Damien Burke)
Date: Fri, 11 Mar 2016 19:50:54 +0000
Subject: Cogent - Google - HE Fun
In-Reply-To: <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
Message-ID: <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>

Just received an updated statement from cogent support:

"We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6. 

Once again, apologies for any inconvenience."

And:

"The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."


From sean at donelan.com  Fri Mar 11 20:38:40 2016
From: sean at donelan.com (Sean Donelan)
Date: Fri, 11 Mar 2016 15:38:40 -0500 (EST)
Subject: Why the US Government has so many data centers
In-Reply-To: <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
Message-ID: <alpine.BSF.2.20.1603111535590.47536@cnex.qbaryna.pbz>

On Sat, 12 Mar 2016, Roland Dobbins wrote:
>> The U.S. Government has an odd defintion of what is a data center, which 
>> ends up with a lot of things no rational person would call a data center.
>
> There's also a case to be made that governmental organizations really 
> oughtn't to have servers just lying around in random rooms, and that those 
> rooms are de facto government data centers, whether those who're responsible 
> for said rooms/servers know it or not . . .

If that is the goal, don't call it data center optimization.  That is 
server optimization.

When you say "data center" to an ordinary, average person or reporter; 
they think of big buildings filled with racks of computers.  Not a lonely 
server sitting in a test lab or under someone's desk.


From sean at donelan.com  Fri Mar 11 20:54:47 2016
From: sean at donelan.com (Sean Donelan)
Date: Fri, 11 Mar 2016 15:54:47 -0500 (EST)
Subject: Why the US Government has so many data centers
In-Reply-To: <CAL9jLaarySvKH1wVJAc_MnH=mfZfL-iwHjA+G2cbQ8WO9sUS+A@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <CAL9jLaarySvKH1wVJAc_MnH=mfZfL-iwHjA+G2cbQ8WO9sUS+A@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1603111543580.47588@cnex.qbaryna.pbz>

On Fri, 11 Mar 2016, Christopher Morrow wrote:
>  o 'a machine under your desk' is not a production operation.
>     (if you think it is, please stop, think again and move that
> service to conditioned power/cooling/ethernet)

Even worse, the new OMB data center definition wants says "(whether in a 
production, test, stage, development, or any other environment)".

In the non-government world, you want to keep test, staging and 
development separate from your "production."  So your testing lab
is now a "data center," and you must consolidate your "data centers"
together.

If you are optimizing servers, not data centers, then you probably
want to consolidate your production servers in a data center.  But
there will still be lots of servers not in data centers, like the
server in the parking garage that controls the gates or the server
in the building that controls HVAC.  Its not smart to consolidate your
HVAC servers and your credit card servers, as some companies have
found out.

The U.S. government definition of data center is a bit like defining
a warehouse as any room containing a single ream of paper.  Yes, 
warehouses are used to store reams of paper; but that doesn't make
every place containing a ream of paper a warehouse.


From Steve.Mikulasik at civeo.com  Fri Mar 11 21:07:37 2016
From: Steve.Mikulasik at civeo.com (Steve Mikulasik)
Date: Fri, 11 Mar 2016 21:07:37 +0000
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603111543580.47588@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <CAL9jLaarySvKH1wVJAc_MnH=mfZfL-iwHjA+G2cbQ8WO9sUS+A@mail.gmail.com>
 <alpine.BSF.2.20.1603111543580.47588@cnex.qbaryna.pbz>
Message-ID: <CY1PR07MB22001558980AE67EE948576DFAB50@CY1PR07MB2200.namprd07.prod.outlook.com>

This is a great way to create a mess of rules. Need a server for running an app locally to a site? You need XYZ standards that make no sense for your deploy and increase the cost by 10 times. 

Our server guys always try to set standards, then they run into a deploy where the needs are simple, but the standards make it significantly uneconomical.


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan
Sent: Friday, March 11, 2016 1:55 PM
To: Christopher Morrow <morrowc.lists at gmail.com>
Cc: nanog list <nanog at nanog.org>
Subject: Re: Why the US Government has so many data centers

On Fri, 11 Mar 2016, Christopher Morrow wrote:
>  o 'a machine under your desk' is not a production operation.
>     (if you think it is, please stop, think again and move that 
> service to conditioned power/cooling/ethernet)

Even worse, the new OMB data center definition wants says "(whether in a production, test, stage, development, or any other environment)".

In the non-government world, you want to keep test, staging and development separate from your "production."  So your testing lab is now a "data center," and you must consolidate your "data centers"
together.

If you are optimizing servers, not data centers, then you probably want to consolidate your production servers in a data center.  But there will still be lots of servers not in data centers, like the server in the parking garage that controls the gates or the server in the building that controls HVAC.  Its not smart to consolidate your HVAC servers and your credit card servers, as some companies have found out.

The U.S. government definition of data center is a bit like defining a warehouse as any room containing a single ream of paper.  Yes, warehouses are used to store reams of paper; but that doesn't make every place containing a ream of paper a warehouse.


From surfer at mauigateway.com  Fri Mar 11 21:40:09 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 11 Mar 2016 13:40:09 -0800
Subject: Why the US Government has so many data centers
Message-ID: <20160311134009.5CE0A36E@m0086238.ppops.net>


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan

The U.S. government definition of data center is a bit like defining 
a warehouse as any room containing a single ream of paper.  Yes, 
warehouses are used to store reams of paper; but that doesn't make 
every place containing a ream of paper a warehouse.
----------------------------------------

--- Steve.Mikulasik at civeo.com wrote:

This is a great way to create a mess of rules. Need a server 
for running an app locally to a site? You need XYZ standards 
that make no sense for your deploy and increase the cost by 
10 times. 

Our server guys always try to set standards, then they run 
into a deploy where the needs are simple, but the standards 
make it significantly uneconomical.
---------------------------------------------


Been there, done that, got many t-shirts.  There is no thought
at all to economics.  None.  People that have absolutely no 
experience in networking or computers (read: can barely operate 
M$ computers) make these rules/definitions/processes.  It's not 
even sausage when they're done.  It's post-digested sausage.  
For example, read about the OPM fiasco: 

https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach

I'm one of those 21.5 million people.  Fingerprints, SSN, 
address, etc, etc, etc.


scott

From alter3d at alter3d.ca  Fri Mar 11 22:23:25 2016
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Fri, 11 Mar 2016 17:23:25 -0500
Subject: Why the US Government has so many data centers
In-Reply-To: <20160311134009.5CE0A36E@m0086238.ppops.net>
References: <20160311134009.5CE0A36E@m0086238.ppops.net>
Message-ID: <56E3455D.5080902@alter3d.ca>



On 2016-03-11 04:40 PM, Scott Weeks wrote:
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan
>
> The U.S. government definition of data center is a bit like defining
> a warehouse as any room containing a single ream of paper.  Yes,
> warehouses are used to store reams of paper; but that doesn't make
> every place containing a ream of paper a warehouse.
> ----------------------------------------
>
> --- Steve.Mikulasik at civeo.com wrote:
>
> This is a great way to create a mess of rules. Need a server
> for running an app locally to a site? You need XYZ standards
> that make no sense for your deploy and increase the cost by
> 10 times.
>
> Our server guys always try to set standards, then they run
> into a deploy where the needs are simple, but the standards
> make it significantly uneconomical.
> ---------------------------------------------
>
>
> Been there, done that, got many t-shirts.  There is no thought
> at all to economics.  None.  People that have absolutely no
> experience in networking or computers (read: can barely operate
> M$ computers) make these rules/definitions/processes.  It's not
> even sausage when they're done.  It's post-digested sausage.
> For example, read about the OPM fiasco:
>
> https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach
>
> I'm one of those 21.5 million people.  Fingerprints, SSN,
> address, etc, etc, etc.
>
>
> scott

I disagree.  Government departments are heavily concerned about 
economics.  Specifically, "how can we maintain, or preferably increase, 
our budget in the next fiscal cycle?"   If that means feeding 500 lbs of 
pork to a chihuahua so you can burn up this year's budget, then so be 
it.  Next year you can ask for extra money to put the chihuahua on a 
special, extremely expensive diet while simultaneously asking for more 
pork to enrich its diet.


From surfer at mauigateway.com  Fri Mar 11 22:41:30 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 11 Mar 2016 14:41:30 -0800
Subject: Why the US Government has so many data centers
Message-ID: <20160311144130.5CE0A883@m0086238.ppops.net>



On 2016-03-11 04:40 PM, Scott Weeks wrote:
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean Donelan
>
> The U.S. government definition of data center is a bit like defining
> a warehouse as any room containing a single ream of paper.  Yes,
> warehouses are used to store reams of paper; but that doesn't make
> every place containing a ream of paper a warehouse.
> ----------------------------------------
>
> --- Steve.Mikulasik at civeo.com wrote:
>
> This is a great way to create a mess of rules. Need a server
> for running an app locally to a site? You need XYZ standards
> that make no sense for your deploy and increase the cost by
> 10 times.
>
> Our server guys always try to set standards, then they run
> into a deploy where the needs are simple, but the standards
> make it significantly uneconomical.
> ---------------------------------------------
>
>
> Been there, done that, got many t-shirts.  There is no thought
> at all to economics.  None.  People that have absolutely no
> experience in networking or computers (read: can barely operate
> M$ computers) make these rules/definitions/processes.  It's not
> even sausage when they're done.  It's post-digested sausage.
> For example, read about the OPM fiasco:
>
> https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach
>
> I'm one of those 21.5 million people.  Fingerprints, SSN,
> address, etc, etc, etc.
------------------------------------------------


--- alter3d at alter3d.ca wrote:------------------
From: Peter Kristolaitis <alter3d at alter3d.ca>

I disagree.  Government departments are heavily concerned about 
economics.  Specifically, "how can we maintain, or preferably increase, 
our budget in the next fiscal cycle?"   If that means feeding 500 lbs of 
pork to a chihuahua so you can burn up this year's budget, then so be 
it.  Next year you can ask for extra money to put the chihuahua on a 
special, extremely expensive diet while simultaneously asking for more 
pork to enrich its diet.
------------------------------------------


Ok, put that way you're correct.  It's really disgusting to watch the
waste knowing how hard I work for my money and how badly it's pissed
into the wind.

scott


From randy at psg.com  Sat Mar 12 02:19:17 2016
From: randy at psg.com (Randy Bush)
Date: Sat, 12 Mar 2016 11:19:17 +0900
Subject: AW: Cogent - Google - HE Fun
In-Reply-To: <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
Message-ID: <m2io0s4evu.wl%randy@psg.com>

> Anyone who is multihomed with cogent ipv6 in their mix should shutdown
> their IPv6 bgp session. Let?s see if we can make their graph freefall.

Ettore Bugatti, maker of the finest cars of his day, was once asked why his
cars had less than perfect brakes.  He replied something like, "Any fool can
make a car stop.  It takes a genius to make a car go."

From colton.conor at gmail.com  Sat Mar 12 18:04:23 2016
From: colton.conor at gmail.com (Colton Conor)
Date: Sat, 12 Mar 2016 12:04:23 -0600
Subject: HP HSR Routers
Message-ID: <CAMDdSzMkzE=n=LCk7Qs8E4La3Y_edAMrMpGxeL9BvAEwKY0LCw@mail.gmail.com>

Does anyone deploy HP HSR routers for full BGP routing? Looks like they
have couple of routers that can hold 4 Million IPv4 routes, and do full BGP
routing. I did no even know that HP had routers of this size.

I read this post on Reddit, and it said the following:

I would suggest looking at the HP routing line, in North America for some
reason people over look them (HP's ability to get the message out is not
stellar). The HSR 6602-XG will push 15 Mpps with routing table sizes of
4mil (ipv4) and 2mil (ipv6) there is no additional licensing for any
feature you want to use. With respect to implementation I have always felt
if you understand the protocol who gives a damn about the syntax... The MSR
4060 will handle 36 Mpps with table sizes of 1mil (ipv4) and 1mil (ipv6).
Either solution will be cost effective.

The person I heard about HP from manages a direct peer as a transit AS to
hurricane electric with dual 10G Ethernet with a HSR 6800 (420Mpps) the
throughput and feature set on their product is unreal.

In a municipality's network for peering I purchased an ASR for the main
site prior to learning about the MSR/HSR line and just put in a 4060 for
the secondary and tertiary site they work like a charm. I think the total
cost per 4060 with redundant MPU's / Power Supplies / 4 port Gig T HIMM
card and 5years of support was like $15k (CDN) so like $25 USD... and not
only do they go toe to toe with the QFP in the ASR for performance but I
can terminate ipsec tunnels without shelling out an addition $20k!! or I
can redistribute into MPBGP from my IGP without shelling out an additional
20K for the IP Enterprise liscense!! :D

I would at least check em' out.

Oh last thing the routers support IRF which is the HP spin on RSMLT for
fabric creation (think VSS without the arbitrary limitations on which line
cards will be a/a or a/p (looking at you FWSM and IDSM) so you can
effectively have millisecond convergence across the routers... Also Comware
is modular so the OS is identical across all products, which is kind of
nice because with an ASR you have crap like VASI groups which only exist in
the ASR so ya that was fun....

https://www.reddit.com/r/networking/comments/347e74/costefficient_peering_router/

From swmike at swm.pp.se  Sat Mar 12 18:20:12 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sat, 12 Mar 2016 19:20:12 +0100 (CET)
Subject: HP HSR Routers
In-Reply-To: <CAMDdSzMkzE=n=LCk7Qs8E4La3Y_edAMrMpGxeL9BvAEwKY0LCw@mail.gmail.com>
References: <CAMDdSzMkzE=n=LCk7Qs8E4La3Y_edAMrMpGxeL9BvAEwKY0LCw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1603121918230.31096@uplift.swm.pp.se>

On Sat, 12 Mar 2016, Colton Conor wrote:

> Does anyone deploy HP HSR routers for full BGP routing? Looks like they
> have couple of routers that can hold 4 Million IPv4 routes, and do full BGP
> routing. I did no even know that HP had routers of this size.

Are you sure that's forwarding table size, not routing table size?

There are lots of platforms that will have large RIB but a lot smaller 
FIB.

http://www8.hp.com/h20195/v2/getpdf.aspx/c04111660.pdf?ver=23

"HP 6600 Router Series"

"Routing table size 1000000 entries (IPv4), 300000 entries (IPv6)
Forwarding table size 1000000 entries (IPv4), 100000 entries (IPv6)"

I don't know if there is a typo somewhere, but it shows the difference 
between RIB and FIB.

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

From david.soltero at icann.org  Wed Mar  9 21:06:20 2016
From: david.soltero at icann.org (David Soltero)
Date: Wed, 9 Mar 2016 21:06:20 +0000
Subject: L-Root IPv6 address renumbering
Message-ID: <4AA7E64A-A96E-4E2E-9F13-E3E33315D06D@icann.org>


This is advance notice that there is a scheduled change to the IPv6 addresses in the Root Zone for the L root-server, also known as  L.ROOT-SERVERS.NET, which is administered by the ICANN.

The current IP addresses for the L.ROOT-SERVERS.NET service are:
199.7.83.42
2001:500:3::42

As of March 23, 2016, the new IP addresses for the L.ROOT-SERVERS.NET service will be:
199.7.83.42
2001:500:9f::42

The change will be implemented on the root zone on March 23, 2016 2100UTC,  however the new address is already operational.

We encourage DNS infrastructure operators to update their DNS resolvers root "hints? file.

New hints files will be available at the following URLs once the change has been formally executed on March 23, 2016:

  *   http://www.internic.net/domain/named.root
  *   http://www.internic.net/domain/named.cache

From dsp at fb.com  Thu Mar 10 16:03:39 2016
From: dsp at fb.com (Doug Porter)
Date: Thu, 10 Mar 2016 16:03:39 +0000
Subject: Facebook & Traceroute
In-Reply-To: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
References: <094c01d17a80$625debe0$2719c3a0$@SanDiegoBroadband.com>
Message-ID: <0EF916E814DB5942B1E5360D60B23704D427DA1D@PRN-MBX01-3.TheFacebook.com>

> Why does Facebook spoof the source IP address
> of the hop before this server?  They spoof the
> source IP address that is performing the traceroute.

It's a known bug; apologies.  I've asked again that we rollout the fix.

-- 
dsp

From ganzer at spawar.navy.mil  Fri Mar 11 19:57:29 2016
From: ganzer at spawar.navy.mil (Mark T. Ganzer)
Date: Fri, 11 Mar 2016 11:57:29 -0800
Subject: Why the US Government has so many data centers
In-Reply-To: <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
Message-ID: <56E32329.3020201@spawar.navy.mil>

Note that I an not answering in any sort of "official" capacity....but I 
will instead ask this for your consideration:  Do servers in "test, 
stage, development, or any other environment" really need to have the 
same environmental, power and connectivity requirements that 
"production" servers have?   And should a dev lab containing a couple of 
servers and a few developers really be called a "datacenter"?

-Mark Ganzer
SSC-PAC San Diego Code 82700
Office/Voice mail: 619-553-1186   NOC: 619-553-5881

On 3/11/2016 9:21 AM, Roland Dobbins wrote:
> On 12 Mar 2016, at 0:03, Sean Donelan wrote:
>
>> The U.S. Government has an odd defintion of what is a data center, 
>> which ends up with a lot of things no rational person would call a 
>> data center.
>
> There's also a case to be made that governmental organizations really 
> oughtn't to have servers just lying around in random rooms, and that 
> those rooms are de facto government data centers, whether those who're 
> responsible for said rooms/servers know it or not . . .
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>


From geier at geier.ne.tz  Thu Mar 10 06:38:27 2016
From: geier at geier.ne.tz (Frank Habicht)
Date: Thu, 10 Mar 2016 09:38:27 +0300
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E112E2.5090306@forthnet.gr>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net> <56E112E2.5090306@forthnet.gr>
Message-ID: <56E11663.6090100@geier.ne.tz>

Hi,

On 3/10/2016 9:23 AM, Tassos Chatzithomaoglou wrote:
> Niels Bakker wrote on 10/3/16 02:44:
>> * nanog at nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]:
>>> I'm pretty confident there is no need for a specific MTU consensus and not all IXP participants are obligated to raise their interface MTU if the IXP starts allowing jumbo frames.
>>
>> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too Big messages.  That's why everybody must agree on one MTU.
>>
>>
> Isn't that the case for IXP's current/default MTU?
> If an IXP currently uses 1500, what effect will it have to its customers if it's increased to 9200 but not announced to them?

none.
everyone has agreed on 1500. it is near impossible to get close to
everyone to agree on 9200 (or similar number) and implement it (at the
same time or in a separate VLAN) (Nick argues, and i see the problem).
The agreement and actions of the (various) operators of L3 devices
connected at the IXP is what matters and seems not trivial.
They are not under one control.

Frank

From kurtis at kurtis.pp.se  Thu Mar 10 09:33:00 2016
From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist)
Date: Thu, 10 Mar 2016 09:33:00 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <alpine.DEB.2.02.1603092212580.31096@uplift.swm.pp.se>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <20160309143419.GG1163@22.rev.meerval.net>
 <CAAeewD9dzFBZ=+qXwoVDm6Z36A8Wj_mWYgWn6MeQ5nH3nUEOYw@mail.gmail.com>
 <56E06805.9010800@foobar.org>
 <CAAeewD8oNzWL5hoBQYTyZPWgeLHprd4jyE1ghy6sWs_3dTcrVQ@mail.gmail.com>
 <56E06AB7.7020307@foobar.org>
 <CAAeewD9ANpe46J8a=QQ6TMJ3JM=ceKE3ajknv5TWs1rqCm4i=Q@mail.gmail.com>
 <8F7D7E2C-B162-4750-BA90-EFFAD0C0BEB1@foobar.org>
 <CAAeewD8vJ1gOAbBERgNTZSxBuAjBrNX+VL+FvQBZPtew0TdvfQ@mail.gmail.com>
 <56E07DAE.5040008@foobar.org>
 <CAAeewD8G8XgdWGY8aGxwTR4Xk8UvBzm_mhHSWbhsF0tuQL6AzA@mail.gmail.com>
 <56E08E0B.4040607@foobar.org>
 <alpine.DEB.2.02.1603092212580.31096@uplift.swm.pp.se>
Message-ID: <C8E13700-6FAB-4635-91A9-DE02A24B064C@kurtis.pp.se>


> On 9 Mar 2016, at 21:17, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 
> On Wed, 9 Mar 2016, Nick Hilliard wrote:
> 
>> Many IXPs have either looked at or attempted to build jumbo peering lans.  You can see how well they worked out by looking at the number of successful deployments.  The reason for this tiny number isn't due to lack of effort on the part of the ixp operators.
> 
> I believe all IXP operators should offer higher MTU vlans, so that the ISPs who are interested can use them. If individual ISPs are not interested, then they don't have to use it. It's available if they gain interest.

In my experience many (most)  IXP members don?t want multiple VLANs as default as that drives up operational complexity. I am not saying they are right, I am just saying that is reality.

> The whole point of an IX is to be a market place where interested parties can talk to each other. The IXP should not limit (to reasonable extent) what services the ISPs can run across the infrastructure. If two ISPs need higher than 1500 MTU between them, then forcing them to connect outside of the IXP L2 infrastructure doesn't make any sense to me, when it's fairly easy for the IXP to offer this service.

Most IXPs offers private VLANs and I assume these can support any MTU size you want.

Best Regards,

- kurtis -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160310/0b18f9ba/attachment.pgp>

From m.pels at tech.leaseweb.com  Thu Mar 10 14:15:55 2016
From: m.pels at tech.leaseweb.com (Martin Pels)
Date: Thu, 10 Mar 2016 15:15:55 +0100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E112E2.5090306@forthnet.gr>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
 <56E112E2.5090306@forthnet.gr>
Message-ID: <20160310151555.65178a3d@pels-Latitude-E5450>

?On Thu, 10 Mar 2016 08:23:30 +0200
Tassos Chatzithomaoglou <achatz at forthnet.gr> wrote:

> Niels Bakker wrote on 10/3/16 02:44:
> > * nanog at nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59
> > CET]:
> >> I'm pretty confident there is no need for a specific MTU consensus
> >> and not all IXP participants are obligated to raise their
> >> interface MTU if the IXP starts allowing jumbo frames.
> >
> > You're wrong here.  The IXP switch platform cannot send ICMP Packet
> > Too Big messages.  That's why everybody must agree on one MTU.
> >
> >
> Isn't that the case for IXP's current/default MTU?
> If an IXP currently uses 1500, what effect will it have to its
> customers if it's increased to 9200 but not announced to them?

None. Until someone actually tries to make use of the higher MTU. Then
things start breaking.

Let's say I'm a customer at this IXP. I have 100 peers. I have one peer
that likes large MTUs, so I set my L3 MTU to 9000 (or whatever I agree
with this peer). Now I have broken connectivity towards my 99 other
peers who are all still at 1500.

So today you need a separate VLAN for Jumbo's, which some IXPs have. On
this VLAN you will only find the peers that actually care about
Jumboframes. The majority of IXP participants don't bother to connect
to this VLAN for varying reasons. If the number of interested parties
is too low, IXPs may well decide it is not worth the investment of time
and resources to set this up, implement monitoring for it, deal with
customers messing up their configs, etc.

In order for Jumboframes to be successful on IXPs _on a large scale_
the technology has to change. There needs to be a mechanism to negotiate
MTU for each L2 neighbor individually. Something like
draft-van-beijnum-multi-mtu-03, which was mentioned before in this
thread. With this in place individual sets of peers could safely use
different MTUs on the same VLAN, and IXPs would have a migration path
towards supporting larger framesizes.

--

Kind regards,

Martin Pels
Network Engineer
LeaseWeb Technologies B.V.

T: +31 20 316 0232
M: 
E: m.pels at tech.leaseweb.com
W: http://www.leaseweb.com

Luttenbergweg 8, 1101 EC?Amsterdam,?Netherlands



From nwarren at barryelectric.com  Wed Mar  9 18:59:31 2016
From: nwarren at barryelectric.com (Nicholas Warren)
Date: Wed, 9 Mar 2016 18:59:31 +0000
Subject: SFP Cost Variation
Message-ID: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>

Quick question for the experts.

Why when looking at SFPs, some sites list them as $800 when the same part
number can be found on places like amazon for $30-$40. What is the
difference in them? Why would I buy them from a place like CDW with what
appears to be a 2,000% markup.

https://www.cdw.com/shop/products/Brocade-SFP-mini-GBIC-transceiver-module-G
igabit-Ethernet/1411743.aspx

http://www.amazon.com/gp/product/B0076Q1CTY

Thanks,
Nich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4845 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160309/50dc699e/attachment.bin>

From liam at fedney.org  Wed Mar  9 18:02:40 2016
From: liam at fedney.org (L Sean Kennedy)
Date: Wed, 9 Mar 2016 13:02:40 -0500
Subject: [NANOG-announce] NANOG 67 Chicago,
 IL - Call for Presentations is Open!
Message-ID: <CABDdXoz4p=_i_QaNDdeieOGZmn6hKfqThBinPU54P2Qc5MypBQ@mail.gmail.com>

NANOG Community,

The NANOG Program Committee is excited to announce that we are accepting
proposals for all sessions at NANOG 67 in Chicago, IL on June 13-15, 2016.
I have included some key points from the Call for Presentations and the
complete text is now available on the NANOG website:

https://www.nanog.org/meetings/nanog67/callforpresentations

Early bird registration is open for NANOG 67 and hotel reservations in the
NANOG block are available for those interested in making advance travel
plans.  We look forward to seeing all of you in Chicago and are eager to
get to work on building a strong program for the upcoming meeting.

https://www.nanog.org/meetings/nanog67/home

Sincerely,
 Sean
NANOG Program Committee


NANOG 67 Call for Presentations

The North American Network Operators' Group (NANOG) will hold its 67th
conference in Chicago, Illinois on June 13-15, 2016.  EdgeConneX will be
the Local Host at NANOG 67.

The NANOG Program Committee seeks proposals for presentations, panels,
tutorials, and tracks sessions for the NANOG 67 program. We welcome
suggestions of keynote speakers or topic ideas. Presentations may cover
current technologies already deployed or soon-to-be deployed in the
Internet. Vendors are welcome to submit talks which cover relevant
technologies and capabilities, but presentations must not be promotional or
discuss proprietary solutions. NANOG 67 submissions can be entered on the NANOG
Program Committee Site <https://pc.nanog.org/>.

How To Submit

The primary speaker, moderator, or author should submit a presentation
proposal and an abstract on the Program Committee Site
<https://pc.nanog.org/>.  Please upload draft slides as soon as possible so
the Program Committee can understand the intended structure and level of
detail covered by the talk.  Draft slides are not required for a proposal
to be initiated,  but they are usually expected before the Program
Committee can definitively accept a submission.  The following information
should be included in the proposal:

   -

   Author's name(s)
   -

   Professional or Educational Affiliation
   -

   A preferred contact email address
   -

   A preferred phone number for contact
   -

   Submission category (General Session, Panel, Tutorial, or Track)
   -

   Presentation Title
   -

   Abstract
   -

   Slides (attachment or URL), in PowerPoint (preferred) or PDF format

Timeline for submission and proposal review

   -

   Submitter enters Abstract (and draft slides if possible) in Program
   Committee Site <https://pc.nanog.org/>.
   -

      Any time following Call for Presentations and before deadline for
      Abstracts
      -

   PC performs initial review and assigns a ?Shepherd? to help develop the
   submission.
   -

      Within 2-3 weeks
      -

   Submitter develops draft slides of talk
   -

      Please submit initial draft slides early
      -

      Panels and Track submissions should provide topic list and
      intended/confirmed participants
      -

   PC reviews slides and continues to work with Submitter as needed to
   develop topic
   -

      Draft presentation slides should be submitted prior to published
      deadline for slides
      -

   PC accepts or declines submission
   -

   Agenda assembled and posted
   -

   Submitters notified


If you think you have an interesting topic but want feedback or suggestions
for developing an idea into a presentation, please email the Program
Committee <nanogpc at nanog.org>, and a representative of the Program
Committee will respond. Otherwise, submit your talk, keynote, track, or
panel proposal to the Program Committee Site <https://pc.nanog.org/>
without delay!  We look forward to reviewing your submission.

Key Dates For NANOG 67

Event/Deadline

Date

Registration for NANOG 67 Opens

Monday, 3/7/2016

CFP Opens for NANOG 67

Tuesday, 3/8/2016

CFP Deadline #1: Presentation Abstracts Due

Monday, 4/4/2016

CFP Deadline #2: Presentation Slides Due

Friday, 4/29/2016

CFP Topic List and NANOG Highlights Page

Monday, 5/2/2016

Speaker FINAL presentations to PC Tool <https://pc.nanog.org/>

Monday, 5/30/2016

On-site Registration

Sunday, 6/12/2016

Lightning Talk Submissions Open (Abstracts Only)

Sunday, 6/12/2016

Further Presentation Guidelines can be found under "Present at a NANOG"
<https://www.nanog.org/meetings/presentation> and some general advice is
available in Tips on Giving a Talk
<https://www.nanog.org/meetings/presentation/tips>.

The NANOG Program Committee seeks proposals for presentations, panels,
tutorial sessions, and tracks in all areas of network operations, such as:


   -

   Network Connectivity, Interconnection, and Architecture
   -

   Network Management and Configuration including Automation
   -

   Network Performance, Measurement, and Telemetry
   -

   Data Center and Physical Plant including Cooling and Power Efficiency
   -

   Network Research
   -

   Internet Governance
   -

   Routing and Switching Protocols
   -

   Network Data and Control Plane Security
   -

   Optical and Transmission Technologies
   -

   Wireless Networks
   -

   DNS, Transport, and Applications
   -

   Network Operations and Engineering Professional Experiences

Submissions are welcomed by and for network operators of all sizes.
Presentations about difficult problems (and interesting solutions) that you
encounter in the course of your job are encouraged.

The NANOG registration fee is waived for:

   -

   General Session presentations: the conference registration fee will be
   waived for a maximum of one speaker.
   -

   General Session panels: conference registration fees will be waived for
   one panel moderator and all panelists.
   -

   Tracks: conference registration fees will be waived for one moderator.
   -

   Tutorials: conference registration fees will be waived for one
   instructor.
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

From mm at 42com.com  Wed Mar  9 13:26:15 2016
From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=)
Date: Wed, 9 Mar 2016 14:26:15 +0100
Subject: mrtg alternative
In-Reply-To: <56E01EB1.1040801@pubnix.net>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <56E01EB1.1040801@pubnix.net>
Message-ID: <56E02477.2090408@42com.com>

Hi,

collectd has the features you mentioned (select/deselect , zoom...) and 
it is, quote: "built to scale".


BR

Max M.

On 09.03.2016 14:01, Alain Hebert wrote:
>      Hi,
>
>      Cacti works... Biggest case I know, ~180 devices.  A few issues with
> THold plugin but nothing that can't be fixed.
>
>      And they are working on a new release (available thru github) which
> include most of the useful plugins.
>
> -----
> Alain Hebert                                ahebert at pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443
>
> On 02/27/16 16:12, Rafael Ganascim wrote:
>> I like cacti:
>>
>> http://www.cacti.net
>>
>>
>>
>> 2016-02-26 20:18 GMT-03:00 Baldur Norddahl <baldur.norddahl at gmail.com>:
>>
>>> Hi
>>>
>>> I am currently using MRTG and RRD to make traffic graphs. I am searching
>>> for more modern alternatives that allows the user to dynamically zoom and
>>> scroll the timeline.
>>>
>>> Bonus points if the user can customize the graphs directly in the
>>> webbrowse. For example he might be able to add or remove individual peers
>>> from the graph by simply clicking a checkbox.
>>>
>>> What is the 2016 tool for this?
>>>
>>> Regards,
>>>
>>> Baldur
>>>


From nanog-amuse at foofus.com  Fri Mar 11 23:44:49 2016
From: nanog-amuse at foofus.com (amuse)
Date: Fri, 11 Mar 2016 15:44:49 -0800
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
Message-ID: <CAH9Hpnz9U_Tqeq3ZjkyhM9bumiX7ZD7+SWUSA3_Es5ow2F3PCQ@mail.gmail.com>

I can confirm this. I was working at NASA when the last "data call" was put
out.  We had a room with a flight simulator in it, powered by an SGI
Onyx2.  The conversation with the auditor went like this:

Auditor *points at Onyx2*  "Is that machine shared?"
Me:  "Well yeah, the whole group uses it to..."
Auditor: *aside, to colleague* "OK, mark this room down too."

And our flight simulator lab became a data center.



On Fri, Mar 11, 2016 at 9:03 AM, Sean Donelan <sean at donelan.com> wrote:

> If you've wondered why the U.S. Government has so many data centers, ok I
> know no one has ever asked.
>
> The U.S. Government has an odd defintion of what is a data center, which
> ends up with a lot of things no rational person would call a data center.
>
> If you call every room with even one server a "data center," you'll end up
> with tens of thousands of rooms now data centers.  With this defintiion, I
> probably have two data centers in my home.  Its important because
> Inspectors General auditors will go around and count things, because that's
> what they do, and write reports about insane numbers of data centers.
>
>
> https://datacenters.cio.gov/optimization/
>
> "For the purposes of this memorandum, rooms with at least one server,
> providing services (whether in a production, test, stage, development, or
> any other environment), are considered data centers. However, rooms
> containing only routing equipment, switches, security devices (such as
> firewalls), or other telecommunications components shall not be considered
> data centers."
>

From h-kaneko at dr.jp.nec.com  Mon Mar  7 04:01:09 2016
From: h-kaneko at dr.jp.nec.com (Hiroya Kaneko)
Date: Mon, 7 Mar 2016 04:01:09 +0000
Subject: JANOG38 Meeting Call for Presentations
Message-ID: <DC46640E18378943B889470D0F6F018F8121A755@BPXM05GP.gisp.nec.co.jp>

Hello,

JANOG38 Meeting will take place on 6-8 July 2016 in OKINAWA, Japan.


JANOG is making a call for presentations until 15 April 2016.
Our meetings are in Japanese, but we have had several non-Japanese speakers who made presentations in the past.

We are looking forward to your proposals for presentations.


Shishio Tsuchiya,Hiroya Kaneko
JANOG38 Programme Committee Co-Chairs


----------------------------------------------------------------------
** JANOG38 MEETING
----------------------------------------------------------------------

 - Host    : OKIT Corporation 
 - Date    : 6 July., 2016 - 8 July., 2016
 - Venue   : TBD (Naha, Okinawa)
 - Fees    : Conference(6-8 July): Free
             Banquet(in the evening on 7th): TBD
----------------------------------------------------------------------
** HOW TO SUBMIT PRESENTATIONS
----------------------------------------------------------------------

If you are interested to give a presentation, submissions are welcome via e-mail at:"meeting-38[at]janog.gr.jp" with the following information.

 1. Speaker's name(s)
 2. Speaker's organization(s)
 3. Preferred contact email address
 4. Submission category (General Session or Panel Session)
    * If your choice is panel, please tell us the number of speakers  5. Presentation title  6. Abstract  7. Desired presentation time and discussion time  8. Slides (attachment or URL), in PowerPoint or PDF format.

Our Meetings are in Japanese, so non-Japanese speakers usually arrange an informal interpreter.
If you are interested in making a presentation at JANOG but cannot arrange an interpreter by yourself, you could consult with us at:
"meeting-38[at]janog.gr.jp". Although we cannot guarantee, we may be able to help you on volunteer basis.
Let us know if you have any questions : meeting-38[at]janog.gr.jp


----------------------------------------------------------------------
** THE KEY DATE FOR JANOG38 SUBMISSIONS
----------------------------------------------------------------------

CFP Deadline : 15 April 23:59 JST
The Program Committee will notify you after 25th April about your submission.


----------------------------------------------------------------------
** VISA
----------------------------------------------------------------------

Foreign visitor entering Japan must have a passport which has valid period during you stay in Japan. Passport holders from some countries are required to have a visa to visit Japan before they depart toward Japan. Many are exempt from this requirement and can get their visa on entry to Japan. Please determine whether you are exempt from the visa requirement.

Please refer to the official website from Ministry of Foreign Affairs of Japan or any other appropriate website to get more information about Visa application. Ministry of Foreign Affairs of Japan - Guide to Japanese Visas http://www.mofa.go.jp/j_info/visit/visa/index.html

List of Countries and Regions for Visa Exemptions http://www.mofa.go.jp/j_info/visit/visa/short/novisa.html

Please note that JANOG can not assist you with your visa application.
If you have any questions about the meeting, please feel free to contact meeting-38[at]janog.gr.jp.


----------------------------------------------------------------------
** ABOUT JANOG
----------------------------------------------------------------------

JANOG webpage in English is available at: http://www.janog.gr.jp/en/

----------------------------------------------------------------------

*******************************************************
Hiroya Kaneko
NEC Cloud System Research Laboratories
1753, Shimonumabe, Nakahara-ku, Kawasaki
Kanagawa 211-8666, Japan
TEL +8150-3381-7597
Mail: h-kaneko at dr.jp.nec.com


From nicovpp59 at gmail.com  Mon Mar  7 15:55:22 2016
From: nicovpp59 at gmail.com (Nicolas V)
Date: Mon, 7 Mar 2016 16:55:22 +0100
Subject: Cisco Fabricpath
Message-ID: <CAJDSeq2BYhgBkSMA2uiynaLWFWt_RQ9aqyp5=pnjExSWthA_aw@mail.gmail.com>

Hello,

Does anyone already played with cisco fabricpath feature ? I want to use it
on my nexus 5548

Is it working as easy as it seems ? No bugs / particular nx-os version... ?

Thanks !
Nicolas

From mark at hostvirtual.com  Tue Mar  8 17:02:40 2016
From: mark at hostvirtual.com (Mark Mahle)
Date: Tue, 8 Mar 2016 17:02:40 +0000 (GMT+00:00)
Subject: remote serial console (IP to Serial)
In-Reply-To: <F14B2049-39CC-4815-81F2-5167E8A5F15A@beckman.org>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
 <CAKuzA1HUNMip0T3srdP0RhMtGJaurtb2UbxPOQ4doj_NvLscEA@mail.gmail.com>
 <3D1C55A4-2E76-4693-96E8-AE28E9D76835@delong.com>
 <F14B2049-39CC-4815-81F2-5167E8A5F15A@beckman.org>
Message-ID: <1712568304.17851.1457456560056.JavaMail.zimbra@vr.org>

http://www.opengear.com has never let us down with respect to any footprint/device/connection/etc options.

Sure, you're paying a bit -- but you know the old adage..

Mark

----- Original Message -----
From: "Mel Beckman" <mel at beckman.org>
To: "owen" <owen at delong.com>
Cc: "North American Network Operators' Group" <nanog at nanog.org>
Sent: Tuesday, March 8, 2016 8:51:54 AM
Subject: Re: remote serial console (IP to Serial)

Adafruit.com sells a USB to serial converter for $10 that works great (https://www.adafruit.com/product/954). Plus you can operate multiple serial ports this way. 

 -mel beckman

> On Mar 8, 2016, at 8:45 AM, Owen DeLong <owen at delong.com> wrote:
> 
> Serial port on the PI is TTL, so you?ll need some level shifters and/or
> ideally some opto-isolators or buffers to do a proper implementation.
> 
> Owen
> 
>> On Mar 8, 2016, at 08:32 , greg whynott <greg.whynott at gmail.com> wrote:
>> 
>> Thanks to all who responded to me,  quite the flood of suggestions and
>> options.
>> 
>> Found a lot of 20 Digi CM32's on ebay for 35 dollars each,  overkill but
>> can't beat the price,  going to look into those to make sure they are still
>> able to get OS updates.  There will be no firewall in front of this device
>> so it should have one itself.
>> 
>> I like the raspberry pi idea...  Would ensure perpetual security updates
>> with the OS running on it,  whereas I'm sure some of the vendors of
>> commercial console products EOL support at some point.  The fact it runs
>> linux is inviting as we can add it to our monitoring systems.
>> 
>> have a great day,
>> greg
>> 
>> 
>> 
>> On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow <morrowc.lists at gmail.com
>>> wrote:
>> 
>>> for singular serial .. there are many, do you want something that's
>>> "appliance" or are you willing to deploy 18 raspnberry-pi-like
>>> thingies?
>>> 
>>> On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
>>> wrote:
>>>> Recently I have taking over the responsibility of managing about 18
>>> remote
>>>> routers and firewalls.   None of these have a console port for 'out of
>>>> band' access accessible today.
>>>> 
>>>> Most sites has available IPs between the ISP and us (typically a /29) or
>>> a
>>>> backup DSL connection available for use.     I'd like to purchase a IP to
>>>> Serial port device I can use for each location in the event I lock myself
>>>> out.   The requirement would be an Ethernet port,  a serial port,  and
>>> SSH.
>>>> 
>>>> 
>>>> Anyone have any recommendations on something like this?
>>>> 
>>>> thanks much,
>>>> greg
>

From joe at nethead.com  Tue Mar  8 16:16:51 2016
From: joe at nethead.com (Joe Hamelin)
Date: Tue, 8 Mar 2016 08:16:51 -0800
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAL9jLaYWpSr=y=7mXBfLK_D9rS4uVY41S=JP2N_C1j+pXf9AMQ@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAL9jLaZL1DspRy=k4Su1dnc8LfoKpesj3H+pSypA9yh6OLWk5Q@mail.gmail.com>
 <CAL9jLaYWpSr=y=7mXBfLK_D9rS4uVY41S=JP2N_C1j+pXf9AMQ@mail.gmail.com>
Message-ID: <CAO0-hXaqyOeTpHDNirOsrMczTnyhFMiWqG1siO8H48LVD-49qQ@mail.gmail.com>

This little guy has proven handy for me.
http://www.amazon.com/iPocket232-RS232-to-Ethernet-Converter/dp/B00K309TKY

--
Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474

On Tue, Mar 8, 2016 at 7:35 AM, Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> also, serial? or usb? (see previous cisco usb console port discussion)
>
> On Tue, Mar 8, 2016 at 10:33 AM, Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
> > for singular serial .. there are many, do you want something that's
> > "appliance" or are you willing to deploy 18 raspnberry-pi-like
> > thingies?
> >
> > On Tue, Mar 8, 2016 at 10:30 AM, greg whynott <greg.whynott at gmail.com>
> wrote:
> >> Recently I have taking over the responsibility of managing about 18
> remote
> >> routers and firewalls.   None of these have a console port for 'out of
> >> band' access accessible today.
> >>
> >> Most sites has available IPs between the ISP and us (typically a /29)
> or a
> >> backup DSL connection available for use.     I'd like to purchase a IP
> to
> >> Serial port device I can use for each location in the event I lock
> myself
> >> out.   The requirement would be an Ethernet port,  a serial port,  and
> SSH.
> >>
> >>
> >> Anyone have any recommendations on something like this?
> >>
> >> thanks much,
> >> greg
>

From nanog at wayne47.com  Wed Mar  9 18:00:37 2016
From: nanog at wayne47.com (Michael Wayne)
Date: Wed, 9 Mar 2016 13:00:37 -0500
Subject: remote serial console (IP to Serial)
In-Reply-To: <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
 <56DF2209.5050607@apolix.co.za>
 <CAPcb_GL2OD-zxpdHyChqu9ZRNyTiYsTxaynnMpV0LwMU34AyeQ@mail.gmail.com>
 <20160308192122.GA24295@bamboo.slabnet.com>
 <CA+E3k9280LFQ7N7K450zyVM-dS18bXkHBc56UPPcB0BB9QJ=Pg@mail.gmail.com>
Message-ID: <20160309180037.GM29268@manor.msen.com>

On Wed, Mar 09, 2016 at 06:40:54AM -0600, Andrew Latham wrote:
> +1 on the Lantronix Spider as it is an awesome tool but Lantronix make
> devices for very small rollouts also,
> http://www.lantronix.com/products/eds1100-eds2100/#tab-features might be

I mentioned this to the OP but did not see it mentioned here:

That Lantronix above is $214 for one serial port.  Money sensitive
people might consider an EdgeRouter Lite (used only to get ssh and
provide firewalling) coupled with a used Portmaster PM25 off Ebay
for under $200 (total) for 25 serial ports.

From yardiel at gmail.com  Sat Mar 12 19:11:57 2016
From: yardiel at gmail.com (Yardiel Fuentes)
Date: Sat, 12 Mar 2016 14:11:57 -0500
Subject: DataCenter color-coding cabling schema
Message-ID: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>

Hello Nanog-ers,

Have any of you had the option or; conversely, do you know of ?best
practices" or ?common standards?,  to color code physical cabling for your
connections in DataCenters for Base-T and FX connections? If so, Could you
share  any ttype of color-coding schema you are aware of ??. Yes, this is
actually considering paying for customized color-coded cabling in a Data
Center...

Mr. Google did not really provide me with relevant answers on the above?
beyond the typical (Orange is for MMF, yellow for SMF, etc)?

Any reasons for or against it welcome too...

-- 
Yardiel Fuentes

From josh at kyneticwifi.com  Sat Mar 12 19:17:58 2016
From: josh at kyneticwifi.com (Josh Reynolds)
Date: Sat, 12 Mar 2016 13:17:58 -0600
Subject: SFP Cost Variation
In-Reply-To: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
References: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
Message-ID: <CAC6=tfZDyd9Qav4NW0Oa_neW2OSZqBsEtwgL1FxTET=V1fV9Gg@mail.gmail.com>

http://packetpushers.net/overpriced-optics-by-oems/
On Mar 12, 2016 1:16 PM, "Nicholas Warren" <nwarren at barryelectric.com>
wrote:

> Quick question for the experts.
>
> Why when looking at SFPs, some sites list them as $800 when the same part
> number can be found on places like amazon for $30-$40. What is the
> difference in them? Why would I buy them from a place like CDW with what
> appears to be a 2,000% markup.
>
>
> https://www.cdw.com/shop/products/Brocade-SFP-mini-GBIC-transceiver-module-G
> igabit-Ethernet/1411743.aspx
>
> http://www.amazon.com/gp/product/B0076Q1CTY
>
> Thanks,
> Nich
>

From bill at herrin.us  Sat Mar 12 19:30:09 2016
From: bill at herrin.us (William Herrin)
Date: Sat, 12 Mar 2016 14:30:09 -0500
Subject: HP HSR Routers
In-Reply-To: <CAMDdSzMkzE=n=LCk7Qs8E4La3Y_edAMrMpGxeL9BvAEwKY0LCw@mail.gmail.com>
References: <CAMDdSzMkzE=n=LCk7Qs8E4La3Y_edAMrMpGxeL9BvAEwKY0LCw@mail.gmail.com>
Message-ID: <CAP-guGWYQae3OtQgOQM3gx9gmvCZ2eS1hFqLoQC=3boi6O62Ug@mail.gmail.com>

On Sat, Mar 12, 2016 at 1:04 PM, Colton Conor <colton.conor at gmail.com> wrote:
> I would suggest looking at the HP routing line, in North America for some
> reason people over look them (HP's ability to get the message out is not
> stellar). The HSR 6602-XG will push 15 Mpps with routing table sizes of
> 4mil (ipv4) and 2mil (ipv6) there is no additional licensing for any
> feature you want to use. With respect to implementation I have always felt
> if you understand the protocol who gives a damn about the syntax... The MSR
> 4060 will handle 36 Mpps with table sizes of 1mil (ipv4) and 1mil (ipv6).
> Either solution will be cost effective.

Hi Colton,

My bet is that there's no TCAM. That or they're being cagey about
their hardware architecture since I can't find a single document about
the router that even mentions TCAM. Instead I'd bet they're doing
software routing (radix tree) spread over "32 hardware threads" and as
long as the bulk of your destinations are in small enough parts of the
tree to fit cleanly in to the processor caches you'll get "up to 15
Mpps".

http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=c04111430&doctype=quickspecs&doclang=EN_US&searchquery=&cc=us&lc=en

If I'm right (I'm making guesses after all) then you should compare
HP's offering with software-based routers from other vendors rather
than comparing against routers which have a hardware fast path.

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  Sat Mar 12 19:35:04 2016
From: edward.dore at freethought-internet.co.uk (Edward Dore)
Date: Sat, 12 Mar 2016 19:35:04 +0000
Subject: SFP Cost Variation
In-Reply-To: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
References: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
Message-ID: <319B0DED-F2AB-4040-A45C-6CA9B5E91422@freethought-internet.co.uk>


> On 9 Mar 2016, at 18:59, Nicholas Warren <nwarren at barryelectric.com> wrote:
> 
> Quick question for the experts.
> 
> Why when looking at SFPs, some sites list them as $800 when the same part
> number can be found on places like amazon for $30-$40. What is the
> difference in them? Why would I buy them from a place like CDW with what
> appears to be a 2,000% markup.
> 
> https://www.cdw.com/shop/products/Brocade-SFP-mini-GBIC-transceiver-module-G
> igabit-Ethernet/1411743.aspx
> 
> http://www.amazon.com/gp/product/B0076Q1CTY
> 
> Thanks,
> Nich

The Amazon link almost certainly isn't the exact same part - it's more than likely a "compatible" module from a third party which has been coded to identify itself in the same way as the official part.

But yes, "official" optics are generally extremely expensive and third party ones are much, much cheaper (LightReading published an article many years ago reporting that at the time 25% of Cisco's profits were coming from the transceivers that they were selling as a huge markup!). You can get compatible transceivers for lots of popular vendors from the likes of Fiberstore, flexOptix and Solid Optics.

It's worth noting that the likes of Cisco, Juniper, Brocade etc. don't make the transceivers that they sell at these huge markups either - they just buy them from the likes of Finsar and code them with their own part numbers and guarantee them as compatible.

Depending on the vendor, product and software version, you may find that third party transceivers are disabled, have reduced functionality such as no DOM/DDM or generate warnings about being unsupported. This is why you can buy third party optics that are coded to identify themselves as legitimate parts.

Edward Dore
Freethought Internet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160312/87666322/attachment.pgp>

From jk at ip-clear.de  Sat Mar 12 19:38:42 2016
From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost)
Date: Sat, 12 Mar 2016 20:38:42 +0100
Subject: SFP Cost Variation
In-Reply-To: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
References: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
Message-ID: <D1A73034-0A1A-4176-9F52-9F32228FF88A@ip-clear.de>

Its all about support under warranty.

CDW is selling the original Brocade SFP. The amazon links only shows a 
compatible one. In most cases it will work, but if that tiny metal piece 
will break your freshly installed 20-x2 linecard, Brocade may not 
replace it. Also some of the cheaper optics may not support monitoring 
or diagnostic options.

You can also check the second market for an used original optic, if you 
want to save some budget.

J?rg

On 9 Mar 2016, at 19:59, Nicholas Warren wrote:

> Quick question for the experts.
>
> Why when looking at SFPs, some sites list them as $800 when the same 
> part
> number can be found on places like amazon for $30-$40. What is the
> difference in them? Why would I buy them from a place like CDW with 
> what
> appears to be a 2,000% markup.
>
> https://www.cdw.com/shop/products/Brocade-SFP-mini-GBIC-transceiver-module-G
> igabit-Ethernet/1411743.aspx
>
> http://www.amazon.com/gp/product/B0076Q1CTY
>
> Thanks,
> Nich

From colton.conor at gmail.com  Sat Mar 12 19:48:07 2016
From: colton.conor at gmail.com (Colton Conor)
Date: Sat, 12 Mar 2016 13:48:07 -0600
Subject: HP HSR Routers
In-Reply-To: <alpine.DEB.2.02.1603121918230.31096@uplift.swm.pp.se>
References: <CAMDdSzMkzE=n=LCk7Qs8E4La3Y_edAMrMpGxeL9BvAEwKY0LCw@mail.gmail.com>
 <alpine.DEB.2.02.1603121918230.31096@uplift.swm.pp.se>
Message-ID: <CAMDdSzNd4_wBMDZqeWBNiu_K1BKa6z2rV967yFzbfCQu8RcG2g@mail.gmail.com>

Its is for the routing table. Check out this datasheet:

http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=4AA4-5672ENW&doctype=data%20sheet&doclang=EN_US&searchquery=&cc=us&lc=en
Page 7

Performance Throughput up to 120 million pps up to 240 million pps up to
420 million pps Routing table size 4000000 entries (IPv4), 2000000 entries
(IPv6) 4000000 entries (IPv4), 2000000 entries (IPv6) 4000000 entries
(IPv4), 2000000 entries (IPv6) Forwarding table size 1000000 entries
(IPv4), 1000000 entries (IPv6) 1000000 entries (IPv4), 1000000 entries
(IPv6) 1000000 entries (IPv4), 1000000 entries (IPv6) Backplane bandwidth
1024 Gb/s 1024 Gb/s 2048 Gb/s



On Sat, Mar 12, 2016 at 12:20 PM, Mikael Abrahamsson <swmike at swm.pp.se>
wrote:

> On Sat, 12 Mar 2016, Colton Conor wrote:
>
> Does anyone deploy HP HSR routers for full BGP routing? Looks like they
>> have couple of routers that can hold 4 Million IPv4 routes, and do full
>> BGP
>> routing. I did no even know that HP had routers of this size.
>>
>
> Are you sure that's forwarding table size, not routing table size?
>
> There are lots of platforms that will have large RIB but a lot smaller FIB.
>
> http://www8.hp.com/h20195/v2/getpdf.aspx/c04111660.pdf?ver=23
>
> "HP 6600 Router Series"
>
> "Routing table size 1000000 entries (IPv4), 300000 entries (IPv6)
> Forwarding table size 1000000 entries (IPv4), 100000 entries (IPv6)"
>
> I don't know if there is a typo somewhere, but it shows the difference
> between RIB and FIB.
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
>

From george.herbert at gmail.com  Sat Mar 12 20:03:31 2016
From: george.herbert at gmail.com (George Herbert)
Date: Sat, 12 Mar 2016 12:03:31 -0800
Subject: Why the US Government has so many data centers
In-Reply-To: <56E32329.3020201@spawar.navy.mil>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
Message-ID: <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>





> On Mar 11, 2016, at 11:57 AM, "Mark T. Ganzer" <ganzer at spawar.navy.mil> wrote:
> 
> but I will instead ask this for your consideration:  Do servers in "test, stage, development, or any other environment" really need to have the same environmental, power and connectivity requirements that "production" servers have?


Why would you think otherwise?

It's a symptom of trying to save a few cents at the risk of dollars.

George William Herbert
Sent from my iPhone

From eyeronic.design at gmail.com  Sat Mar 12 20:06:27 2016
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sat, 12 Mar 2016 12:06:27 -0800
Subject: SFP Cost Variation
In-Reply-To: <D1A73034-0A1A-4176-9F52-9F32228FF88A@ip-clear.de>
References: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
 <D1A73034-0A1A-4176-9F52-9F32228FF88A@ip-clear.de>
Message-ID: <CAN3um4yc=fouA+hhgz4Td94pHCCwT06kMQ=-6mCCrAKT7zxnCA@mail.gmail.com>

You also run into some quality issues on third party ones, so be aware
and plan for it.  I've had maybe one Cisco-branded SFP go bad that I
can think, but I've got a crap ton of Axiom branded ones that were
bad.  Twinax ones were even worse...I got maybe two or three inserts
out of a significant fraction of them before they broke.  I've had
great luck with Curvature SFPs.

On Sat, Mar 12, 2016 at 11:38 AM, J?rg Kost <jk at ip-clear.de> wrote:
> Its all about support under warranty.
>
> CDW is selling the original Brocade SFP. The amazon links only shows a
> compatible one. In most cases it will work, but if that tiny metal piece
> will break your freshly installed 20-x2 linecard, Brocade may not replace
> it. Also some of the cheaper optics may not support monitoring or diagnostic
> options.
>
> You can also check the second market for an used original optic, if you want
> to save some budget.
>
> J?rg
>
>
> On 9 Mar 2016, at 19:59, Nicholas Warren wrote:
>
>> Quick question for the experts.
>>
>> Why when looking at SFPs, some sites list them as $800 when the same part
>> number can be found on places like amazon for $30-$40. What is the
>> difference in them? Why would I buy them from a place like CDW with what
>> appears to be a 2,000% markup.
>>
>>
>> https://www.cdw.com/shop/products/Brocade-SFP-mini-GBIC-transceiver-module-G
>> igabit-Ethernet/1411743.aspx
>>
>> http://www.amazon.com/gp/product/B0076Q1CTY
>>
>> Thanks,
>> Nich



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

From marka at isc.org  Sat Mar 12 21:28:27 2016
From: marka at isc.org (Mark Andrews)
Date: Sun, 13 Mar 2016 08:28:27 +1100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: Your message of "Thu, 10 Mar 2016 07:58:29 -0700."
 <CADb+6TAqqYc2yLUGV7n4Qiioq8qasriNsBtCRNNvB2K1A-t1rw@mail.gmail.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E03714.9070700@foobar.org>
 <alpine.DEB.2.02.1603091651460.31096@uplift.swm.pp.se>
 <0eedf5e0-2551-9073-5c43-3376ccd2f15d@bogus.com>
 <CADb+6TAqqYc2yLUGV7n4Qiioq8qasriNsBtCRNNvB2K1A-t1rw@mail.gmail.com>
Message-ID: <20160312212827.B8EA5445D34B@rock.dv.isc.org>


In message <CADb+6TAqqYc2yLUGV7n4Qiioq8qasriNsBtCRNNvB2K1A-t1rw at mail.gmail.com>
, Joel Maslak writes:
> On Wed, Mar 9, 2016 at 9:27 AM, joel jaeggli <joelja at bogus.com> wrote:
> 
> > PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in
> > > my opinion (although it's strange how many hosts that seem to get away
> > > with 1492 (or is it 1496) MTU because they're using PPPoE).
> >
> > if your adv_mss is set accordingly you can get away with
> >  a lot.
> >
> 
> At least for TCP.  EDNS with sizes > 14xx bytes just plain doesn't
> universally work across the internet, yet it's the default everywhere.

If you fix your own firewall to accept fragmented packets EDNS
basically works.  Over the years I've see a couple of sites which
can't emit fragmented EDNS but they are few and far between.

Firewall vendors could also do the correct thing and support
installing slits as well as than pinholes when generating reply
traffic acceptance rules on the fly.  They could be honest and
acknowledge that legitimate reply traffic includes packet fragments
and build their boxes to support it.

Outbound

	allow proto udp from any to any 53 keep-state permit-frags

could generate 

	allow proto udp from dst 53 to src src-port
		and
	allow proto udp from dst to src frag offset != 0

You still have the protocol and the source and destination addresses.
You also don't allow full packets to reassemble via the slit rule.

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

From nick at foobar.org  Sat Mar 12 21:34:03 2016
From: nick at foobar.org (Nick Hilliard)
Date: Sat, 12 Mar 2016 21:34:03 +0000
Subject: SFP Cost Variation
In-Reply-To: <CAC6=tfZDyd9Qav4NW0Oa_neW2OSZqBsEtwgL1FxTET=V1fV9Gg@mail.gmail.com>
References: <C26ABA0F2E16624EA737DB4674DC05AB167D3184@mail.baec.local>
 <CAC6=tfZDyd9Qav4NW0Oa_neW2OSZqBsEtwgL1FxTET=V1fV9Gg@mail.gmail.com>
Message-ID: <56E48B4B.3030807@foobar.org>

Josh Reynolds wrote:
> http://packetpushers.net/overpriced-optics-by-oems/

the cost bases mentioned in this article are a bit odd:

> So how much does a 10GB SFP+ SR optic cost? It turns out around $85 +
> some margin, bringing the cost to $95.

You can pick up a 10GB SFP+ SR for $15 in units of one from fiberstore.
Given the volumes they buy, vendors are probably paying a lot less than
that.

Nick

From job at instituut.net  Sat Mar 12 22:05:43 2016
From: job at instituut.net (Job Snijders)
Date: Sat, 12 Mar 2016 23:05:43 +0100
Subject: L-Root IPv6 address renumbering
In-Reply-To: <4AA7E64A-A96E-4E2E-9F13-E3E33315D06D@icann.org>
References: <4AA7E64A-A96E-4E2E-9F13-E3E33315D06D@icann.org>
Message-ID: <20160312220543.GE80711@22.rev.meerval.net>

Hi David,

On Wed, Mar 09, 2016 at 09:06:20PM +0000, David Soltero wrote:
> This is advance notice that there is a scheduled change to the IPv6
> addresses in the Root Zone for the L root-server, also known as
> L.ROOT-SERVERS.NET, which is administered by the ICANN.
> 
> The current IP addresses for the L.ROOT-SERVERS.NET service are:
> 2001:500:3::42
> 
> As of March 23, 2016, the new IP addresses for the L.ROOT-SERVERS.NET service will be:
> 2001:500:9f::42
> 
> The change will be implemented on the root zone on March 23, 2016
> 2100UTC,  however the new address is already operational.

Can you elaborate on why this change is being introduced?

Kind regards,

Job

From fw at deneb.enyo.de  Sat Mar 12 22:12:56 2016
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 12 Mar 2016 23:12:56 +0100
Subject: Why the US Government has so many data centers
In-Reply-To: <56E32329.3020201@spawar.navy.mil> (Mark T. Ganzer's message of
 "Fri, 11 Mar 2016 11:57:29 -0800")
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
Message-ID: <87fuvvgxav.fsf@mid.deneb.enyo.de>

* Mark T. Ganzer:

> Note that I an not answering in any sort of "official" capacity....but
> I will instead ask this for your consideration:  Do servers in "test,
> stage, development, or any other environment" really need to have the
> same environmental, power and connectivity requirements that
> "production" servers have?

Depends on the process.  If you can push to production without pushing
to stage first, then stage and production need the same service level.

From fgont at si6networks.com  Sun Mar 13 01:22:28 2016
From: fgont at si6networks.com (Fernando Gont)
Date: Sat, 12 Mar 2016 22:22:28 -0300
Subject: IETF RFC 7707: Network Reconnaissance in IPv6 Networks
Message-ID: <56E4C0D4.5090705@si6networks.com>

Folks,

Tim Chown and me have published RFC7707 on "Network Reconnaissance in
IPv6 Networks". The RFC is available at:
<https://www.rfc-editor.org/rfc/rfc7707.txt>.

You can find some context for this RFC here:
<http://blog.si6networks.com/2016/03/the-ietf-has-just-published-rfc-7707_12.html>

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From rdobbins at arbor.net  Sun Mar 13 03:30:26 2016
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sun, 13 Mar 2016 10:30:26 +0700
Subject: Why the US Government has so many data centers
In-Reply-To: <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
Message-ID: <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>

On 13 Mar 2016, at 3:03, George Herbert wrote:

> It's a symptom of trying to save a few cents at the risk of dollars.

Concur 100%.

Not to mention the related security issues.

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

From joe at nethead.com  Sat Mar 12 20:15:41 2016
From: joe at nethead.com (Joe Hamelin)
Date: Sat, 12 Mar 2016 12:15:41 -0800
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
Message-ID: <CAO0-hXaDg26oAiYHFN9+rKnLb4+FTcWmYh1tOLKe0JqRc62DPg@mail.gmail.com>

I know at Clearwire data centers we used gray for network, blue for
management and orange for RS-232 console.  At least for the initial build.
Later re-work or additions were whatever the tech had on hand ;)  They also
had labels on each end of each wire showing the path through the system,
sometimes up to six lines.  It did make it easy to bring up a data center
and find cabling errors.  To see the system last more than a year or two up
upgrades would take some strong rules and oversight.  I think it would be
worth it if your management system can keep the religion.

--
Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474

On Sat, Mar 12, 2016 at 11:11 AM, Yardiel Fuentes <yardiel at gmail.com> wrote:

> Hello Nanog-ers,
>
> Have any of you had the option or; conversely, do you know of ?best
> practices" or ?common standards?,  to color code physical cabling for your
> connections in DataCenters for Base-T and FX connections? If so, Could you
> share  any ttype of color-coding schema you are aware of ??. Yes, this is
> actually considering paying for customized color-coded cabling in a Data
> Center...
>
> Mr. Google did not really provide me with relevant answers on the above?
> beyond the typical (Orange is for MMF, yellow for SMF, etc)?
>
> Any reasons for or against it welcome too...
>
> --
> Yardiel Fuentes
>

From ulf at alameda.net  Sat Mar 12 21:36:55 2016
From: ulf at alameda.net (Ulf Zimmermann)
Date: Sat, 12 Mar 2016 13:36:55 -0800
Subject: Cisco Fabricpath
In-Reply-To: <CAJDSeq2BYhgBkSMA2uiynaLWFWt_RQ9aqyp5=pnjExSWthA_aw@mail.gmail.com>
References: <CAJDSeq2BYhgBkSMA2uiynaLWFWt_RQ9aqyp5=pnjExSWthA_aw@mail.gmail.com>
Message-ID: <CAJUfXzcwPgS14e=cMb=+npVvu2P8Mzri3tseJBpTsdC9rKK-Tg@mail.gmail.com>

I have used it for a cage in one datacenter, it was built 2+ years ago. It
hasn't been giving us problems, with the exception of several bad Cisco
direct attached copper cables.


On Mon, Mar 7, 2016 at 7:55 AM, Nicolas V <nicovpp59 at gmail.com> wrote:

> Hello,
>
> Does anyone already played with cisco fabricpath feature ? I want to use it
> on my nexus 5548
>
> Is it working as easy as it seems ? No bugs / particular nx-os version... ?
>
> Thanks !
> Nicolas
>



-- 

Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764
You can find my resume at: http://www.Alameda.net/~ulf/resume.html

From dmburgess at linktechs.net  Sun Mar 13 14:31:57 2016
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Sun, 13 Mar 2016 14:31:57 +0000
Subject: Cogent - Google - HE Fun
In-Reply-To: <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
Message-ID: <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>

In the end, google has made a choice. I think these kinds of choices will delay IPv6 adoption.  

-----Original Message-----
From: Damien Burke [mailto:damien at supremebytes.com] 
Sent: Friday, March 11, 2016 2:51 PM
To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>; Dennis Burgess <dmburgess at linktechs.net>
Cc: North American Network Operators' Group <nanog at nanog.org>
Subject: RE: Cogent - Google - HE Fun

Just received an updated statement from cogent support:

"We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6. 

Once again, apologies for any inconvenience."

And:

"The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."


From joelja at bogus.com  Sun Mar 13 17:54:08 2016
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 13 Mar 2016 10:54:08 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
Message-ID: <9fade85a-2832-6c0d-b45f-e7a8bd8b290b@bogus.com>

On 3/13/16 7:31 AM, Dennis Burgess wrote:
> In the end, google has made a choice. I think these kinds of choices will delay IPv6 adoption.  

Given that they publish AAAA records for a great deal of their services
I'm not sure how you would conclude that.

> -----Original Message-----
> From: Damien Burke [mailto:damien at supremebytes.com] 
> Sent: Friday, March 11, 2016 2:51 PM
> To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>; Dennis Burgess <dmburgess at linktechs.net>
> Cc: North American Network Operators' Group <nanog at nanog.org>
> Subject: RE: Cogent - Google - HE Fun
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."
> 
> 


-------------- 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/20160313/620610ad/attachment.pgp>

From matthew at matthew.at  Sun Mar 13 18:20:03 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 13 Mar 2016 11:20:03 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
Message-ID: <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>

I come to the opposite conclusion - that this situation can persist with apparently no business impact to either party shows that IPv6 is still unnecessary.

Matthew Kaufman

(Sent from my iPhone)

> On Mar 13, 2016, at 7:31 AM, Dennis Burgess <dmburgess at linktechs.net> wrote:
> 
> In the end, google has made a choice. I think these kinds of choices will delay IPv6 adoption.  
> 
> -----Original Message-----
> From: Damien Burke [mailto:damien at supremebytes.com] 
> Sent: Friday, March 11, 2016 2:51 PM
> To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>; Dennis Burgess <dmburgess at linktechs.net>
> Cc: North American Network Operators' Group <nanog at nanog.org>
> Subject: RE: Cogent - Google - HE Fun
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."
> 

From sean at donelan.com  Sun Mar 13 21:15:24 2016
From: sean at donelan.com (Sean Donelan)
Date: Sun, 13 Mar 2016 17:15:24 -0400 (EDT)
Subject: Why the US Government has so many data centers
In-Reply-To: <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
Message-ID: <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>

On Sun, 13 Mar 2016, Roland Dobbins wrote:
> On 13 Mar 2016, at 3:03, George Herbert wrote:
>
>> It's a symptom of trying to save a few cents at the risk of dollars.
>
> Concur 100%.
>
> Not to mention the related security issues.

Just remember, no exceptions, no waivers.

I understand why cloud vendors want 100% of government IT dollars.  But
requiring all test and development to be done solely in cloud data 
centers...  there is your 100%


From dougb at dougbarton.us  Sun Mar 13 21:25:17 2016
From: dougb at dougbarton.us (Doug Barton)
Date: Sun, 13 Mar 2016 14:25:17 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
Message-ID: <56E5DABD.8020407@dougbarton.us>

s/IPv6/Cogent/  :)

No one who is serious about IPv6 is single-homed to Cogent. Arguably, no 
one who is serious about "The Internet" is single-homed on either protocol.

Thus your conclusion seems to be more like wishful thinking. :)

Doug


On 03/13/2016 11:20 AM, Matthew Kaufman wrote:
> I come to the opposite conclusion - that this situation can persist with apparently no business impact to either party shows that IPv6 is still unnecessary.
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
>> On Mar 13, 2016, at 7:31 AM, Dennis Burgess <dmburgess at linktechs.net> wrote:
>>
>> In the end, google has made a choice. I think these kinds of choices will delay IPv6 adoption.
>>
>> -----Original Message-----
>> From: Damien Burke [mailto:damien at supremebytes.com]
>> Sent: Friday, March 11, 2016 2:51 PM
>> To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>; Dennis Burgess <dmburgess at linktechs.net>
>> Cc: North American Network Operators' Group <nanog at nanog.org>
>> Subject: RE: Cogent - Google - HE Fun
>>
>> Just received an updated statement from cogent support:
>>
>> "We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6.
>>
>> Once again, apologies for any inconvenience."
>>
>> And:
>>
>> "The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."
>>


From george.herbert at gmail.com  Sun Mar 13 22:34:04 2016
From: george.herbert at gmail.com (George Herbert)
Date: Sun, 13 Mar 2016 15:34:04 -0700
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
Message-ID: <CC020B54-0899-4C05-93A4-9C3A93FCFB8D@gmail.com>


I really don't care about AWS sales (customer, but not investor or employee).  But...

If it's not highly loaded, cloud is cheaper.

If it's not in a well run datacenter / machine room, cloud is FAR more reliable.

The cost of blowing up hardware in less than well run machine rooms / datacenters can be immense.  At a now defunct cell provider, we lost a badly maintained machine room to fire, only about 24 racks, $2.1 million damage.  And nearly burned down the Frys Palo Alto building.  And that's just the worst catastrophe; had more losses than that in smaller clusters / onsies.

George William Herbert
Sent from my iPhone

> On Mar 13, 2016, at 2:15 PM, Sean Donelan <sean at donelan.com> wrote:
> 
>> On Sun, 13 Mar 2016, Roland Dobbins wrote:
>>> On 13 Mar 2016, at 3:03, George Herbert wrote:
>>> 
>>> It's a symptom of trying to save a few cents at the risk of dollars.
>> 
>> Concur 100%.
>> 
>> Not to mention the related security issues.
> 
> Just remember, no exceptions, no waivers.
> 
> I understand why cloud vendors want 100% of government IT dollars.  But
> requiring all test and development to be done solely in cloud data centers...  there is your 100%
> 

From ler762 at gmail.com  Sun Mar 13 23:20:53 2016
From: ler762 at gmail.com (Lee)
Date: Sun, 13 Mar 2016 19:20:53 -0400
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
Message-ID: <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>

On 3/13/16, Sean Donelan <sean at donelan.com> wrote:
> On Sun, 13 Mar 2016, Roland Dobbins wrote:
>> On 13 Mar 2016, at 3:03, George Herbert wrote:
>>
>>> It's a symptom of trying to save a few cents at the risk of dollars.
>>
>> Concur 100%.
>>
>> Not to mention the related security issues.
>
> Just remember, no exceptions, no waivers.
>
> I understand why cloud vendors want 100% of government IT dollars.  But
> requiring all test and development to be done solely in cloud data
> centers...  there is your 100%

Where does it say test/dev has to be done solely in a cloud data
center?  This bit
   For the purposes of this memorandum, rooms with at least one
server, providing
   services (whether in a production, test, stage, development, or any other
   environment), are considered data centers.
seems to be more about trying to close the self-reporting loophole -
ie 'these aren't the droids you're looking for.'   for example -
https://github.com/WhiteHouse/datacenters/issues/9

Lee

From owen at delong.com  Mon Mar 14 00:10:26 2016
From: owen at delong.com (Owen DeLong)
Date: Sun, 13 Mar 2016 17:10:26 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
Message-ID: <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>

I don?t know of any universal standards, but I?ve used the following in several
installatins I was responsible for to good avail:

Twisted Pair:

RED:	Untrusted Network (Internet or possibly DMZ)
YELLOW:	Optional for DMZ networks though I preferred to avoid documented in [1] below
BLUE:	Trusted Network (back-end, internal, etc.)
GREEN:	RS-232 straight-thru
PURPLE:	RS-232 X-Over (effectively Null Modem) 12345678 <-> 87654321 pin map.
ORANGE:	Ethernet X-Over (Best avoided documented in [2] below)
GREY:	Special purpose cabling not in one of the above categories

Fiber:
Orange ? Multimode Fiber
Yellow ? Singlemode Fiber

The absolute most useful thing you can do if you can impose the discipline to update
the cable map rigorously and/or allocate manpower for periodic audits is to apply a
unique serial number to each cable. I preferred to document not only the cable ID,
but also the length. For the installations where I have worked, 5 digits was sufficient
unique ID, so I used formats like IIIII-L[.L] where IIIII was a unique ID and L.L was
the length of the cable in feet. (e.g. 00123-6.5 is cable number 123 which is 6.5 feet
in length).

The labels are (ideally) the self-laminating wrap-around types. I prefer the Brady
labeling system which will automatically print 2-4 (depending on font size) instances
of the label text on the self-laminating label such that it can be read from virtually
any side of the cable without requiring you to rotate the label into view in most cases.

The Brady labeling system is a bit overpriced compared to the Brother P-Touch, but the
expanded capabilities and the quality of the label adhesives and such is, IMHO, sufficiently
superior to justify the cost.

Whatever you do, please do not use Flag labels on cables? I HATE THEM. They are a constant
source of entanglement and snags. They often get knocked off as a result or mangled beyond
recognition, rendering them useless.

Similarly, I?ve found that circuit-ID and end-point labels on cables are often ill-maintained,
so if you do use them, please make sure you remove them when the cable is moved/removed.

The length is very useful because it gives you a radius within which the other end of
the cable must be located and you can usually expect it to be reasonably close to the
outer edge of that radius.

More than a few times I?ve prevented a serious outage by giving the port number to the remote
hands guy and then insisting that he read me the cable ID. ?No, try the other port
FE-0/2/4? You?re off by one. It?s above/left/right/below you.?

[1] I prefer to avoid Yellow cables because some people have trouble understanding
that Yellow Fiber and Yellow UTP might have different meanings. I also feel that the
distinction between UNTRUSTED and DMZ networks is usually not all that important in
most cabling situations. YMMV.

[2] In this era of Auto-MDI/MDI-X ports and the like, it?s very rare to encounter a
situation that truly requires a crossover cable with no viable alternative. If such
is needed, I prefer to document it on the cable tags rather than using a special color
code. Again, you have the risk of people not understanding that orange Fiber might not
mean what Orange copper means. YMMV

Yes, I know you can now get virtually any type of fiber in virtually any color, but
the simple fact of the matter remains that when you send skippy out to buy emergency
jumpers or such, you?re most likely going to either get orange multimode or yellow
singlemode and that?s just the way it is.

Owen

> On Mar 12, 2016, at 11:11 , Yardiel Fuentes <yardiel at gmail.com> wrote:
> 
> Hello Nanog-ers,
> 
> Have any of you had the option or; conversely, do you know of ?best
> practices" or ?common standards?,  to color code physical cabling for your
> connections in DataCenters for Base-T and FX connections? If so, Could you
> share  any ttype of color-coding schema you are aware of ??. Yes, this is
> actually considering paying for customized color-coded cabling in a Data
> Center...
> 
> Mr. Google did not really provide me with relevant answers on the above?
> beyond the typical (Orange is for MMF, yellow for SMF, etc)?
> 
> Any reasons for or against it welcome too...
> 
> -- 
> Yardiel Fuentes


From owen at delong.com  Mon Mar 14 00:21:05 2016
From: owen at delong.com (Owen DeLong)
Date: Sun, 13 Mar 2016 17:21:05 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
Message-ID: <21131B80-9A60-42A2-8B15-74DF42EEA522@delong.com>


> On Mar 11, 2016, at 11:50 , Damien Burke <damien at supremebytes.com> wrote:
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."
> 

Which is a cute way of leaving out ?However, since we refuse to accept them directly peering with us??

Owen


From baldur.norddahl at gmail.com  Mon Mar 14 00:23:14 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Mon, 14 Mar 2016 01:23:14 +0100
Subject: Cogent - Google - HE Fun
In-Reply-To: <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
Message-ID: <CAPkb-7BV3ZV3TxVirrrpOpwNZTJwDJUSWdUsS35qARRAx8G6HQ@mail.gmail.com>

On 13 March 2016 at 19:20, Matthew Kaufman <matthew at matthew.at> wrote:

> I come to the opposite conclusion - that this situation can persist with
> apparently no business impact to either party shows that IPv6 is still
> unnecessary.
>

It does in fact have business impact on Cogent (but not Google). It means
that some Cogent customers, like us, that are multihomed no longer will
take in any Google IPv6 traffic via Cogent. This means we will be upgrading
other transits before we upgrade Cogent. Cogent will simply have less bytes
to sell to us.

This effect will be most profound in markets with eyeball networks that
implement IPv6.

On the other hand, Cogent might not know what they are missing out on. Our
traffic growth will mask the fact that they lost some revenue here.

It might also be that we did already get the Google traffic on a different
circuit and therefore nothing changed. But Cogent has many customers, so
there has to be some that just moved their IPv6 google traffic to other
transits as result of this.

Regards,

Baldur

From bill at herrin.us  Mon Mar 14 00:23:46 2016
From: bill at herrin.us (William Herrin)
Date: Sun, 13 Mar 2016 20:23:46 -0400
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
Message-ID: <CAP-guGXh1=MB8=vVTa04kAxhWVhzRzO9JfB1yxrTWjtasAiHzg@mail.gmail.com>

On Sat, Mar 12, 2016 at 2:11 PM, Yardiel Fuentes <yardiel at gmail.com> wrote:
> Have any of you had the option or; conversely, do you know of ?best
> practices" or ?common standards?,  to color code physical cabling for your
> connections in DataCenters for Base-T and FX connections? If so, Could you
> share  any ttype of color-coding schema you are aware of ??. Yes, this is
> actually considering paying for customized color-coded cabling in a Data
> Center...
>
> Mr. Google did not really provide me with relevant answers on the above?
> beyond the typical (Orange is for MMF, yellow for SMF, etc)?
>
> Any reasons for or against it welcome too...

Hi Yardiel,

Patch cables or fixed cabling to patch panels?

For fixed cabling, it's common to pick colors which match the cable
type. Orange for multimode fiber, yellow for single mode fiber, blue
for four-pair cat5e, something else for cat6, etc. At each end, label
the location of the opposite endpoint twice, once on the panel and
once on the cable itself (cables can pull loose from panels).

With fixed cabling terminating in patch panels they'll tend to get
reused over time for different types of signalling so don't overthink
it.


For patch cables, it's common to pick a color for each type of
physical signaling so you don't jam the wrong kind of signal in to a
port that doesn't match. Your gig-e switch may not like the voltage
from that ringing pots line. Blue for ethernet, white for POTs, green
for T1s, some other color for the rs232 serial cables, IP/KVM cables,
etc.

I find the easiest way to label patch cables is with color electrical
tape. Put the same bands of unique colors at both ends of the cable.
This will let you visually identify the cables without pulling on them
to try and line up tiny text on the tags with your eyeballs.

Regards,
Bill Herrin


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

From bill at herrin.us  Mon Mar 14 00:32:09 2016
From: bill at herrin.us (William Herrin)
Date: Sun, 13 Mar 2016 20:32:09 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <56E5DABD.8020407@dougbarton.us>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
Message-ID: <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>

On Sun, Mar 13, 2016 at 5:25 PM, Doug Barton <dougb at dougbarton.us> wrote:
> No one who is serious about IPv6 is single-homed to Cogent. Arguably, no one
> who is serious about "The Internet" is single-homed on either protocol.

At the very least, no one who is clueful about "The Internet" is
single-homed to Cogent with any protocol.

Regards,
Bill Herrin


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

From baldur.norddahl at gmail.com  Mon Mar 14 01:14:54 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Mon, 14 Mar 2016 02:14:54 +0100
Subject: DataCenter color-coding cabling schema
In-Reply-To: <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
Message-ID: <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>

Hi,

What is the best solution for thin 2 mm or 0.9 mm fiber labelling? I like
the idea of wrap around labels but does that work on thin wires? Maybe use
something to pad the wire to more thickness where the label is to be?

Regards,

Baldur

From sean at donelan.com  Mon Mar 14 01:15:49 2016
From: sean at donelan.com (Sean Donelan)
Date: Sun, 13 Mar 2016 21:15:49 -0400 (EDT)
Subject: Why the US Government has so many data centers
In-Reply-To: <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>

On Sun, 13 Mar 2016, Lee wrote:
> Where does it say test/dev has to be done solely in a cloud data
> center?  This bit
>   For the purposes of this memorandum, rooms with at least one
> server, providing
>   services (whether in a production, test, stage, development, or any other
>   environment), are considered data centers.
> seems to be more about trying to close the self-reporting loophole -
> ie 'these aren't the droids you're looking for.'   for example -
> https://github.com/WhiteHouse/datacenters/issues/9

Sigh, read any Inspector General report for how memorandums are 
implemented by auditors.  If the memorandum says "or any other 
environment" the IG's will treat that as no exceptions.

So IG's will "close the reporting loophole" by reporting that their are 
100,000 "data centers" if a room contains  even a single server.

Auditors like counting things, they don't like interpretations.  Inspector 
Generals are uber-auditors.


From nick.pratley at serversaustralia.com.au  Mon Mar 14 01:33:34 2016
From: nick.pratley at serversaustralia.com.au (Nick Pratley)
Date: Mon, 14 Mar 2016 12:33:34 +1100
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
Message-ID: <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>

Hi Baldur,

Equinix in Sydney use the below, for Cross Connects.

Goes around the fiber to pad it out, and the label keeps it on the fiber.

http://www.cableorganizer.com/panduit/labelcore-cable-id-sleeve/

Been meaning to order some for internal use, too.

Nick

From owen at delong.com  Mon Mar 14 01:56:12 2016
From: owen at delong.com (Owen DeLong)
Date: Sun, 13 Mar 2016 18:56:12 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
Message-ID: <3866B413-C0D9-42D3-AC3C-0F4BCE3805E5@delong.com>


> On Mar 13, 2016, at 18:14 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> Hi,
> 
> What is the best solution for thin 2 mm or 0.9 mm fiber labelling? I like
> the idea of wrap around labels but does that work on thin wires? Maybe use
> something to pad the wire to more thickness where the label is to be?

I doubt it would work on 0.9mm single strands, but I?ve had reasonably good
luck with it on standard SM and MM fiber pairs with normal zip-cord style
sheathing.

Owen


From owen at delong.com  Mon Mar 14 01:57:29 2016
From: owen at delong.com (Owen DeLong)
Date: Sun, 13 Mar 2016 18:57:29 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
 <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>
Message-ID: <20C0D077-F0BA-48B4-A693-AF8F9F20CCAB@delong.com>

The only problem I?ve had with those is that they tend to slide down the fiber and you can
end up having to trace the fiber to find the label which sort of defeats the purpose.

Owen

> On Mar 13, 2016, at 18:33 , Nick Pratley <nick.pratley at serversaustralia.com.au> wrote:
> 
> Hi Baldur,
> 
> Equinix in Sydney use the below, for Cross Connects.
> 
> Goes around the fiber to pad it out, and the label keeps it on the fiber.
> 
> http://www.cableorganizer.com/panduit/labelcore-cable-id-sleeve/
> 
> Been meaning to order some for internal use, too.
> 
> Nick


From colton.conor at gmail.com  Mon Mar 14 02:02:27 2016
From: colton.conor at gmail.com (Colton Conor)
Date: Sun, 13 Mar 2016 21:02:27 -0500
Subject: Juniper MX Sizing
In-Reply-To: <C860F293-22A7-48D6-B156-4F5A285A29EE@gmail.com>
References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int>
 <FC74C7D2-4613-46A4-BD9E-EABF39F3E5C0@tripadvisor.com>
 <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int>
 <E4080A77-0042-4BBA-A090-F653A0354861@gmail.com>
 <D3E1DD54-005A-4CB1-A063-1677E22417FB@tripadvisor.com>
 <C860F293-22A7-48D6-B156-4F5A285A29EE@gmail.com>
Message-ID: <CAMDdSzMZWQW-aHxgHhvWjNeUk46rEGK-LJNEFDo5SF_NENuO6A@mail.gmail.com>

Brad,

Did you ever get the numbers for the MX480?

On Fri, Dec 5, 2014 at 3:10 PM, Brad Fleming <bdflemin at gmail.com> wrote:

> We haven?t received the MX480 gear yet (POs just went in about a week
> ago). But we tested MX960s with the same RE-S-1800x4 w/ 16GB RAM RIB+FIB
> convergence time was roughly 45sec. We never worried about getting a super
> accurate time for the MX960 because even an ?eye test? showed it was fast
> enough for our application and we were much more concerned with other parts
> of the box. Also, we had inline-flow reporting configured on the MX960.
> Actually, the MX960?s had a full, production-ready config while the MX104
> was tested with a stripped down after we discovered the slow convergence.
>
> Once we get some MX480s on the bench I?ll report back.
>
>
> > On Dec 5, 2014, at 2:35 PM, Shawn Hsiao <phsiao at tripadvisor.com> wrote:
> >
> >
> > MX480 is also not instantaneous, so the same problem applies.   Brad, do
> you have the number for MX480 for comparison?
> >
> > What we decided was, given both models suffer the same problems, just
> different duration, we decided to mitigate the problem and not spending the
> money.
> >
> > Thanks.
> >
> >
> >
> > On Dec 5, 2014, at 3:01 PM, Brad Fleming <bdflemin at gmail.com> wrote:
> >
> >> Then you should look for something other then the MX104.
> >>
> >> In our testing an MX104 running Junos 13.3R4 with a single, full feed
> took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms
> RTT away and (2) update the FIB with all entries. This performance was
> observed with single RE and dual RE and without any excess services
> running. If we added inline-flow sampling to the device full convergence
> took closer to 5min 45sec in our lab. Efforts to bring the convergence time
> down (without filtering ingress advertisements) with the assistance of JTAC
> proved unsuccessful.
> >>
> >> We decided to ?bite the bullet? and procure MX480s instead but
> obviously that?s not possible for everyone. If the MX480 is out of the
> question a Brocade CER Premium is an option. We have 3 in production and
> see very attractive convergence times; however, they have a more limited
> feature set and you?ll want to understand how their FIB memory scales.
> Apologies, I don?t know the Cisco equivalent from the ASR line these days
> but I?m sure others on the list could help out.
> >>
> >>
> >>> On Dec 5, 2014, at 11:45 AM, Graham Johnston <johnstong at westmancom.com>
> wrote:
> >>>
> >>> Shawn,
> >>>
> >>> It's more about FIB than RIB as I am concerned about the time it takes
> until MPCs have updated route information after large scale changes in
> routes learned via BGP.
> >>>
> >>> Graham Johnston
> >>> Network Planner
> >>> Westman Communications Group
> >>> 204.717.2829
> >>> johnstong at westmancom.com
> >>> ??think green; don't print this email.
> >>>
> >>> -----Original Message-----
> >>> From: Shawn Hsiao [mailto:phsiao at tripadvisor.com]
> >>> Sent: Friday, December 05, 2014 11:30 AM
> >>> To: Graham Johnston
> >>> Cc: nanog at nanog.org
> >>> Subject: Re: Juniper MX Sizing
> >>>
> >>>
> >>> Is your sizing concern just for the RIB, or also for FIB to sync up?
>  The latter was a problem for us, but not the former.   We also have
> inline-jflow turned on and that is still a work-in-progress in terms of
> impacting performance.
> >>>
> >>> We are using MX104 for similar purposes for many months now, and with
> some tweaks in our procedures and configurations we found it to be
> acceptable.    MX104 may not be able to process routes as fast as MX480,
> but MX480 is also not instantaneous either so similar risks exist.
> >>>
> >>>
> >>>
> >>> On Dec 5, 2014, at 11:59 AM, Graham Johnston <johnstong at westmancom.com>
> wrote:
> >>>
> >>>> I am wondering if anyone can provide their real world experience
> about sizing Juniper MX routers as it relates to BGP.  I am needing a
> device that has a mix of layer 2 and 3 features, including MPLS, that will
> have a very low port count requirement that will primarily be used at a
> remote POP site to connect to the local IX as well as one or two full route
> transit providers.  The MX104 has what I need from a physical standpoint
> and a data plane standpoint, as well as power consumption figures.  My only
> concern is whether the REs have enough horsepower to churn through the
> convergence calculations at a rate that operators in this situation would
> find acceptable.  I realize that 'acceptable' is a moving target so I would
> happily accept feedback from people using them as to how long it takes and
> their happiness with the product.
> >>>>
> >>>> For those of you that deem the MX104 unacceptable in this kind of
> role and moved up to the MX240, what RE did you elect to use?
> >>>>
> >>>> Thanks,
> >>>> Graham Johnston
> >>>> Network Planner
> >>>> Westman Communications Group
> >>>> 204.717.2829
> >>>> johnstong at westmancom.com<mailto:johnstong at westmancom.com>
> >>>> P think green; don't print this email.
> >>>>
> >>>
> >>
> >
>
>

From oliver.oboyle at gmail.com  Mon Mar 14 02:21:48 2016
From: oliver.oboyle at gmail.com (Oliver O'Boyle)
Date: Sun, 13 Mar 2016 22:21:48 -0400
Subject: DataCenter color-coding cabling schema
In-Reply-To: <20C0D077-F0BA-48B4-A693-AF8F9F20CCAB@delong.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
 <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>
 <20C0D077-F0BA-48B4-A693-AF8F9F20CCAB@delong.com>
Message-ID: <CAMOPTEwvvh=NbiLQTLotkAdMq=rBhBE2dk5rT3vzQd3GZNVqTg@mail.gmail.com>

Just place a piece of tape under the padding and it won't slide anymore. 5
seconds of extra work per end, though.

On Sun, Mar 13, 2016 at 9:57 PM, Owen DeLong <owen at delong.com> wrote:

> The only problem I?ve had with those is that they tend to slide down the
> fiber and you can
> end up having to trace the fiber to find the label which sort of defeats
> the purpose.
>
> Owen
>
> > On Mar 13, 2016, at 18:33 , Nick Pratley <
> nick.pratley at serversaustralia.com.au> wrote:
> >
> > Hi Baldur,
> >
> > Equinix in Sydney use the below, for Cross Connects.
> >
> > Goes around the fiber to pad it out, and the label keeps it on the fiber.
> >
> > http://www.cableorganizer.com/panduit/labelcore-cable-id-sleeve/
> >
> > Been meaning to order some for internal use, too.
> >
> > Nick
>
>


-- 
:o@>

From Valdis.Kletnieks at vt.edu  Mon Mar 14 03:58:30 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 13 Mar 2016 23:58:30 -0400
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAMOPTEwvvh=NbiLQTLotkAdMq=rBhBE2dk5rT3vzQd3GZNVqTg@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
 <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>
 <20C0D077-F0BA-48B4-A693-AF8F9F20CCAB@delong.com>
 <CAMOPTEwvvh=NbiLQTLotkAdMq=rBhBE2dk5rT3vzQd3GZNVqTg@mail.gmail.com>
Message-ID: <62266.1457927910@turing-police.cc.vt.edu>

On Sun, 13 Mar 2016 22:21:48 -0400, "Oliver O'Boyle" said:
> Just place a piece of tape under the padding and it won't slide anymore. 5
> seconds of extra work per end, though.

I dunno. Your dexterity must be better than mine.  I'd have trouble digging up
the roll of tape, removing a section, putting the tape roll down, and applying
the tape to the cable, all in 5 seconds.

Especially if you drop it and it manages to bounce through a cutout in the
raised floor.  That's got to be the single best reason for overhead cabling. :)
-------------- 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/20160313/e2c4e242/attachment.pgp>

From mark.tinka at seacom.mu  Mon Mar 14 06:49:09 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Mon, 14 Mar 2016 08:49:09 +0200
Subject: Juniper MX Sizing
In-Reply-To: <CAMDdSzMZWQW-aHxgHhvWjNeUk46rEGK-LJNEFDo5SF_NENuO6A@mail.gmail.com>
References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int>
 <FC74C7D2-4613-46A4-BD9E-EABF39F3E5C0@tripadvisor.com>
 <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int>
 <E4080A77-0042-4BBA-A090-F653A0354861@gmail.com>
 <D3E1DD54-005A-4CB1-A063-1677E22417FB@tripadvisor.com>
 <C860F293-22A7-48D6-B156-4F5A285A29EE@gmail.com>
 <CAMDdSzMZWQW-aHxgHhvWjNeUk46rEGK-LJNEFDo5SF_NENuO6A@mail.gmail.com>
Message-ID: <88ec265f-9df6-2bf0-fe18-5fb48a2b63ff@seacom.mu>



On 14/Mar/16 04:02, Colton Conor wrote:

> Brad,
>
> Did you ever get the numbers for the MX480?

I would not expect a difference in performance for the MX480 vis a vis
the MX960 using the same RE's, MPC's and SCB's.

Mark.


From aledm at qix.co.uk  Mon Mar 14 10:15:48 2016
From: aledm at qix.co.uk (Aled Morris)
Date: Mon, 14 Mar 2016 10:15:48 +0000
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAP-guGXh1=MB8=vVTa04kAxhWVhzRzO9JfB1yxrTWjtasAiHzg@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <CAP-guGXh1=MB8=vVTa04kAxhWVhzRzO9JfB1yxrTWjtasAiHzg@mail.gmail.com>
Message-ID: <CAO1bj=acnPZtW-D0CE=nORLfGw8S61sqTLSLzJSHteQEtg3Ppw@mail.gmail.com>

On 14 March 2016 at 00:23, William Herrin <bill at herrin.us> wrote:

> On Sat, Mar 12, 2016 at 2:11 PM, Yardiel Fuentes <yardiel at gmail.com>
> wrote:
> > Have any of you had the option or; conversely, do you know of ?best
> > practices" or ?common standards?,  to color code physical cabling for
> your
> > connections in DataCenters for Base-T and FX connections?
>
> For patch cables, it's common to pick a color for each type of
> physical signaling
>


I used to support this view too, but over the last few years, as everything
has (basically) become Ethernet, I've taken to a different scheme.

For copper patching, I now recommend my clients simply invest in a range of
colored patch cables and use them randomly.

The length of the patch cable is much more important than the color (too
little length will make it difficult to re-route cables if you need to
remove cards etc. and too long will mean tangles and space taken up with
loops of excess cable.)

The benefits of my "rainbow" scheme are:

1. easier to identify both ends of a cable, reducing disconnect errors.
When tracing a cable in a bundle or on a patch bay, it's easy when they're
different colors.

2. no need to police the cable scheme - if you have a strict color regime,
what do you do when someone uses the wrong color?  especially if a
disconnect would be service affecting.  It's really hard to justify
"maintenance downtime" to an account manager on the basis of you not liking
the color of a patch cable.

Aled

From A.L.M.Buxey at lboro.ac.uk  Mon Mar 14 10:28:20 2016
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 14 Mar 2016 10:28:20 +0000
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAO1bj=acnPZtW-D0CE=nORLfGw8S61sqTLSLzJSHteQEtg3Ppw@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <CAP-guGXh1=MB8=vVTa04kAxhWVhzRzO9JfB1yxrTWjtasAiHzg@mail.gmail.com>
 <CAO1bj=acnPZtW-D0CE=nORLfGw8S61sqTLSLzJSHteQEtg3Ppw@mail.gmail.com>
Message-ID: <20160314102820.GG30170@lboro.ac.uk>

Hi,


I'm not sure I'm keen on a colour standard - especially given our recent difficulties
sourcing cabling to our spec in certain colours...or lengths!    however, what we do - and others
do based on this thread - is have our own internal colour scheme for purposes/systems/customers.

fibre is far more difficult for this - coloured labels (and a decent labelling regime in the first place)
win in that arena.  (obviously the copper plant has labelling too but the choice of colours means
that function/purpose is already known from many metres away ;-) ) 

alan

From rea+nanog at grid.kiae.ru  Mon Mar 14 11:42:44 2016
From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin)
Date: Mon, 14 Mar 2016 14:42:44 +0300
Subject: DataCenter color-coding cabling schema
In-Reply-To: <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
Message-ID: <20160314114244.GH85560@void.codelabs.ru>

Sun, Mar 13, 2016 at 05:10:26PM -0700, Owen DeLong wrote:
> Whatever you do, please do not use Flag labels on cables? I HATE
> THEM. They are a constant source of entanglement and snags. They
> often get knocked off as a result or mangled beyond recognition,
> rendering them useless.

Hadn't seen that for ages, using Brother P-touch printers for
small amounts of work and Avery Zweckform paper + laser printing
for large cable installations.  This stuff (Avery paper),
  http://computing.kiae.ru/~rea/wiring-porn-2.jpeg
lives already for 5+ years and outlived many replacements of
spine modules (that's InfiniBand fabric) and other operations
without labels being ruined in any way.
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.

From colton.conor at gmail.com  Mon Mar 14 12:35:09 2016
From: colton.conor at gmail.com (Colton Conor)
Date: Mon, 14 Mar 2016 07:35:09 -0500
Subject: Juniper MX Sizing
In-Reply-To: <88ec265f-9df6-2bf0-fe18-5fb48a2b63ff@seacom.mu>
References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int>
 <FC74C7D2-4613-46A4-BD9E-EABF39F3E5C0@tripadvisor.com>
 <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int>
 <E4080A77-0042-4BBA-A090-F653A0354861@gmail.com>
 <D3E1DD54-005A-4CB1-A063-1677E22417FB@tripadvisor.com>
 <C860F293-22A7-48D6-B156-4F5A285A29EE@gmail.com>
 <CAMDdSzMZWQW-aHxgHhvWjNeUk46rEGK-LJNEFDo5SF_NENuO6A@mail.gmail.com>
 <88ec265f-9df6-2bf0-fe18-5fb48a2b63ff@seacom.mu>
Message-ID: <CAMDdSzPZETMsr+HHhew6jW5cbQwumz_2375wv+udueO5QoMpaA@mail.gmail.com>

Mark,

You are right that makes sense. So as a recap, you were seeing about 45
seconds route convergence time using RE-S-1800x4 w/ 16GB RAM. For a MX104
it took 4min 25sec. I assume a MX80 would be even slower than an MX104.

What about a MX480 with RE-2000's with 4GB of ram? Does anyone have any
stats on that? I would assume faster than a MX104 but slower than the
RE-S-1800x4
w/ 16GB RAM.

On Mon, Mar 14, 2016 at 1:49 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 14/Mar/16 04:02, Colton Conor wrote:
>
> > Brad,
> >
> > Did you ever get the numbers for the MX480?
>
> I would not expect a difference in performance for the MX480 vis a vis
> the MX960 using the same RE's, MPC's and SCB's.
>
> Mark.
>
>

From colton.conor at gmail.com  Mon Mar 14 12:36:44 2016
From: colton.conor at gmail.com (Colton Conor)
Date: Mon, 14 Mar 2016 07:36:44 -0500
Subject: HP HSR Routers
In-Reply-To: <CAP-guGWYQae3OtQgOQM3gx9gmvCZ2eS1hFqLoQC=3boi6O62Ug@mail.gmail.com>
References: <CAMDdSzMkzE=n=LCk7Qs8E4La3Y_edAMrMpGxeL9BvAEwKY0LCw@mail.gmail.com>
 <CAP-guGWYQae3OtQgOQM3gx9gmvCZ2eS1hFqLoQC=3boi6O62Ug@mail.gmail.com>
Message-ID: <CAMDdSzNYiPy5UMbRv0QL+8T+-tv+yho+sd39u-MANE6BnUBbFQ@mail.gmail.com>

I don't see TCAM listed either, but as large as HP is I assume they can
afford and use TCAM in their larger routers.

On Sat, Mar 12, 2016 at 1:30 PM, William Herrin <bill at herrin.us> wrote:

> On Sat, Mar 12, 2016 at 1:04 PM, Colton Conor <colton.conor at gmail.com>
> wrote:
> > I would suggest looking at the HP routing line, in North America for some
> > reason people over look them (HP's ability to get the message out is not
> > stellar). The HSR 6602-XG will push 15 Mpps with routing table sizes of
> > 4mil (ipv4) and 2mil (ipv6) there is no additional licensing for any
> > feature you want to use. With respect to implementation I have always
> felt
> > if you understand the protocol who gives a damn about the syntax... The
> MSR
> > 4060 will handle 36 Mpps with table sizes of 1mil (ipv4) and 1mil (ipv6).
> > Either solution will be cost effective.
>
> Hi Colton,
>
> My bet is that there's no TCAM. That or they're being cagey about
> their hardware architecture since I can't find a single document about
> the router that even mentions TCAM. Instead I'd bet they're doing
> software routing (radix tree) spread over "32 hardware threads" and as
> long as the bulk of your destinations are in small enough parts of the
> tree to fit cleanly in to the processor caches you'll get "up to 15
> Mpps".
>
>
> http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=c04111430&doctype=quickspecs&doclang=EN_US&searchquery=&cc=us&lc=en
>
> If I'm right (I'm making guesses after all) then you should compare
> HP's offering with software-based routers from other vendors rather
> than comparing against routers which have a hardware fast path.
>
> 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  Mon Mar 14 12:48:54 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Mon, 14 Mar 2016 07:48:54 -0500 (CDT)
Subject: AT&T E-mail Admin
Message-ID: <825644654.10236.1457959731508.JavaMail.mhammett@ThunderFuck>

Could someone forward me over to someone in AT&T's e-mail department? I've got an IP that's seemingly mistakenly on their RBL. It isn't on any blacklists listed at MXToolbox and the logs don't show any recent SPAM like activity. I filled out their form, but no response yet and I suspect they won't take too kindly to my "There's nothing wrong." response in it. 




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



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



From jmilko at gmail.com  Mon Mar 14 13:14:16 2016
From: jmilko at gmail.com (James Milko)
Date: Mon, 14 Mar 2016 09:14:16 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
 <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
Message-ID: <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>

On Sun, Mar 13, 2016 at 8:32 PM, William Herrin <bill at herrin.us> wrote:

> On Sun, Mar 13, 2016 at 5:25 PM, Doug Barton <dougb at dougbarton.us> wrote:
> > No one who is serious about IPv6 is single-homed to Cogent. Arguably, no
> one
> > who is serious about "The Internet" is single-homed on either protocol.
>
> At the very least, no one who is clueful about "The Internet" is
> single-homed to Cogent with any protocol.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>

s/single-homed/dual-homed/

It's not like losing Google/HE because your other transit dropped is
acceptable.

JM

From bill at herrin.us  Mon Mar 14 14:47:24 2016
From: bill at herrin.us (William Herrin)
Date: Mon, 14 Mar 2016 10:47:24 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
 <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
 <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>
Message-ID: <CAP-guGXH43GsvX7n+18mVjgpzF4OC0xnhP8W4pOjyjjYCK=NAA@mail.gmail.com>

On Mon, Mar 14, 2016 at 9:14 AM, James Milko <jmilko at gmail.com> wrote:
> On Sun, Mar 13, 2016 at 8:32 PM, William Herrin <bill at herrin.us> wrote:
>> At the very least, no one who is clueful about "The Internet" is
>> single-homed to Cogent with any protocol.
>
> s/single-homed/dual-homed/
>
> It's not like losing Google/HE because your other transit dropped is
> acceptable.

Hi James,

Cogent is effective at reducing cost as the third or subsequent
provider in one's mix.

Regards,
Bill Herrin


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

From ler762 at gmail.com  Mon Mar 14 14:53:34 2016
From: ler762 at gmail.com (Lee)
Date: Mon, 14 Mar 2016 10:53:34 -0400
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
Message-ID: <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>

On 3/13/16, Sean Donelan wrote:
> On Sun, 13 Mar 2016, Lee wrote:
>> Where does it say test/dev has to be done solely in a cloud data
>> center?  This bit
>>   For the purposes of this memorandum, rooms with at least one
>> server, providing
>>   services (whether in a production, test, stage, development, or any
>> other
>>   environment), are considered data centers.
>> seems to be more about trying to close the self-reporting loophole -
>> ie 'these aren't the droids you're looking for.'   for example -
>> https://github.com/WhiteHouse/datacenters/issues/9
>
> Sigh, read any Inspector General report for how memorandums are
> implemented by auditors.  If the memorandum says "or any other
> environment" the IG's will treat that as no exceptions.
>
> So IG's will "close the reporting loophole" by reporting that their are
> 100,000 "data centers" if a room contains  even a single server.
>
> Auditors like counting things, they don't like interpretations.  Inspector
> Generals are uber-auditors.

uhmmm.. yes - that's my point.  No more of the "Whut?  That box over
there??  Oh no, that's not a server, it's an _appliance_"
foot-dragging / circumvention of the cloud first policy.

I doubt anyone really believes that having a server in the room makes
it a data center.  But if you're the Federal CIO pushing the cloud
first policy, this seems like a great bureaucratic maneuver to get the
decision making away from the techies that like redundant servers in
multiple locations, their managers who's job rating depends on
providing reliable services and even the agency CIOs.  Check the
reporting section of the memo where it says "each agency head shall
annually publish a Data Center Consolidation and Optimization
Strategic Plan".   I dunno, but I'm guessing agency heads are
political appointees that aren't going to spend much, if any, time
listening to techies whine about how important their servers are & why
they can't be consolidated, virtualized or outsourced.

Lee

From mhuff at ox.com  Mon Mar 14 14:58:03 2016
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 14 Mar 2016 14:58:03 +0000
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAP-guGXH43GsvX7n+18mVjgpzF4OC0xnhP8W4pOjyjjYCK=NAA@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
 <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
 <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>
 <CAP-guGXH43GsvX7n+18mVjgpzF4OC0xnhP8W4pOjyjjYCK=NAA@mail.gmail.com>
Message-ID: <82e09f735eb64ad9a5583cc8800af48c@pur-vm-exch13n1.ox.com>

One caveat about Cogent even as a third or extra provider.

Because of disputes with eyeball networks, there is significant congestion at peering points with Cogent. We saw consistent 5-10% packet loss over many months traversing Cogent through to Charger, Cox and Verizon as well as others. For web access and even streaming video, with buffers, this might not be an issue. But for corporate use with VOIP and/or VPNs, it was a killer. We had to cancel our Cogent service and work with our remaining providers to de-preference Cogent completely.



----
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 William Herrin
> Sent: Monday, March 14, 2016 10:47 AM
> To: James Milko <jmilko at gmail.com>
> Cc: nanog at nanog.org
> Subject: Re: Cogent - Google - HE Fun
> 
> On Mon, Mar 14, 2016 at 9:14 AM, James Milko <jmilko at gmail.com> wrote:
> > On Sun, Mar 13, 2016 at 8:32 PM, William Herrin <bill at herrin.us>
> wrote:
> >> At the very least, no one who is clueful about "The Internet" is
> >> single-homed to Cogent with any protocol.
> >
> > s/single-homed/dual-homed/
> >
> > It's not like losing Google/HE because your other transit dropped is
> > acceptable.
> 
> Hi James,
> 
> Cogent is effective at reducing cost as the third or subsequent provider
> in one's mix.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

From oliver.oboyle at gmail.com  Mon Mar 14 15:11:26 2016
From: oliver.oboyle at gmail.com (Oliver O'Boyle)
Date: Mon, 14 Mar 2016 11:11:26 -0400
Subject: DataCenter color-coding cabling schema
In-Reply-To: <62266.1457927910@turing-police.cc.vt.edu>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
 <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>
 <20C0D077-F0BA-48B4-A693-AF8F9F20CCAB@delong.com>
 <CAMOPTEwvvh=NbiLQTLotkAdMq=rBhBE2dk5rT3vzQd3GZNVqTg@mail.gmail.com>
 <62266.1457927910@turing-police.cc.vt.edu>
Message-ID: <CAMOPTEyquitOe=gYcjk6p+CHkUq_OMoozwrG6cWbUtHE4YOgrg@mail.gmail.com>

Lol! I am very dextrous... But I prep by pulling off many pieces of tape at
once and lining them up in advance. They don't need to go on perfectly. In
fact, a few wrinkles help to keep the padding in place better than no
wrinkles.

Put a wire around the roll of tape and connect it to a small carabiner that
you can clip to the rack or to other stable items wherever you're working
(not individual cables in case you dislodge them).

On Sun, Mar 13, 2016 at 11:58 PM, <Valdis.Kletnieks at vt.edu> wrote:

> On Sun, 13 Mar 2016 22:21:48 -0400, "Oliver O'Boyle" said:
> > Just place a piece of tape under the padding and it won't slide anymore.
> 5
> > seconds of extra work per end, though.
>
> I dunno. Your dexterity must be better than mine.  I'd have trouble
> digging up
> the roll of tape, removing a section, putting the tape roll down, and
> applying
> the tape to the cable, all in 5 seconds.
>
> Especially if you drop it and it manages to bounce through a cutout in the
> raised floor.  That's got to be the single best reason for overhead
> cabling. :)
>



-- 
:o@>

From sean at donelan.com  Mon Mar 14 15:20:35 2016
From: sean at donelan.com (Sean Donelan)
Date: Mon, 14 Mar 2016 11:20:35 -0400 (EDT)
Subject: Why the US Government has so many data centers
In-Reply-To: <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>

On Mon, 14 Mar 2016, Lee wrote:
> I doubt anyone really believes that having a server in the room makes
> it a data center.  But if you're the Federal CIO pushing the cloud
> first policy, this seems like a great bureaucratic maneuver to get the
> decision making away from the techies that like redundant servers in
> multiple locations, their managers who's job rating depends on
> providing reliable services and even the agency CIOs.  Check the
> reporting section of the memo where it says "each agency head shall
> annually publish a Data Center Consolidation and Optimization
> Strategic Plan".   I dunno, but I'm guessing agency heads are
> political appointees that aren't going to spend much, if any, time
> listening to techies whine about how important their servers are & why
> they can't be consolidated, virtualized or outsourced.

If your goal is to consolidate servers, call it a server consolidation 
initiative.

You are correct political appointees won't understand why techies are
perplexed by calling everything a data center.  Just remember that
when you read the stories in the Washington Post about how many
data centers the government has...


http://www.datacenterdynamics.com/design-build/us-government-finds-2000-more-data-centers/95243.fullarticle
New count of government facilities, and it looks like consolidation is going backwards



From ler762 at gmail.com  Mon Mar 14 16:44:03 2016
From: ler762 at gmail.com (Lee)
Date: Mon, 14 Mar 2016 12:44:03 -0400
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
Message-ID: <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>

On 3/14/16, Sean Donelan wrote:
> On Mon, 14 Mar 2016, Lee wrote:
>> I doubt anyone really believes that having a server in the room makes
>> it a data center.  But if you're the Federal CIO pushing the cloud
>> first policy, this seems like a great bureaucratic maneuver to get the
>> decision making away from the techies that like redundant servers in
>> multiple locations, their managers who's job rating depends on
>> providing reliable services and even the agency CIOs.  Check the
>> reporting section of the memo where it says "each agency head shall
>> annually publish a Data Center Consolidation and Optimization
>> Strategic Plan".   I dunno, but I'm guessing agency heads are
>> political appointees that aren't going to spend much, if any, time
>> listening to techies whine about how important their servers are & why
>> they can't be consolidated, virtualized or outsourced.
>
> If your goal is to consolidate servers, call it a server consolidation
> initiative.

He did, didn't he?  "... consolidate inefficient infrastructure,
optimize existing facilities, achieve cost savings, and transition to
more efficient infrastructure".   But other than the ability to
embarrass people[1] - ie. make the reports public, how much actual
ability to effect change does he really have?

> You are correct political appointees won't understand why techies are
> perplexed by calling everything a data center.  Just remember that
> when you read the stories in the Washington Post about how many
> data centers the government has...
>
>
> http://www.datacenterdynamics.com/design-build/us-government-finds-2000-more-data-centers/95243.fullarticle
> New count of government facilities, and it looks like consolidation is going
> backwards

Yes, *sigh*, another what kind of people _do_ we have running the govt
story.  Altho, looking on the bright side, it could have been much
worse than a final summing up of "With the current closing having been
reported to have saved over $2.5 billion it is clear that inroads are
being made, but ... one has to wonder exactly how effective the
initiative will be at achieving a more effective and efficient use of
government monies in providing technology services."

Best Regards,
Lee


[1] http://archive.fortune.com/2011/07/13/news/companies/vivek_kundra_leadership.fortune/index.htm

For example, one of the first things I did was take the picture of
every CIO in the federal government. We set up an IT dashboard online,
and I put their pictures right next to the IT projects they were
responsible for. You could see on this IT dashboard whether that
project was on schedule or not. The President actually looked at the
IT dashboard, so we took a picture of that and put it online. Moments
later, I started getting many phone calls from CIOs who said, "For the
first time, my cabinet secretary is asking me why this project is red
or green or yellow." One agency ended up halting 45 IT projects
immediately. It was just the act of shining light and making sure you
focus on execution, not only policy.

From george.metz at gmail.com  Mon Mar 14 17:01:07 2016
From: george.metz at gmail.com (George Metz)
Date: Mon, 14 Mar 2016 13:01:07 -0400
Subject: Why the US Government has so many data centers
In-Reply-To: <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
Message-ID: <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>

On Mon, Mar 14, 2016 at 12:44 PM, Lee <ler762 at gmail.com> wrote:

>
> Yes, *sigh*, another what kind of people _do_ we have running the govt
> story.  Altho, looking on the bright side, it could have been much
> worse than a final summing up of "With the current closing having been
> reported to have saved over $2.5 billion it is clear that inroads are
> being made, but ... one has to wonder exactly how effective the
> initiative will be at achieving a more effective and efficient use of
> government monies in providing technology services."
>
> Best Regards,
> Lee
>

That's an inaccurate cost savings though most likely; it probably doesn't
take into account the impacts of the consolidation on other items. As a
personal example, we're in the middle of upgrading my site from an OC-3 to
an OC-12, because we're running routinely at 95+% utilization on the OC-3
with 4,000+ seats at the site. The reason we're running that high is
because several years ago, they "consolidated" our file storage, so instead
of file storage (and, actually, dot1x authentication though that's
relatively minor) being local, everyone has to hit a datacenter some 500+
miles away over that OC-3 every time they have to access a file share. And
since they're supposed to save everything to their personal share drive
instead of the actual machine they're sitting at, the results are
predictable.

So how much is it going to cost for the OC-12 over the OC-3 annually? Is
that difference higher or lower than the cost to run a couple of storage
servers on-site? I don't know the math personally, but I do know that if we
had storage (and RADIUS auth and hell, even a shell server) on site, we
wouldn't be needing to upgrade to an OC-12.

From george.herbert at gmail.com  Mon Mar 14 17:28:30 2016
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 14 Mar 2016 10:28:30 -0700
Subject: Why the US Government has so many data centers
In-Reply-To: <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
Message-ID: <A12368ED-5796-4B5B-B893-1C7A78BF36EA@gmail.com>


At enterprise storage costs, that much storage will cost more than the OC-12, and then add datacenter and backups.  Total could be 2-3x OC-12 annual costs.

If your org can afford to buy non-top-line storage then it would probably be cheaper to go local.

However, you should check how much of the bandwidth is actually storage.  I see multimillion dollar projects without basic demand / needs analysis or statistics more often than not.


George William Herbert
Sent from my iPhone

> On Mar 14, 2016, at 10:01 AM, George Metz <george.metz at gmail.com> wrote:
> 
>> On Mon, Mar 14, 2016 at 12:44 PM, Lee <ler762 at gmail.com> wrote:
>> 
>> 
>> Yes, *sigh*, another what kind of people _do_ we have running the govt
>> story.  Altho, looking on the bright side, it could have been much
>> worse than a final summing up of "With the current closing having been
>> reported to have saved over $2.5 billion it is clear that inroads are
>> being made, but ... one has to wonder exactly how effective the
>> initiative will be at achieving a more effective and efficient use of
>> government monies in providing technology services."
>> 
>> Best Regards,
>> Lee
> 
> That's an inaccurate cost savings though most likely; it probably doesn't
> take into account the impacts of the consolidation on other items. As a
> personal example, we're in the middle of upgrading my site from an OC-3 to
> an OC-12, because we're running routinely at 95+% utilization on the OC-3
> with 4,000+ seats at the site. The reason we're running that high is
> because several years ago, they "consolidated" our file storage, so instead
> of file storage (and, actually, dot1x authentication though that's
> relatively minor) being local, everyone has to hit a datacenter some 500+
> miles away over that OC-3 every time they have to access a file share. And
> since they're supposed to save everything to their personal share drive
> instead of the actual machine they're sitting at, the results are
> predictable.
> 
> So how much is it going to cost for the OC-12 over the OC-3 annually? Is
> that difference higher or lower than the cost to run a couple of storage
> servers on-site? I don't know the math personally, but I do know that if we
> had storage (and RADIUS auth and hell, even a shell server) on site, we
> wouldn't be needing to upgrade to an OC-12.

From mhardeman at ipifony.com  Mon Mar 14 17:41:09 2016
From: mhardeman at ipifony.com (Matthew D. Hardeman)
Date: Mon, 14 Mar 2016 12:41:09 -0500
Subject: Cogent - Google - HE Fun
In-Reply-To: <82e09f735eb64ad9a5583cc8800af48c@pur-vm-exch13n1.ox.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
 <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
 <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>
 <CAP-guGXH43GsvX7n+18mVjgpzF4OC0xnhP8W4pOjyjjYCK=NAA@mail.gmail.com>
 <82e09f735eb64ad9a5583cc8800af48c@pur-vm-exch13n1.ox.com>
Message-ID: <51B2B308-163F-4D38-BE4A-F29E72F9CD51@ipifony.com>

I would have concurred on this not so very long ago, but Cogent has made serious strides in improving this.

In particular, I think Cogent is fairly trustworthy to at least AT&T and Verizon at this point.

As for Charter, Comcast, Cox, and the like, I?ve come to believe that there?s really no substitute for direct interconnection to those guys if they?re part of the market you serve.

My clients are mostly ISPs and ITSPs and for the over-the-top ITSPs, if they?re serving clients whose broadband access is one of the major cable providers, I always encourage the client to establish a BGP session directly into that provider (whether purchasing enterprise transit from them, but just accepting customer routes and advertising with a no-export prefix or formal paid peering, etc.)

The impact that it has on service quality is measurable and it?s a significant impact in many cases.

> On Mar 14, 2016, at 9:58 AM, Matthew Huff <mhuff at ox.com> wrote:
> 
> One caveat about Cogent even as a third or extra provider.
> 
> Because of disputes with eyeball networks, there is significant congestion at peering points with Cogent. We saw consistent 5-10% packet loss over many months traversing Cogent through to Charger, Cox and Verizon as well as others. For web access and even streaming video, with buffers, this might not be an issue. But for corporate use with VOIP and/or VPNs, it was a killer. We had to cancel our Cogent service and work with our remaining providers to de-preference Cogent completely.
> 
> 
> 
> ----
> 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 William Herrin
>> Sent: Monday, March 14, 2016 10:47 AM
>> To: James Milko <jmilko at gmail.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Cogent - Google - HE Fun
>> 
>> On Mon, Mar 14, 2016 at 9:14 AM, James Milko <jmilko at gmail.com> wrote:
>>> On Sun, Mar 13, 2016 at 8:32 PM, William Herrin <bill at herrin.us>
>> wrote:
>>>> At the very least, no one who is clueful about "The Internet" is
>>>> single-homed to Cogent with any protocol.
>>> 
>>> s/single-homed/dual-homed/
>>> 
>>> It's not like losing Google/HE because your other transit dropped is
>>> acceptable.
>> 
>> Hi James,
>> 
>> Cogent is effective at reducing cost as the third or subsequent provider
>> in one's mix.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> --
>> William Herrin ................ herrin at dirtside.com  bill at herrin.us
>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4190 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160314/33489d71/attachment.bin>

From owen at delong.com  Mon Mar 14 18:15:29 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 14 Mar 2016 11:15:29 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <62266.1457927910@turing-police.cc.vt.edu>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
 <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>
 <20C0D077-F0BA-48B4-A693-AF8F9F20CCAB@delong.com>
 <CAMOPTEwvvh=NbiLQTLotkAdMq=rBhBE2dk5rT3vzQd3GZNVqTg@mail.gmail.com>
 <62266.1457927910@turing-police.cc.vt.edu>
Message-ID: <9340F2CE-CF57-4199-A030-BA67AACF61A8@delong.com>


> On Mar 13, 2016, at 20:58 , Valdis.Kletnieks at vt.edu wrote:
> 
> On Sun, 13 Mar 2016 22:21:48 -0400, "Oliver O'Boyle" said:
>> Just place a piece of tape under the padding and it won't slide anymore. 5
>> seconds of extra work per end, though.
> 
> I dunno. Your dexterity must be better than mine.  I'd have trouble digging up
> the roll of tape, removing a section, putting the tape roll down, and applying
> the tape to the cable, all in 5 seconds.
> 
> Especially if you drop it and it manages to bounce through a cutout in the
> raised floor.  That's got to be the single best reason for overhead cabling. :)

Because it?s faster if you have to climb down off a ladder first before pulling
up the floor tiles to track down the roll of tape?

Oh, you mean that?s the single best reason for overhead COOLING. :P

Owen


From owen at delong.com  Mon Mar 14 18:19:44 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 14 Mar 2016 11:19:44 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAO1bj=acnPZtW-D0CE=nORLfGw8S61sqTLSLzJSHteQEtg3Ppw@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <CAP-guGXh1=MB8=vVTa04kAxhWVhzRzO9JfB1yxrTWjtasAiHzg@mail.gmail.com>
 <CAO1bj=acnPZtW-D0CE=nORLfGw8S61sqTLSLzJSHteQEtg3Ppw@mail.gmail.com>
Message-ID: <90C02696-623A-4410-B924-064FCC4ADFA7@delong.com>


> On Mar 14, 2016, at 03:15 , Aled Morris <aledm at qix.co.uk> wrote:
> 
> On 14 March 2016 at 00:23, William Herrin <bill at herrin.us> wrote:
> 
>> On Sat, Mar 12, 2016 at 2:11 PM, Yardiel Fuentes <yardiel at gmail.com>
>> wrote:
>>> Have any of you had the option or; conversely, do you know of ?best
>>> practices" or ?common standards?,  to color code physical cabling for
>> your
>>> connections in DataCenters for Base-T and FX connections?
>> 
>> For patch cables, it's common to pick a color for each type of
>> physical signaling
>> 
> 
> 
> I used to support this view too, but over the last few years, as everything
> has (basically) become Ethernet, I've taken to a different scheme.
> 
> For copper patching, I now recommend my clients simply invest in a range of
> colored patch cables and use them randomly.
> 
> The length of the patch cable is much more important than the color (too
> little length will make it difficult to re-route cables if you need to
> remove cards etc. and too long will mean tangles and space taken up with
> loops of excess cable.)
> 
> The benefits of my "rainbow" scheme are:
> 
> 1. easier to identify both ends of a cable, reducing disconnect errors.
> When tracing a cable in a bundle or on a patch bay, it's easy when they're
> different colors.

But if you serialize them and have the company you order the cables from
do the labeling (I?ve had this done, it?s not difficult and doesn?t add
significantly to the cost of the cables), then that?s even more useful
for that purpose than your ?rainbow? scheme.

> 2. no need to police the cable scheme - if you have a strict color regime,
> what do you do when someone uses the wrong color?  especially if a
> disconnect would be service affecting.  It's really hard to justify
> "maintenance downtime" to an account manager on the basis of you not liking
> the color of a patch cable.

Well?

1.	You have someone whose responsibility it is to keep appropriate
	sized cables of various colors in stock so that there?s no incentive
	to do so.

2.	You don?t let untrained monkeys play in your cage.

3.	You hand the 1d10t that did it a roll of appropriately colored electrical
	tape and provide instructions on how to spiral-wrap. He gets to change the
	color of the cable. (This will make a repeat offense relatively unlikely
	as it?s a huge PITA).

Owen


From mhuff at ox.com  Mon Mar 14 18:23:40 2016
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 14 Mar 2016 18:23:40 +0000
Subject: Cogent - Google - HE Fun
In-Reply-To: <51B2B308-163F-4D38-BE4A-F29E72F9CD51@ipifony.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
 <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
 <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>
 <CAP-guGXH43GsvX7n+18mVjgpzF4OC0xnhP8W4pOjyjjYCK=NAA@mail.gmail.com>
 <82e09f735eb64ad9a5583cc8800af48c@pur-vm-exch13n1.ox.com>
 <51B2B308-163F-4D38-BE4A-F29E72F9CD51@ipifony.com>
Message-ID: <40be6ecf49914224ac4eb6aa4e756688@pur-vm-exch13n1.ox.com>

We don't serve a market. We are a private business. We are multi-homed with multiple providers, none of which is an eyeball network. Even if we wanted to peer, most of them are not available in our area, but our the only choice for some of our employees.

Cogent still has congestion issues at various peering points as has been reported in this and other mailing lists recently. Like I said, if VOIP and VPN aren't an issue, go ahead and use cogent. But if packet loss makes your access useless, then avoid them if it all possible. 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: Matthew D. Hardeman [mailto:mhardeman at ipifony.com]
> Sent: Monday, March 14, 2016 1:41 PM
> To: Matthew Huff <mhuff at ox.com>
> Cc: William Herrin <bill at herrin.us>; James Milko <jmilko at gmail.com>;
> nanog at nanog.org
> Subject: Re: Cogent - Google - HE Fun
> 
> I would have concurred on this not so very long ago, but Cogent has made
> serious strides in improving this.
> 
> In particular, I think Cogent is fairly trustworthy to at least AT&T and
> Verizon at this point.
> 
> As for Charter, Comcast, Cox, and the like, I?ve come to believe that
> there?s really no substitute for direct interconnection to those guys if
> they?re part of the market you serve.
> 
> My clients are mostly ISPs and ITSPs and for the over-the-top ITSPs, if
> they?re serving clients whose broadband access is one of the major cable
> providers, I always encourage the client to establish a BGP session
> directly into that provider (whether purchasing enterprise transit from
> them, but just accepting customer routes and advertising with a no-
> export prefix or formal paid peering, etc.)
> 
> The impact that it has on service quality is measurable and it?s a
> significant impact in many cases.
> 
> > On Mar 14, 2016, at 9:58 AM, Matthew Huff <mhuff at ox.com> wrote:
> >
> > One caveat about Cogent even as a third or extra provider.
> >
> > Because of disputes with eyeball networks, there is significant
> congestion at peering points with Cogent. We saw consistent 5-10% packet
> loss over many months traversing Cogent through to Charger, Cox and
> Verizon as well as others. For web access and even streaming video, with
> buffers, this might not be an issue. But for corporate use with VOIP
> and/or VPNs, it was a killer. We had to cancel our Cogent service and
> work with our remaining providers to de-preference Cogent completely.
> >
> >
> >
> > ----
> > 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 William
> Herrin
> >> Sent: Monday, March 14, 2016 10:47 AM
> >> To: James Milko <jmilko at gmail.com>
> >> Cc: nanog at nanog.org
> >> Subject: Re: Cogent - Google - HE Fun
> >>
> >> On Mon, Mar 14, 2016 at 9:14 AM, James Milko <jmilko at gmail.com>
> wrote:
> >>> On Sun, Mar 13, 2016 at 8:32 PM, William Herrin <bill at herrin.us>
> >> wrote:
> >>>> At the very least, no one who is clueful about "The Internet" is
> >>>> single-homed to Cogent with any protocol.
> >>>
> >>> s/single-homed/dual-homed/
> >>>
> >>> It's not like losing Google/HE because your other transit dropped is
> >>> acceptable.
> >>
> >> Hi James,
> >>
> >> Cogent is effective at reducing cost as the third or subsequent
> provider
> >> in one's mix.
> >>
> >> Regards,
> >> Bill Herrin
> >>
> >>
> >> --
> >> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> >> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From mhardeman at ipifony.com  Mon Mar 14 18:31:56 2016
From: mhardeman at ipifony.com (Matthew D. Hardeman)
Date: Mon, 14 Mar 2016 13:31:56 -0500
Subject: Cogent - Google - HE Fun
In-Reply-To: <40be6ecf49914224ac4eb6aa4e756688@pur-vm-exch13n1.ox.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
 <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
 <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>
 <CAP-guGXH43GsvX7n+18mVjgpzF4OC0xnhP8W4pOjyjjYCK=NAA@mail.gmail.com>
 <82e09f735eb64ad9a5583cc8800af48c@pur-vm-exch13n1.ox.com>
 <51B2B308-163F-4D38-BE4A-F29E72F9CD51@ipifony.com>
 <40be6ecf49914224ac4eb6aa4e756688@pur-vm-exch13n1.ox.com>
Message-ID: <C28A6C01-1D71-4DE0-B20B-527D7282B7DF@ipifony.com>

I understand.  I tend to take a more market by market view of each network rather than a global perspective.  Clearly, for the enterprise use case with a diversity of users spread across the globe, or even nationally, the use case is a bit different.

Having said that, I am rather terribly curious...  I?ve not really seen any of the major national non-eyeballs who didn?t have congestion at some peering points to major eyeball networks for not insignificant periods. 

Which transit have you found to be the very best for minimizing those concerns in the general case?


> On Mar 14, 2016, at 1:23 PM, Matthew Huff <mhuff at ox.com> wrote:
> 
> We don't serve a market. We are a private business. We are multi-homed with multiple providers, none of which is an eyeball network. Even if we wanted to peer, most of them are not available in our area, but our the only choice for some of our employees.
> 
> Cogent still has congestion issues at various peering points as has been reported in this and other mailing lists recently. Like I said, if VOIP and VPN aren't an issue, go ahead and use cogent. But if packet loss makes your access useless, then avoid them if it all possible. 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: Matthew D. Hardeman [mailto:mhardeman at ipifony.com]
>> Sent: Monday, March 14, 2016 1:41 PM
>> To: Matthew Huff <mhuff at ox.com>
>> Cc: William Herrin <bill at herrin.us>; James Milko <jmilko at gmail.com>;
>> nanog at nanog.org
>> Subject: Re: Cogent - Google - HE Fun
>> 
>> I would have concurred on this not so very long ago, but Cogent has made
>> serious strides in improving this.
>> 
>> In particular, I think Cogent is fairly trustworthy to at least AT&T and
>> Verizon at this point.
>> 
>> As for Charter, Comcast, Cox, and the like, I?ve come to believe that
>> there?s really no substitute for direct interconnection to those guys if
>> they?re part of the market you serve.
>> 
>> My clients are mostly ISPs and ITSPs and for the over-the-top ITSPs, if
>> they?re serving clients whose broadband access is one of the major cable
>> providers, I always encourage the client to establish a BGP session
>> directly into that provider (whether purchasing enterprise transit from
>> them, but just accepting customer routes and advertising with a no-
>> export prefix or formal paid peering, etc.)
>> 
>> The impact that it has on service quality is measurable and it?s a
>> significant impact in many cases.
>> 
>>> On Mar 14, 2016, at 9:58 AM, Matthew Huff <mhuff at ox.com> wrote:
>>> 
>>> One caveat about Cogent even as a third or extra provider.
>>> 
>>> Because of disputes with eyeball networks, there is significant
>> congestion at peering points with Cogent. We saw consistent 5-10% packet
>> loss over many months traversing Cogent through to Charger, Cox and
>> Verizon as well as others. For web access and even streaming video, with
>> buffers, this might not be an issue. But for corporate use with VOIP
>> and/or VPNs, it was a killer. We had to cancel our Cogent service and
>> work with our remaining providers to de-preference Cogent completely.
>>> 
>>> 
>>> 
>>> ----
>>> 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 William
>> Herrin
>>>> Sent: Monday, March 14, 2016 10:47 AM
>>>> To: James Milko <jmilko at gmail.com>
>>>> Cc: nanog at nanog.org
>>>> Subject: Re: Cogent - Google - HE Fun
>>>> 
>>>> On Mon, Mar 14, 2016 at 9:14 AM, James Milko <jmilko at gmail.com>
>> wrote:
>>>>> On Sun, Mar 13, 2016 at 8:32 PM, William Herrin <bill at herrin.us>
>>>> wrote:
>>>>>> At the very least, no one who is clueful about "The Internet" is
>>>>>> single-homed to Cogent with any protocol.
>>>>> 
>>>>> s/single-homed/dual-homed/
>>>>> 
>>>>> It's not like losing Google/HE because your other transit dropped is
>>>>> acceptable.
>>>> 
>>>> Hi James,
>>>> 
>>>> Cogent is effective at reducing cost as the third or subsequent
>> provider
>>>> in one's mix.
>>>> 
>>>> Regards,
>>>> Bill Herrin
>>>> 
>>>> 
>>>> --
>>>> William Herrin ................ herrin at dirtside.com  bill at herrin.us
>>>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4190 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160314/57f7024a/attachment.bin>

From owen at delong.com  Mon Mar 14 18:39:30 2016
From: owen at delong.com (Owen DeLong)
Date: Mon, 14 Mar 2016 11:39:30 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <20160314114244.GH85560@void.codelabs.ru>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <20160314114244.GH85560@void.codelabs.ru>
Message-ID: <1E9C33CD-679D-43BE-8ACD-9519A6D7FE5D@delong.com>


> On Mar 14, 2016, at 04:42 , Eygene Ryabinkin <rea+nanog at grid.kiae.ru> wrote:
> 
> Sun, Mar 13, 2016 at 05:10:26PM -0700, Owen DeLong wrote:
>> Whatever you do, please do not use Flag labels on cables? I HATE
>> THEM. They are a constant source of entanglement and snags. They
>> often get knocked off as a result or mangled beyond recognition,
>> rendering them useless.
> 
> Hadn't seen that for ages, using Brother P-touch printers for
> small amounts of work and Avery Zweckform paper + laser printing
> for large cable installations.  This stuff (Avery paper),
>  http://computing.kiae.ru/~rea/wiring-porn-2.jpeg
> lives already for 5+ years and outlived many replacements of
> spine modules (that's InfiniBand fabric) and other operations
> without labels being ruined in any way.

Sorry? To be clear, those hideous attrocities of P-Touch nastiness
are exactly what I meant by flag labels. I had forgotten about the
plastic zip ties with the over-sized surface on the ratchet.

Compare to:

http://www.cableorganizer.com/images/brady/brady-idxpert/labels-markers/images/01-idxpert-markers-labels-cables.jpg

http://neumannmarking.com/wp-content/uploads/2015/03/135866255-300x199.jpg

http://www.hotblog.co.uk/boblittlepr/wp-content/uploads/2013/06/cable-labels_Cormant_1.jpg

Admittedly, I?m not wild about the bar-code scheme in the last one as I prefer human-readable labels, but YMMV.

Owen


From mhuff at ox.com  Mon Mar 14 18:42:23 2016
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 14 Mar 2016 18:42:23 +0000
Subject: Cogent - Google - HE Fun
In-Reply-To: <C28A6C01-1D71-4DE0-B20B-527D7282B7DF@ipifony.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <2DFCBBC2-7CD9-4347-8758-F8980CADC2B7@matthew.at>
 <56E5DABD.8020407@dougbarton.us>
 <CAP-guGXF+8k4Kr1uZvAmB-VKw+F4K+4Yp3x0_XZ0uXjOGi2uBg@mail.gmail.com>
 <CAAFEU20QpxWJg++TEASgrNo8x6p_q-WMFyDaqdha5g1JR3z+Fg@mail.gmail.com>
 <CAP-guGXH43GsvX7n+18mVjgpzF4OC0xnhP8W4pOjyjjYCK=NAA@mail.gmail.com>
 <82e09f735eb64ad9a5583cc8800af48c@pur-vm-exch13n1.ox.com>
 <51B2B308-163F-4D38-BE4A-F29E72F9CD51@ipifony.com>
 <40be6ecf49914224ac4eb6aa4e756688@pur-vm-exch13n1.ox.com>
 <C28A6C01-1D71-4DE0-B20B-527D7282B7DF@ipifony.com>
Message-ID: <d2560c808f23484fa843a6fdf5809ede@pur-vm-exch13n1.ox.com>

I wouldn't say that I know what's best. We have had many different providers over the last 20 years that I have been here. We never had an issue with any of them until we added Cogent into the mix. Currently we are using a 300MB lighttower and a 300MB LighPath metro Ethernet connection. 

From my experience VPN software (both IPSEC and SSLVPN) are very susceptible to high packet loss issues. A few retransmissions/out of order/dropped packets aren't a problem. A sustained drop rate of 5-10% is a major issue.

----
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: Matthew D. Hardeman [mailto:mhardeman at ipifony.com]
> Sent: Monday, March 14, 2016 2:32 PM
> To: Matthew Huff <mhuff at ox.com>
> Cc: William Herrin <bill at herrin.us>; James Milko <jmilko at gmail.com>;
> nanog at nanog.org
> Subject: Re: Cogent - Google - HE Fun
> 
> I understand.  I tend to take a more market by market view of each
> network rather than a global perspective.  Clearly, for the enterprise
> use case with a diversity of users spread across the globe, or even
> nationally, the use case is a bit different.
> 
> Having said that, I am rather terribly curious...  I?ve not really seen
> any of the major national non-eyeballs who didn?t have congestion at
> some peering points to major eyeball networks for not insignificant
> periods.
> 
> Which transit have you found to be the very best for minimizing those
> concerns in the general case?
> 
> 
> > On Mar 14, 2016, at 1:23 PM, Matthew Huff <mhuff at ox.com> wrote:
> >
> > We don't serve a market. We are a private business. We are multi-homed
> with multiple providers, none of which is an eyeball network. Even if we
> wanted to peer, most of them are not available in our area, but our the
> only choice for some of our employees.
> >
> > Cogent still has congestion issues at various peering points as has
> been reported in this and other mailing lists recently. Like I said, if
> VOIP and VPN aren't an issue, go ahead and use cogent. But if packet
> loss makes your access useless, then avoid them if it all possible.
> 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: Matthew D. Hardeman [mailto:mhardeman at ipifony.com]
> >> Sent: Monday, March 14, 2016 1:41 PM
> >> To: Matthew Huff <mhuff at ox.com>
> >> Cc: William Herrin <bill at herrin.us>; James Milko <jmilko at gmail.com>;
> >> nanog at nanog.org
> >> Subject: Re: Cogent - Google - HE Fun
> >>
> >> I would have concurred on this not so very long ago, but Cogent has
> made
> >> serious strides in improving this.
> >>
> >> In particular, I think Cogent is fairly trustworthy to at least AT&T
> and
> >> Verizon at this point.
> >>
> >> As for Charter, Comcast, Cox, and the like, I?ve come to believe that
> >> there?s really no substitute for direct interconnection to those guys
> if
> >> they?re part of the market you serve.
> >>
> >> My clients are mostly ISPs and ITSPs and for the over-the-top ITSPs,
> if
> >> they?re serving clients whose broadband access is one of the major
> cable
> >> providers, I always encourage the client to establish a BGP session
> >> directly into that provider (whether purchasing enterprise transit
> from
> >> them, but just accepting customer routes and advertising with a no-
> >> export prefix or formal paid peering, etc.)
> >>
> >> The impact that it has on service quality is measurable and it?s a
> >> significant impact in many cases.
> >>
> >>> On Mar 14, 2016, at 9:58 AM, Matthew Huff <mhuff at ox.com> wrote:
> >>>
> >>> One caveat about Cogent even as a third or extra provider.
> >>>
> >>> Because of disputes with eyeball networks, there is significant
> >> congestion at peering points with Cogent. We saw consistent 5-10%
> packet
> >> loss over many months traversing Cogent through to Charger, Cox and
> >> Verizon as well as others. For web access and even streaming video,
> with
> >> buffers, this might not be an issue. But for corporate use with VOIP
> >> and/or VPNs, it was a killer. We had to cancel our Cogent service and
> >> work with our remaining providers to de-preference Cogent completely.
> >>>
> >>>
> >>>
> >>> ----
> >>> 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 William
> >> Herrin
> >>>> Sent: Monday, March 14, 2016 10:47 AM
> >>>> To: James Milko <jmilko at gmail.com>
> >>>> Cc: nanog at nanog.org
> >>>> Subject: Re: Cogent - Google - HE Fun
> >>>>
> >>>> On Mon, Mar 14, 2016 at 9:14 AM, James Milko <jmilko at gmail.com>
> >> wrote:
> >>>>> On Sun, Mar 13, 2016 at 8:32 PM, William Herrin <bill at herrin.us>
> >>>> wrote:
> >>>>>> At the very least, no one who is clueful about "The Internet" is
> >>>>>> single-homed to Cogent with any protocol.
> >>>>>
> >>>>> s/single-homed/dual-homed/
> >>>>>
> >>>>> It's not like losing Google/HE because your other transit dropped
> is
> >>>>> acceptable.
> >>>>
> >>>> Hi James,
> >>>>
> >>>> Cogent is effective at reducing cost as the third or subsequent
> >> provider
> >>>> in one's mix.
> >>>>
> >>>> Regards,
> >>>> Bill Herrin
> >>>>
> >>>>
> >>>> --
> >>>> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> >>>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> >


From Valdis.Kletnieks at vt.edu  Mon Mar 14 18:52:03 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 14 Mar 2016 14:52:03 -0400
Subject: DataCenter color-coding cabling schema
In-Reply-To: <9340F2CE-CF57-4199-A030-BA67AACF61A8@delong.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CAPkb-7BkGpyN_bg10dY=LHpnXz_nv76EJzYFykWKK3WJCKRTCQ@mail.gmail.com>
 <CALf9hzCk1qdDLMLHL2L1epcCZ66gBtCvES8RkOF9R3p+iWZstg@mail.gmail.com>
 <20C0D077-F0BA-48B4-A693-AF8F9F20CCAB@delong.com>
 <CAMOPTEwvvh=NbiLQTLotkAdMq=rBhBE2dk5rT3vzQd3GZNVqTg@mail.gmail.com>
 <62266.1457927910@turing-police.cc.vt.edu>
 <9340F2CE-CF57-4199-A030-BA67AACF61A8@delong.com>
Message-ID: <22453.1457981523@turing-police.cc.vt.edu>

On Mon, 14 Mar 2016 11:15:29 -0700, Owen DeLong said:
> > On Mar 13, 2016, at 20:58 , Valdis.Kletnieks at vt.edu wrote:
> > Especially if you drop it and it manages to bounce through a cutout in the
> > raised floor.  That's got to be the single best reason for overhead cabling. :)

> Because it???s faster if you have to climb down off a ladder first before pulling
> up the floor tiles to track down the roll of tape?

> Oh, you mean that???s the single best reason for overhead COOLING. :P

The tiles intended for cold air flow have lots of little 1/4" or so holes
in them that a roll of tape can't fall through.  The roll of tape *can*
escape through the 6x6 cable cutout under the rack if there aren't too
many cables in the way.  If we had overhead cabling and under-floor cooling,
we'd have no large cutouts anyplace. :)

(Alas, the data center across the hall is 27 years old, and we'll need to
build a new one to fix it.  Someday soon, maybe. :)
-------------- 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/20160314/7f4b2561/attachment.pgp>

From sean at donelan.com  Mon Mar 14 19:19:16 2016
From: sean at donelan.com (Sean Donelan)
Date: Mon, 14 Mar 2016 15:19:16 -0400 (EDT)
Subject: Why the US Government has so many data centers
In-Reply-To: <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1603141511180.76497@cnex.qbaryna.pbz>

On Mon, 14 Mar 2016, George Metz wrote:
> That's an inaccurate cost savings though most likely; it probably doesn't

Politicians and sales people with inaccurate cost savings.  Say it isn't 
so.

If you think these are $100 million dollar "data centers," maybe a few 
billion dollars in cost savings is possible over 10 years.  But if a 
majority of the "data centers" are a single server in a room, the 
cost savings of moving it to a different room may not save billions of 
dollars.  But no one will remember.  Prediction, there will be a glowing 
report in a year or so about the huge cost savings, and then a couple 
years later will be an Inspector General report about problems counting 
things.

If that's what taxpayers want, that's what they'll get.


From george.metz at gmail.com  Mon Mar 14 19:19:50 2016
From: george.metz at gmail.com (George Metz)
Date: Mon, 14 Mar 2016 15:19:50 -0400
Subject: Why the US Government has so many data centers
In-Reply-To: <A12368ED-5796-4B5B-B893-1C7A78BF36EA@gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
 <A12368ED-5796-4B5B-B893-1C7A78BF36EA@gmail.com>
Message-ID: <CANjVB-hzL1iUBa9iK5HdFHxOS0Xx7BHttsCSKbCPqspYFfSdYA@mail.gmail.com>

Datacenter isn't actually an issue since there's room in the same racks
(ironically, in the location the previous fileservers were) as the Domain
Controllers and WAN Accelerators. Based on the "standard" (per the Windows
admins) file storage space of 700 meg, that sounds like 3TB for user
storage. Even if it were 30TB, I still can't see a proper setup costing
more than the OC-12 after a period of two years.

Org is within the Federal Government, so they're not allowed to buy
non-top-line anything. I agree we should check how much bandwidth is
storage, but since there's a snowball's chance in hell of them actually
making a change, it's almost certainly not worth the paperwork.

On Mon, Mar 14, 2016 at 1:28 PM, George Herbert <george.herbert at gmail.com>
wrote:

>
> At enterprise storage costs, that much storage will cost more than the
> OC-12, and then add datacenter and backups.  Total could be 2-3x OC-12
> annual costs.
>
> If your org can afford to buy non-top-line storage then it would probably
> be cheaper to go local.
>
> However, you should check how much of the bandwidth is actually storage.
> I see multimillion dollar projects without basic demand / needs analysis or
> statistics more often than not.
>
>
> George William Herbert
> Sent from my iPhone
>
> > On Mar 14, 2016, at 10:01 AM, George Metz <george.metz at gmail.com> wrote:
> >
> >> On Mon, Mar 14, 2016 at 12:44 PM, Lee <ler762 at gmail.com> wrote:
> >>
> >>
> >> Yes, *sigh*, another what kind of people _do_ we have running the govt
> >> story.  Altho, looking on the bright side, it could have been much
> >> worse than a final summing up of "With the current closing having been
> >> reported to have saved over $2.5 billion it is clear that inroads are
> >> being made, but ... one has to wonder exactly how effective the
> >> initiative will be at achieving a more effective and efficient use of
> >> government monies in providing technology services."
> >>
> >> Best Regards,
> >> Lee
> >
> > That's an inaccurate cost savings though most likely; it probably doesn't
> > take into account the impacts of the consolidation on other items. As a
> > personal example, we're in the middle of upgrading my site from an OC-3
> to
> > an OC-12, because we're running routinely at 95+% utilization on the OC-3
> > with 4,000+ seats at the site. The reason we're running that high is
> > because several years ago, they "consolidated" our file storage, so
> instead
> > of file storage (and, actually, dot1x authentication though that's
> > relatively minor) being local, everyone has to hit a datacenter some 500+
> > miles away over that OC-3 every time they have to access a file share.
> And
> > since they're supposed to save everything to their personal share drive
> > instead of the actual machine they're sitting at, the results are
> > predictable.
> >
> > So how much is it going to cost for the OC-12 over the OC-3 annually? Is
> > that difference higher or lower than the cost to run a couple of storage
> > servers on-site? I don't know the math personally, but I do know that if
> we
> > had storage (and RADIUS auth and hell, even a shell server) on site, we
> > wouldn't be needing to upgrade to an OC-12.
>

From george.herbert at gmail.com  Mon Mar 14 19:29:09 2016
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 14 Mar 2016 12:29:09 -0700
Subject: Why the US Government has so many data centers
In-Reply-To: <CANjVB-hzL1iUBa9iK5HdFHxOS0Xx7BHttsCSKbCPqspYFfSdYA@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
 <A12368ED-5796-4B5B-B893-1C7A78BF36EA@gmail.com>
 <CANjVB-hzL1iUBa9iK5HdFHxOS0Xx7BHttsCSKbCPqspYFfSdYA@mail.gmail.com>
Message-ID: <42E3C7B7-EB88-4510-B9C8-355D7014AFBB@gmail.com>




> On Mar 14, 2016, at 12:19 PM, George Metz <george.metz at gmail.com> wrote:
> 
> Based on the "standard" (per the Windows admins) file storage space of 700 meg, that sounds like 3TB for user storage. Even if it were 30TB, I still can't see a proper setup costing more than the OC-12 after a period of two years.
> 
> Org is within the Federal Government, so they're not allowed to buy non-top-line anything.

Million-plus dollar NetApps or EMC units are not at all unusual.

This is a terrible pity if a small NAS from Imation/Nexsan would work redundantly for $150k or less.

> I agree we should check how much bandwidth is storage, but since there's a snowball's chance in hell of them actually making a change, it's almost certainly not worth the paperwork.

This is the kind of thing whoever runs it needs to know, proves my point, and argues against local datacenters where nobody bothers to even collect performance metrics much of the time.

George William Herbert
Sent from my iPhone


From surfer at mauigateway.com  Mon Mar 14 20:27:01 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 14 Mar 2016 13:27:01 -0700
Subject: Why the US Government has so many data centers
Message-ID: <20160314132701.5CE29CFD@m0087793.ppops.net>


--- sean at donelan.com wrote:
From: Sean Donelan <sean at donelan.com>
  
: But if a majority of the "data centers" are a single server 
: in a room, the cost savings of moving it to a different 
: room may not save billions of dollars.  But no one will 
: remember.  

Many are not one, rather several.  For example, in a job there
were two M$ servers in a room.  The guides required an AD setup 
(with a backup AD), 2 NTP servers with Stratum 1 (for, you know 
the logs in the syslog server; they need to be accurate), a 
router, a LAN switch (can't put a LAN switch card in the router) 
and a firewall.  All for *two* servers.  I'm not even mentioning 
the administrative requirements for all the boxes.

It's all phunny money.  Real economics are not even considered.
At all.


: Prediction, there will be a glowing report in a year or so 
: about the huge cost savings, and then a couple years later 
: will be an Inspector General report about problems counting 
: things.

And he will get his money, so the counting will get done. 
Bigger budget, more responsibility, more scope of authority,
higher pay.  Not the IE just gov't managers in general.


: If that's what taxpayers want, that's what they'll get.

Taxpayers get no say in the process.  We can chant 'more
efficiency' all we want.  It's just water on a duck's back.
Nothing will change.  Like an ant trying to turn a tank.

scott




From lorell at hathcock.org  Mon Mar 14 20:47:03 2016
From: lorell at hathcock.org (Lorell Hathcock)
Date: Mon, 14 Mar 2016 15:47:03 -0500
Subject: CALEA Requirements
Message-ID: <031701d17e32$aa36d5c0$fea48140$@hathcock.org>

NANOG:

 

Can someone point me to the current CALEA requirements?

 

As an ISP, should I be recording all internet traffic that passes my
routers?  Or do I only have to record when and if I receive a court order?

 

I'm not under any court order now, I just want to be sure that I am
compliant going forward in my capabilities.

 

Thanks!

 

Lorell Hathcock


From sean at donelan.com  Mon Mar 14 20:49:38 2016
From: sean at donelan.com (Sean Donelan)
Date: Mon, 14 Mar 2016 16:49:38 -0400 (EDT)
Subject: Why the US Government has so many data centers
In-Reply-To: <20160314132701.5CE29CFD@m0087793.ppops.net>
References: <20160314132701.5CE29CFD@m0087793.ppops.net>
Message-ID: <alpine.BSF.2.20.1603141645390.77060@cnex.qbaryna.pbz>

On Mon, 14 Mar 2016, Scott Weeks wrote:
> It's all phunny money.  Real economics are not even considered.
> At all.

And what makes your think the Data Center Optimization Initiative is any 
different, when they are counting single servers instead of data centers?

If it was a rational, coherent plan; that would be great.  Instead I see 
lots of people spending years looking for servers, and writing reports 
about counting servers, and moving servers from on room to another room. 
What's the return on investment counting paperclips?

Declare victory now.


From fw at deneb.enyo.de  Mon Mar 14 20:54:44 2016
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 14 Mar 2016 21:54:44 +0100
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603111535590.47536@cnex.qbaryna.pbz> (Sean
 Donelan's message of "Fri, 11 Mar 2016 15:38:40 -0500 (EST)")
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <alpine.BSF.2.20.1603111535590.47536@cnex.qbaryna.pbz>
Message-ID: <87vb4oye3v.fsf@mid.deneb.enyo.de>

* Sean Donelan:

> When you say "data center" to an ordinary, average person or reporter;
> they think of big buildings filled with racks of computers.  Not a
> lonely server sitting in a test lab or under someone's desk.

I suspect part of the initiative is to get rid of that mindset, which
leads to such gems as ?we don't have any servers, so we only need to
secure our clients?.

From surfer at mauigateway.com  Mon Mar 14 20:57:56 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 14 Mar 2016 13:57:56 -0700
Subject: CALEA Requirements
Message-ID: <20160314135756.5CE29921@m0087793.ppops.net>



--- lorell at hathcock.org wrote:
From: "Lorell Hathcock" <lorell at hathcock.org>

Can someone point me to the current CALEA requirements?

As an ISP, should I be recording all internet traffic that passes my
routers?  Or do I only have to record when and if I receive a court order?

I'm not under any court order now, I just want to be sure that I am
compliant going forward in my capabilities.
-----------------------------------------


This is something your company's lawyers should hash out.  
That said, you shouldn't record anything unless forced to 
do so.  It'll just make pervasive surveillance easier.

scott

From mikea at mikea.ath.cx  Mon Mar 14 21:06:24 2016
From: mikea at mikea.ath.cx (mikea)
Date: Mon, 14 Mar 2016 16:06:24 -0500
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603141645390.77060@cnex.qbaryna.pbz>
References: <20160314132701.5CE29CFD@m0087793.ppops.net>
 <alpine.BSF.2.20.1603141645390.77060@cnex.qbaryna.pbz>
Message-ID: <20160314210624.GD56385@mikea.ath.cx>

On Mon, Mar 14, 2016 at 04:49:38PM -0400, Sean Donelan wrote:
> On Mon, 14 Mar 2016, Scott Weeks wrote:
> > It's all phunny money.  Real economics are not even considered.
> > At all.
> 
> And what makes your think the Data Center Optimization Initiative is any 
> different, when they are counting single servers instead of data centers?
> 
> If it was a rational, coherent plan; that would be great.  Instead I see 
> lots of people spending years looking for servers, and writing reports 
> about counting servers, and moving servers from on room to another room. 
> What's the return on investment counting paperclips?

But when they're finished, they'll have the serial number of each individual
paperclip, and a paperclip history form to go with it. 

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

From surfer at mauigateway.com  Mon Mar 14 21:11:14 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 14 Mar 2016 14:11:14 -0700
Subject: Why the US Government has so many data centers
Message-ID: <20160314141114.5CE29BEB@m0087793.ppops.net>


--- sean at donelan.com wrote:
From: Sean Donelan <sean at donelan.com>
On Mon, 14 Mar 2016, Scott Weeks wrote:

> It's all phunny money.  Real economics are not even 
> considered.  At all.

: And what makes your think the Data Center Optimization 
: Initiative is any different, when they are counting 
: single servers instead of data centers?

I don't think it's different.  It's more of the same 
insanity.


: If it was a rational, coherent plan; that would be great
: Instead I see lots of people spending years looking for 
: servers, and writing reports about counting servers, and 
: moving servers from on room to another room. 

That's the world of top-heavy management.  Not just in the
gov't, but in many orgs.  It's just worse in the gov't due
to the sheer size of the workforce there.  It's not rational 
and there're just too many middle management people fighting 
for their own increase in scope of authority for coherency.


: What's the return on investment counting paperclips?

This is the phunny money comment.  In the real world we
deal with real ROI or the business fails.  In their world, 
there is no such thing.


: Declare victory now.

They did that a long time ago in other areas.  Apparently, 
this is just the next one...  ;-)

scott






From keiths at neilltech.com  Mon Mar 14 21:11:39 2016
From: keiths at neilltech.com (Keith Stokes)
Date: Mon, 14 Mar 2016 21:11:39 +0000
Subject: Why the US Government has so many data centers
In-Reply-To: <20160314210624.GD56385@mikea.ath.cx>
References: <20160314132701.5CE29CFD@m0087793.ppops.net>
 <alpine.BSF.2.20.1603141645390.77060@cnex.qbaryna.pbz>
 <20160314210624.GD56385@mikea.ath.cx>
Message-ID: <1228259F-1E92-43F6-B3B5-5803E7A8C506@neilltech.com>

Plus a subsequent GAO report accounting for a miscount due to using paperclips on the history forms.

On Mar 14, 2016, at 4:06 PM, mikea <mikea at mikea.ath.cx<mailto:mikea at mikea.ath.cx>> wrote:

On Mon, Mar 14, 2016 at 04:49:38PM -0400, Sean Donelan wrote:
On Mon, 14 Mar 2016, Scott Weeks wrote:
It's all phunny money.  Real economics are not even considered.
At all.

And what makes your think the Data Center Optimization Initiative is any
different, when they are counting single servers instead of data centers?

If it was a rational, coherent plan; that would be great.  Instead I see
lots of people spending years looking for servers, and writing reports
about counting servers, and moving servers from on room to another room.
What's the return on investment counting paperclips?

But when they're finished, they'll have the serial number of each individual
paperclip, and a paperclip history form to go with it.

--
Mike Andrews, W5EGO
mikea at mikea.ath.cx<mailto:mikea at mikea.ath.cx>
Tired old sysadmin


---

Keith Stokes





From Steve.Mikulasik at civeo.com  Mon Mar 14 21:16:15 2016
From: Steve.Mikulasik at civeo.com (Steve Mikulasik)
Date: Mon, 14 Mar 2016 21:16:15 +0000
Subject: Why the US Government has so many data centers
In-Reply-To: <20160314210624.GD56385@mikea.ath.cx>
References: <20160314132701.5CE29CFD@m0087793.ppops.net>
 <alpine.BSF.2.20.1603141645390.77060@cnex.qbaryna.pbz>
 <20160314210624.GD56385@mikea.ath.cx>
Message-ID: <CY1PR07MB22000EC35AA7EAA05E4EED67FA880@CY1PR07MB2200.namprd07.prod.outlook.com>


Yeah, but at the end we will have reduced paper clip losses significantly! Of course paper clip usage will go up to support the new paper clip auditing department.


-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of mikea
Sent: Monday, March 14, 2016 3:06 PM
To: nanog at nanog.org
Subject: Re: Why the US Government has so many data centers

On Mon, Mar 14, 2016 at 04:49:38PM -0400, Sean Donelan wrote:
> On Mon, 14 Mar 2016, Scott Weeks wrote:
> > It's all phunny money.  Real economics are not even considered.
> > At all.
> 
> And what makes your think the Data Center Optimization Initiative is 
> any different, when they are counting single servers instead of data centers?
> 
> If it was a rational, coherent plan; that would be great.  Instead I 
> see lots of people spending years looking for servers, and writing 
> reports about counting servers, and moving servers from on room to another room.
> What's the return on investment counting paperclips?

But when they're finished, they'll have the serial number of each individual paperclip, and a paperclip history form to go with it. 

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


From todd.crane at n5tech.com  Mon Mar 14 22:26:34 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Mon, 14 Mar 2016 16:26:34 -0600
Subject: E911 (was CALEA Requirements)
In-Reply-To: <20160314135756.5CE29921@m0087793.ppops.net>
References: <20160314135756.5CE29921@m0087793.ppops.net>
Message-ID: <A5ACF3E4-657D-419C-99BA-E87836346166@n5tech.com>


While we're at it, can somebody point me on the right path for E911. I'm not looking for a managed service but rather an in-house solution.

Todd Crane

> On Mar 14, 2016, at 2:57 PM, Scott Weeks <surfer at mauigateway.com> wrote:
> 
> 
> 
> --- lorell at hathcock.org wrote:
> From: "Lorell Hathcock" <lorell at hathcock.org>
> 
> Can someone point me to the current CALEA requirements?
> 
> As an ISP, should I be recording all internet traffic that passes my
> routers?  Or do I only have to record when and if I receive a court order?
> 
> I'm not under any court order now, I just want to be sure that I am
> compliant going forward in my capabilities.
> -----------------------------------------
> 
> 
> This is something your company's lawyers should hash out.  
> That said, you shouldn't record anything unless forced to 
> do so.  It'll just make pervasive surveillance easier.
> 
> scott

From david.soltero at icann.org  Tue Mar 15 01:04:13 2016
From: david.soltero at icann.org (David Soltero)
Date: Tue, 15 Mar 2016 01:04:13 +0000
Subject: L-Root IPv6 address renumbering
In-Reply-To: <20160312220543.GE80711@22.rev.meerval.net>
References: <4AA7E64A-A96E-4E2E-9F13-E3E33315D06D@icann.org>
 <20160312220543.GE80711@22.rev.meerval.net>
Message-ID: <B55BDD81-803A-4C06-9D8E-41E36A6C0CF1@icann.org>

Hi Job,

the following was posted earlier on another list ...


The rationale behind the renumbering is that the current IPv6 prefix,
2001:500:3::/48, comes as a direct minimum assignment. We were unable to
expand that allocation to a /47. What we (and I'm sure others) have
noticed is that ISPs and transit providers filter on allocation
boundaries, and constrain RIBs to the minimum allocation size. So our
reach for doing traffic engineering with a /48 is quite limited, noting
the first step in the BGP route selection state machine is generally the
prefix length.

The new address (2001:500:9f::42) sits in the prefix 2001:500:9E::/47,
which then allows us to get 'reach' of the more specific 2001:500:9F::/48
for traffic engineering purposes when we need it across the L-Root
constellation on IPv6.

We do this already on IPv4 using 199.7.82.0/23 and 199.7.83.0/24.

Hope this helps.




On 3/12/16, 5:05 PM, "Job Snijders" <job at instituut.net> wrote:

>Hi David,
>
>On Wed, Mar 09, 2016 at 09:06:20PM +0000, David Soltero wrote:
>> This is advance notice that there is a scheduled change to the IPv6
>> addresses in the Root Zone for the L root-server, also known as
>> L.ROOT-SERVERS.NET, which is administered by the ICANN.
>> 
>> The current IP addresses for the L.ROOT-SERVERS.NET service are:
>> 2001:500:3::42
>> 
>> As of March 23, 2016, the new IP addresses for the L.ROOT-SERVERS.NET service will be:
>> 2001:500:9f::42
>> 
>> The change will be implemented on the root zone on March 23, 2016
>> 2100UTC,  however the new address is already operational.
>
>Can you elaborate on why this change is being introduced?
>
>Kind regards,
>
>Job

From mhardeman at ipifony.com  Tue Mar 15 02:40:02 2016
From: mhardeman at ipifony.com (Matthew D. Hardeman)
Date: Mon, 14 Mar 2016 21:40:02 -0500
Subject: Cogent - Google - HE Fun
In-Reply-To: <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
Message-ID: <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>

It looks like Google is experimenting with a change in course on this issue.

Here?s a look at the IPv6 routing table tonight on my router bordering Cogent.

*>i 2607:f8b0:4013::/48
                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
                                          0        150          0       15169 i
*                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
                                          0        90           0       174 6461 15169 i
*>i 2607:f8b0:4014::/48
                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
                                          0        110          0       6939 6461 15169 i
*                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
                                          0        90           0       174 6461 15169 i
*>i 2607:f8b0:4016::/48
                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
                                          0        150          0       15169 i
*                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
                                          0        90           0       174 6461 15169 i


This is only 3 IPv6 prefixes (out of 47 prefixes seen in my IPv6 routing table).  Two of these prefixes I see via direct peering with Google and, alternatively, via Cogent through Zayo transit.  One of these prefixes doesn?t advertise in Google?s direct peering session (at least not in mine, but HE picks it up via Zayo and Cogent picks it up via Zayo).

All of these are /48 subnets of their greater 2620:f8b0::/32 prefix, which does show up in both their direct session and in HE via Zayo.


> On Mar 13, 2016, at 9:31 AM, Dennis Burgess <dmburgess at linktechs.net> wrote:
> 
> In the end, google has made a choice. I think these kinds of choices will delay IPv6 adoption.  
> 
> -----Original Message-----
> From: Damien Burke [mailto:damien at supremebytes.com] 
> Sent: Friday, March 11, 2016 2:51 PM
> To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>; Dennis Burgess <dmburgess at linktechs.net>
> Cc: North American Network Operators' Group <nanog at nanog.org>
> Subject: RE: Cogent - Google - HE Fun
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4190 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160314/e40451d2/attachment.bin>

From todd.crane at n5tech.com  Tue Mar 15 04:50:43 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Mon, 14 Mar 2016 22:50:43 -0600
Subject: Cogent - Google - HE Fun
In-Reply-To: <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
Message-ID: <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>


> This is only tangentially related but it looks like HE has surpassed Cogent on IPv4 adjacencies. That said the source probably suffers from a selection bias at the very least.
> 
> http://bgp.he.net/report/peers
> 
> 
Hit reply by mistake instead of reply all. 

> Todd Crane
> 
>> On Mar 14, 2016, at 8:40 PM, Matthew D. Hardeman <mhardeman at ipifony.com> wrote:
>> 
>> It looks like Google is experimenting with a change in course on this issue.
>> 
>> Here?s a look at the IPv6 routing table tonight on my router bordering Cogent.
>> 
>> *>i 2607:f8b0:4013::/48
>>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
>>                                          0        150          0       15169 i
>> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
>>                                          0        90           0       174 6461 15169 i
>> *>i 2607:f8b0:4014::/48
>>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
>>                                          0        110          0       6939 6461 15169 i
>> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
>>                                          0        90           0       174 6461 15169 i
>> *>i 2607:f8b0:4016::/48
>>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
>>                                          0        150          0       15169 i
>> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
>>                                          0        90           0       174 6461 15169 i
>> 
>> 
>> This is only 3 IPv6 prefixes (out of 47 prefixes seen in my IPv6 routing table).  Two of these prefixes I see via direct peering with Google and, alternatively, via Cogent through Zayo transit.  One of these prefixes doesn?t advertise in Google?s direct peering session (at least not in mine, but HE picks it up via Zayo and Cogent picks it up via Zayo).
>> 
>> All of these are /48 subnets of their greater 2620:f8b0::/32 prefix, which does show up in both their direct session and in HE via Zayo.
>> 
>> 
>>> On Mar 13, 2016, at 9:31 AM, Dennis Burgess <dmburgess at linktechs.net> wrote:
>>> 
>>> In the end, google has made a choice. I think these kinds of choices will delay IPv6 adoption.  
>>> 
>>> -----Original Message-----
>>> From: Damien Burke [mailto:damien at supremebytes.com] 
>>> Sent: Friday, March 11, 2016 2:51 PM
>>> To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>; Dennis Burgess <dmburgess at linktechs.net>
>>> Cc: North American Network Operators' Group <nanog at nanog.org>
>>> Subject: RE: Cogent - Google - HE Fun
>>> 
>>> Just received an updated statement from cogent support:
>>> 
>>> "We appreciate your concerns. This is a known issue that originates with Google as it is up to their discretion as to how they announce routes to us v4 or v6. 
>>> 
>>> Once again, apologies for any inconvenience."
>>> 
>>> And:
>>> 
>>> "The SLA does not cover route transit beyond our network. We cannot route to IPs that are not announced to us by the IP owner, directly or through a network peer."
>> 

From mark.tinka at seacom.mu  Tue Mar 15 06:01:15 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 15 Mar 2016 08:01:15 +0200
Subject: Juniper MX Sizing
In-Reply-To: <CAMDdSzPZETMsr+HHhew6jW5cbQwumz_2375wv+udueO5QoMpaA@mail.gmail.com>
References: <49EE1A35457387418410F97564A3752B01365DC78E@MSG6.westman.int>
 <FC74C7D2-4613-46A4-BD9E-EABF39F3E5C0@tripadvisor.com>
 <49EE1A35457387418410F97564A3752B01365DC8C7@MSG6.westman.int>
 <E4080A77-0042-4BBA-A090-F653A0354861@gmail.com>
 <D3E1DD54-005A-4CB1-A063-1677E22417FB@tripadvisor.com>
 <C860F293-22A7-48D6-B156-4F5A285A29EE@gmail.com>
 <CAMDdSzMZWQW-aHxgHhvWjNeUk46rEGK-LJNEFDo5SF_NENuO6A@mail.gmail.com>
 <88ec265f-9df6-2bf0-fe18-5fb48a2b63ff@seacom.mu>
 <CAMDdSzPZETMsr+HHhew6jW5cbQwumz_2375wv+udueO5QoMpaA@mail.gmail.com>
Message-ID: <c5dc790b-4b1b-de36-e484-0bb3e4bcfb86@seacom.mu>



On 14/Mar/16 14:35, Colton Conor wrote:

> Mark,
>
> You are right that makes sense. So as a recap, you were seeing about
> 45 seconds route convergence time using RE-S-1800x4 w/ 16GB RAM. For a
> MX104 it took 4min 25sec. I assume a MX80 would be even slower than an
> MX104.
>
> What about a MX480 with RE-2000's with 4GB of ram? Does anyone have
> any stats on that? I would assume faster than a MX104 but slower than
> the RE-S-1800x4 w/ 16GB RAM.

I don't have empirical data, but yes, the MX80 and MX104 will be way
slower across the board.

Mark.

From florian at figula.de  Tue Mar 15 11:26:58 2016
From: florian at figula.de (Florian Figula)
Date: Tue, 15 Mar 2016 12:26:58 +0100
Subject: AW: Cisco Fabricpath
In-Reply-To: <CAJUfXzcwPgS14e=cMb=+npVvu2P8Mzri3tseJBpTsdC9rKK-Tg@mail.gmail.com>
References: <CAJDSeq2BYhgBkSMA2uiynaLWFWt_RQ9aqyp5=pnjExSWthA_aw@mail.gmail.com>
 <CAJUfXzcwPgS14e=cMb=+npVvu2P8Mzri3tseJBpTsdC9rKK-Tg@mail.gmail.com>
Message-ID: <022101d17ead$96be4930$c43adb90$@figula.de>

Hi Ulf,

I am currently running a fabric path setup with four Nexus 5548UP for a customer. We had several problems followed by mysterious packet loss when upgrading from NX-OS 5.2(1)N1(4) to 7.0(5)N1(1) in case of leap second update. Cisco TAC advised me to downgrade after the event on 1st of July in 2015 due to CSCuo56514. This Bug should first be fixed in 7.0(7)N1(1). Presently this is the recommended IOS-XE for N5K. My customer is currently running 5.2(1)N1(9) without any problems.


Regards,

Florian

-----Urspr?ngliche Nachricht-----
Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Ulf Zimmermann
Gesendet: Samstag, 12. M?rz 2016 22:37
An: Nicolas V <nicovpp59 at gmail.com>
Cc: nanog at nanog.org
Betreff: Re: Cisco Fabricpath

I have used it for a cage in one datacenter, it was built 2+ years ago. It hasn't been giving us problems, with the exception of several bad Cisco direct attached copper cables.


On Mon, Mar 7, 2016 at 7:55 AM, Nicolas V <nicovpp59 at gmail.com> wrote:

> Hello,
>
> Does anyone already played with cisco fabricpath feature ? I want to 
> use it on my nexus 5548
>
> Is it working as easy as it seems ? No bugs / particular nx-os version... ?
>
> Thanks !
> Nicolas
>



-- 

Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html


From mark.tinka at seacom.mu  Wed Mar 16 07:40:28 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 16 Mar 2016 09:40:28 +0200
Subject: Low density Juniper (or alternative) Edge
In-Reply-To: <CAEQS+Yc=c4LfeAJDZk+FqW_nB4B-fZSn_C8+_bAUz_A9n=db7w@mail.gmail.com>
References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com>
 <56B1B32E.4030609@foobar.org>
 <0a03a53f-b7c1-52e0-800f-9bce6f87ca08@seacom.mu>
 <CAEQS+Yc=c4LfeAJDZk+FqW_nB4B-fZSn_C8+_bAUz_A9n=db7w@mail.gmail.com>
Message-ID: <b205c8eb-bdc1-c99b-ef43-da1ba3ac2f1d@seacom.mu>



On 15/Mar/16 20:14, ML-NANOG-Stefan-Jakob wrote:

>
> Do yo have more details what's wrong with the XR platform?
>
> Which hardware do we talk about and which XR version is your statement
> applying?

Well, as it turns out, I just found out and confirmed that since IOS XE
3.12S and later, Cisco introduced a new feature called Aggregate
EtherChannel Quality of Service:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-3s/asr1000/qos-mqc-xe-3s-asr1000-book/qos-mqc-xe-3s-asr1000-book_chapter_01011.html

With this, you can now apply a QoS policy on a LAG port and it will work
with (almost) all QoS features without you needing to apply the policies
on the LAG member links. I still need to spend some more time testing
the policing side of things, particularly how the data plane is
programmed re: carving of configured bandwidth across member ports in
the LAG.

I also see some good work being done on the ASR920 platform (also an IOS
XE-based system), as per below:

http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/qos/qos-guidelines-xe-3-13-asr920-book.html#ID-1374-00000345

From what I can gather, none of this love has made it to IOS or IOS XR
boxes.

So quite pleased with what I'm seeing with Cisco so far in this regard...

Mark.


From bohn at adelphi.edu  Wed Mar 16 13:56:59 2016
From: bohn at adelphi.edu (Dennis Bohn)
Date: Wed, 16 Mar 2016 09:56:59 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
Message-ID: <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>

So if someone (say an eyeball network) was putting out a RFQ for a gig say
of upstream cxn and wanted to spec full reachability to the full V6 net,
what would the wording for that spec look like?
Would that get $provider's attention?
On Mar 15, 2016 12:50 AM, "Todd Crane" <todd.crane at n5tech.com> wrote:

>
> > This is only tangentially related but it looks like HE has surpassed
> Cogent on IPv4 adjacencies. That said the source probably suffers from a
> selection bias at the very least.
> >
> > http://bgp.he.net/report/peers
> >
> >
> Hit reply by mistake instead of reply all.
>
> > Todd Crane
> >
> >> On Mar 14, 2016, at 8:40 PM, Matthew D. Hardeman <mhardeman at ipifony.com>
> wrote:
> >>
> >> It looks like Google is experimenting with a change in course on this
> issue.
> >>
> >> Here?s a look at the IPv6 routing table tonight on my router bordering
> Cogent.
> >>
> >> *>i 2607:f8b0:4013::/48
> >>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
> >>                                          0        150          0
>  15169 i
> >> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
> >>                                          0        90           0
>  174 6461 15169 i
> >> *>i 2607:f8b0:4014::/48
> >>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
> >>                                          0        110          0
>  6939 6461 15169 i
> >> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
> >>                                          0        90           0
>  174 6461 15169 i
> >> *>i 2607:f8b0:4016::/48
> >>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
> >>                                          0        150          0
>  15169 i
> >> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
> >>                                          0        90           0
>  174 6461 15169 i
> >>
> >>
> >> This is only 3 IPv6 prefixes (out of 47 prefixes seen in my IPv6
> routing table).  Two of these prefixes I see via direct peering with Google
> and, alternatively, via Cogent through Zayo transit.  One of these prefixes
> doesn?t advertise in Google?s direct peering session (at least not in mine,
> but HE picks it up via Zayo and Cogent picks it up via Zayo).
> >>
> >> All of these are /48 subnets of their greater 2620:f8b0::/32 prefix,
> which does show up in both their direct session and in HE via Zayo.
> >>
> >>
> >>> On Mar 13, 2016, at 9:31 AM, Dennis Burgess <dmburgess at linktechs.net>
> wrote:
> >>>
> >>> In the end, google has made a choice. I think these kinds of choices
> will delay IPv6 adoption.
> >>>
> >>> -----Original Message-----
> >>> From: Damien Burke [mailto:damien at supremebytes.com]
> >>> Sent: Friday, March 11, 2016 2:51 PM
> >>> To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>;
> Dennis Burgess <dmburgess at linktechs.net>
> >>> Cc: North American Network Operators' Group <nanog at nanog.org>
> >>> Subject: RE: Cogent - Google - HE Fun
> >>>
> >>> Just received an updated statement from cogent support:
> >>>
> >>> "We appreciate your concerns. This is a known issue that originates
> with Google as it is up to their discretion as to how they announce routes
> to us v4 or v6.
> >>>
> >>> Once again, apologies for any inconvenience."
> >>>
> >>> And:
> >>>
> >>> "The SLA does not cover route transit beyond our network. We cannot
> route to IPs that are not announced to us by the IP owner, directly or
> through a network peer."
> >>
>

From morrowc.lists at gmail.com  Wed Mar 16 14:06:56 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 16 Mar 2016 10:06:56 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
Message-ID: <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>

On Wed, Mar 16, 2016 at 9:56 AM, Dennis Bohn <bohn at adelphi.edu> wrote:
> So if someone (say an eyeball network) was putting out a RFQ for a gig say
> of upstream cxn and wanted to spec full reachability to the full V6 net,
> what would the wording for that spec look like?
> Would that get $provider's attention?

"We would like transit services to the full ipv4 and ipv6 addressable
space, we would like our prefixes to be advertised to the whole of the
above space as well."

then you'd by one (some) connection(s) from 'best option #1' and
one(some) connection(s) to 'next best option'.

I'm not sure 'rfq' is required here is it? you just call the caida
top-10/15 and roll based on cost/performance. There are notable
exceptions to network performance (routing performance?) but really
they are all the same now, yes?

perhaps you would be more concerned not with 'ipv6/v4 reachability'
than with how what your customers access (may access in the future) is
reachable from the providers in question? and potentially what knobs
the providers expose to you for bgp TE functionality?

> On Mar 15, 2016 12:50 AM, "Todd Crane" <todd.crane at n5tech.com> wrote:
>
>>
>> > This is only tangentially related but it looks like HE has surpassed
>> Cogent on IPv4 adjacencies. That said the source probably suffers from a
>> selection bias at the very least.
>> >
>> > http://bgp.he.net/report/peers
>> >
>> >
>> Hit reply by mistake instead of reply all.
>>
>> > Todd Crane
>> >
>> >> On Mar 14, 2016, at 8:40 PM, Matthew D. Hardeman <mhardeman at ipifony.com>
>> wrote:
>> >>
>> >> It looks like Google is experimenting with a change in course on this
>> issue.
>> >>
>> >> Here?s a look at the IPv6 routing table tonight on my router bordering
>> Cogent.
>> >>
>> >> *>i 2607:f8b0:4013::/48
>> >>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
>> >>                                          0        150          0
>>  15169 i
>> >> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
>> >>                                          0        90           0
>>  174 6461 15169 i
>> >> *>i 2607:f8b0:4014::/48
>> >>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
>> >>                                          0        110          0
>>  6939 6461 15169 i
>> >> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
>> >>                                          0        90           0
>>  174 6461 15169 i
>> >> *>i 2607:f8b0:4016::/48
>> >>                    2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
>> >>                                          0        150          0
>>  15169 i
>> >> *                    2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
>> >>                                          0        90           0
>>  174 6461 15169 i
>> >>
>> >>
>> >> This is only 3 IPv6 prefixes (out of 47 prefixes seen in my IPv6
>> routing table).  Two of these prefixes I see via direct peering with Google
>> and, alternatively, via Cogent through Zayo transit.  One of these prefixes
>> doesn?t advertise in Google?s direct peering session (at least not in mine,
>> but HE picks it up via Zayo and Cogent picks it up via Zayo).
>> >>
>> >> All of these are /48 subnets of their greater 2620:f8b0::/32 prefix,
>> which does show up in both their direct session and in HE via Zayo.
>> >>
>> >>
>> >>> On Mar 13, 2016, at 9:31 AM, Dennis Burgess <dmburgess at linktechs.net>
>> wrote:
>> >>>
>> >>> In the end, google has made a choice. I think these kinds of choices
>> will delay IPv6 adoption.
>> >>>
>> >>> -----Original Message-----
>> >>> From: Damien Burke [mailto:damien at supremebytes.com]
>> >>> Sent: Friday, March 11, 2016 2:51 PM
>> >>> To: Mark Tinka <mark.tinka at seacom.mu>; Owen DeLong <owen at delong.com>;
>> Dennis Burgess <dmburgess at linktechs.net>
>> >>> Cc: North American Network Operators' Group <nanog at nanog.org>
>> >>> Subject: RE: Cogent - Google - HE Fun
>> >>>
>> >>> Just received an updated statement from cogent support:
>> >>>
>> >>> "We appreciate your concerns. This is a known issue that originates
>> with Google as it is up to their discretion as to how they announce routes
>> to us v4 or v6.
>> >>>
>> >>> Once again, apologies for any inconvenience."
>> >>>
>> >>> And:
>> >>>
>> >>> "The SLA does not cover route transit beyond our network. We cannot
>> route to IPs that are not announced to us by the IP owner, directly or
>> through a network peer."
>> >>
>>

From baldur.norddahl at gmail.com  Wed Mar 16 14:58:05 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Wed, 16 Mar 2016 15:58:05 +0100
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
Message-ID: <CAPkb-7Bac_LzzKQ5Usv32pyZ6su+PapR3RPnWdHAkeMmQ7CXcg@mail.gmail.com>

On 16 March 2016 at 14:56, Dennis Bohn <bohn at adelphi.edu> wrote:

> So if someone (say an eyeball network) was putting out a RFQ for a gig say
> of upstream cxn and wanted to spec full reachability to the full V6 net,
> what would the wording for that spec look like?
> Would that get $provider's attention?
>

But is that even possible to deliver? I might have some address space that
I only advertised with no export to a single peer - does that count? If
some third party decides to stop advertising a prefix to $provider are they
then in breach of contract with no way to resolve it? If so, I want to sign
up and then I will pull some insignificant prefix, just so I can demand $5
million USD in ransom money.

Google decided they have some prefixes they don't want to advertise to
Cogent. They did offer a reasonable way for Cogent to resolve that issue,
but what if Google werent reasonable? Do you still demand that Cogent cave
in to anything?

I see no easy way here other than let the market decide. If Cogent sucks
they will get less traffic and less customers. Or maybe someone finds them
useful at the pricepoint they offer.

Regards,

Baldur

From bohn at adelphi.edu  Wed Mar 16 15:22:05 2016
From: bohn at adelphi.edu (Dennis Bohn)
Date: Wed, 16 Mar 2016 11:22:05 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
Message-ID: <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>

On Mar 16, 2016 10:06 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
wrote:
>
> On Wed, Mar 16, 2016 at 9:56 AM, Dennis Bohn <bohn at adelphi.edu> wrote:
> > So if someone (say an eyeball network) was putting out a RFQ for a gig
say
> > of upstream cxn and wanted to spec full reachability to the full V6 net,
> > what would the wording for that spec look like?
> > Would that get $provider's attention?
>
> "We would like transit services to the full ipv4 and ipv6 addressable
> space, we would like our prefixes to be advertised to the whole of the
> above space as well."
>
> then you'd by one (some) connection(s) from 'best option #1' and
> one(some) connection(s) to 'next best option'.
>
> I'm not sure 'rfq' is required here is it? ....

I was thinking RFQ with specific requirements might get cogent attention
more than a call. Sure they wouldn't change policy for me, but if they were
unable to meet quote requirements repeatedly it might have some effect...
or am I dreaming?

              and potentially what knobs
> the providers expose to you for bgp TE functionality?

Good thought to include that. Tnx.
D.

From bill at herrin.us  Wed Mar 16 15:32:12 2016
From: bill at herrin.us (William Herrin)
Date: Wed, 16 Mar 2016 11:32:12 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
Message-ID: <CAP-guGVrNUzbHhQs7n5Jfz8zr1t9yCpDX1skPfcuqxZeDVKgXg@mail.gmail.com>

On Wed, Mar 16, 2016 at 9:56 AM, Dennis Bohn <bohn at adelphi.edu> wrote:
> So if someone (say an eyeball network) was putting out a RFQ for a gig say
> of upstream cxn and wanted to spec full reachability to the full V6 net,
> what would the wording for that spec look like?

Maybe require something roughly like this in the SLA:

"Customer may notify Provider upon discovery of a network Partition. A
Partition exists when correct BGP routes available via at least 90% of
comparable Internet service providers are absent from Provider's BGP
feed or do not otherwise function. Where such Partition persists for
at least 6 hours from notification, Provider shall make a 100% service
credit starting from notification. Where such Partition persists for
at least 24 hours, Customer may terminate this contract without
penalty until 30 days following the Partition's end."

> Would that get $provider's attention?

No. They'll either agree blindly or consider you a hard case. Either
way it won't change their actual behavior.

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  Wed Mar 16 15:32:29 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 16 Mar 2016 08:32:29 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
 <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
Message-ID: <7B7CD553-0522-43A6-BF90-02C4F7C28698@delong.com>


I think the RFQ idea isn?t a bad one, but I doubt it will have any effect.

Cogent already knows that they have customers leaving because of their peering wars. They
don?t seem to care.

However, if it?s going to be effective, I think the RFQ has to be achievable by most other
networks.

I propose:

????
Provider must demonstrate a peering policy conducive to maintaining reachability to all
publicly advertised space on the internet. Provider must show that they have reachability
to all autonomous systems visible from route-views or other publicly accessible looking
glass system(s). Provider must demonstrate these capabilities for both IPv4 and IPv6.
????

In this way, you?ve got a succinct, easily achievable criteria that roughly approximates
full routes and a relatively clear message that restrictive ?pay us or forget about reaching
our subscribers? peering policy isn?t going to get them selected as your provider.

Owen


From morrowc.lists at gmail.com  Wed Mar 16 15:41:39 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 16 Mar 2016 11:41:39 -0400
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
 <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
Message-ID: <CAL9jLab9NrPRcsOrRseP8pDV-er1Dyiom6h3pJ5XXn55H3V8kg@mail.gmail.com>

On Wed, Mar 16, 2016 at 11:22 AM, Dennis Bohn <bohn at adelphi.edu> wrote:
>
> On Mar 16, 2016 10:06 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
> wrote:
>>
>> On Wed, Mar 16, 2016 at 9:56 AM, Dennis Bohn <bohn at adelphi.edu> wrote:
>> > So if someone (say an eyeball network) was putting out a RFQ for a gig
>> > say
>> > of upstream cxn and wanted to spec full reachability to the full V6 net,
>> > what would the wording for that spec look like?
>> > Would that get $provider's attention?
>>
>> "We would like transit services to the full ipv4 and ipv6 addressable
>> space, we would like our prefixes to be advertised to the whole of the
>> above space as well."
>>
>> then you'd by one (some) connection(s) from 'best option #1' and
>> one(some) connection(s) to 'next best option'.
>>
>> I'm not sure 'rfq' is required here is it? ....
>
> I was thinking RFQ with specific requirements might get cogent attention
> more than a call. Sure they wouldn't change policy for me, but if they were
> unable to meet quote requirements repeatedly it might have some effect... or
> am I dreaming?
>

my guess is the same as Owen's ... 'your rfq don't mean squat'.
honestly it's not like people don't ask their cogent sales folk for
this sort of thing, it's just not cogent's (clearly, given how long
the HE/Cogent thing along has persisted) way of doing things.

Sometimes your belief system just isn't theirs.

>               and potentially what knobs
>> the providers expose to you for bgp TE functionality?
>
> Good thought to include that. Tnx.
> D.

From mark.tinka at seacom.mu  Wed Mar 16 18:43:22 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 16 Mar 2016 20:43:22 +0200
Subject: Cogent - Google - HE Fun
In-Reply-To: <CAL9jLab9NrPRcsOrRseP8pDV-er1Dyiom6h3pJ5XXn55H3V8kg@mail.gmail.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
 <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
 <CAL9jLab9NrPRcsOrRseP8pDV-er1Dyiom6h3pJ5XXn55H3V8kg@mail.gmail.com>
Message-ID: <933ae78f-a745-0ad4-7ff5-6f887345e444@seacom.mu>



On 16/Mar/16 17:41, Christopher Morrow wrote:

> my guess is the same as Owen's ... 'your rfq don't mean squat'.
> honestly it's not like people don't ask their cogent sales folk for
> this sort of thing, it's just not cogent's (clearly, given how long
> the HE/Cogent thing along has persisted) way of doing things.
>
> Sometimes your belief system just isn't theirs.

The first time I considered buying from Cogent was out of One Wilshire,
back in 2010. I did a 1-month PoC with them.

The global IPv6 BGP table was around 2,500 routes then. Cogent had only
100 or so, IIRC. I told them I would not sign with them due to this.

Fast-forward to 2012, nothing much had changed when they tried to get me
to buy from them again (out of London, this time), and I told them why.
Then in 2014, they tracked me down again and confirmed they then had a
full IPv6 BGP table. So I added them to my network (out of Amsterdam).

Cogent form part of the 7x upstreams I have (not to mention all the
peering we do). So if they de-peer some network, we aren't stuck. I have
them on my network because they add value to some paths on the Internet,
and not because of price.

I'm one guy, so I can't say whether my actions over the years prompted a
warm body within the Cogent machine to rethink their IPv6 strategy. But
I think if you refuse to buy from them on principles that matter to you,
and you tell them why, it could help. If it doesn't, move on - it won't
be your loss.

I would, though, say that the amount of support this list is giving
Cogent to keep their heart beating is astounding. If there was ever a
time for them to listen to their environment, this would be it. But alas...

Mark.


From eric.kuhnke at gmail.com  Wed Mar 16 18:45:26 2016
From: eric.kuhnke at gmail.com (Eric Kuhnke)
Date: Wed, 16 Mar 2016 11:45:26 -0700
Subject: collectd as alternative to RTG for high-resolution polling and long
 term storage?
Message-ID: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>

Would anyone care to share their experience using collectd as an
alternative to rtg for high-resolution polling of interface traffic and
long term storage?

I am investigating the various options for large data set size, lossless
long term traffic charting (not RRAs which lose precision over time). One
possible use is precision 95th billing.

https://collectd.org/

From ulf at alameda.net  Wed Mar 16 19:20:35 2016
From: ulf at alameda.net (Ulf Zimmermann)
Date: Wed, 16 Mar 2016 12:20:35 -0700
Subject: collectd as alternative to RTG for high-resolution polling and
 long term storage?
In-Reply-To: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
References: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
Message-ID: <CAJUfXzeJrZxpP7bXugUy+afyrgYqke8+aHtJ2U=nsyD3_3rtkg@mail.gmail.com>

Be aware that collectd itself is a collection agent. It doesn't include
(last I checked) a grapher. There are however a number of graphers out
there to work with those RRD files, if you use that to store the data.

I personally have been using collectd across hundreds of Linux systems,
using rrdcached to a central collector and wrote my own grapher for that
stuff I am interested int.

Ulf.


On Wed, Mar 16, 2016 at 11:45 AM, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:

> Would anyone care to share their experience using collectd as an
> alternative to rtg for high-resolution polling of interface traffic and
> long term storage?
>
> I am investigating the various options for large data set size, lossless
> long term traffic charting (not RRAs which lose precision over time). One
> possible use is precision 95th billing.
>
> https://collectd.org/
>



-- 

Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764
You can find my resume at: http://www.Alameda.net/~ulf/resume.html

From owen at delong.com  Wed Mar 16 19:23:30 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 16 Mar 2016 12:23:30 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <933ae78f-a745-0ad4-7ff5-6f887345e444@seacom.mu>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
 <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
 <CAL9jLab9NrPRcsOrRseP8pDV-er1Dyiom6h3pJ5XXn55H3V8kg@mail.gmail.com>
 <933ae78f-a745-0ad4-7ff5-6f887345e444@seacom.mu>
Message-ID: <CE555794-F675-468B-B0CE-FEAB10282678@delong.com>


> On Mar 16, 2016, at 11:43 , Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 16/Mar/16 17:41, Christopher Morrow wrote:
> 
>> my guess is the same as Owen's ... 'your rfq don't mean squat'.
>> honestly it's not like people don't ask their cogent sales folk for
>> this sort of thing, it's just not cogent's (clearly, given how long
>> the HE/Cogent thing along has persisted) way of doing things.
>> 
>> Sometimes your belief system just isn't theirs.
> 
> The first time I considered buying from Cogent was out of One Wilshire,
> back in 2010. I did a 1-month PoC with them.
> 
> The global IPv6 BGP table was around 2,500 routes then. Cogent had only
> 100 or so, IIRC. I told them I would not sign with them due to this.
> 
> Fast-forward to 2012, nothing much had changed when they tried to get me
> to buy from them again (out of London, this time), and I told them why.
> Then in 2014, they tracked me down again and confirmed they then had a
> full IPv6 BGP table. So I added them to my network (out of Amsterdam).

Please confirm that you in fact are receiving 174 * 6939 IPv6 paths from them?

Seems unlikely to me.

Owen


From jlk at thrashyour.com  Wed Mar 16 19:29:53 2016
From: jlk at thrashyour.com (John Kinsella)
Date: Wed, 16 Mar 2016 12:29:53 -0700
Subject: collectd as alternative to RTG for high-resolution polling and
 long term storage?
In-Reply-To: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
References: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
Message-ID: <A4A7031D-3BB7-470F-AF8C-F2BB30A4A688@thrashyour.com>

Collectd is great, IMHO. I was using collectd+graphite to gather and display stats for a large collection of VMs, servers, routers, and switches. Collectd itself was pretty low overhead, easy to configure (I managed configs via puppet) and Just Worked.

Graphite and carbon cache were a little more tricky to set up - carbon by default aggregates/averages older data, so if not setup correctly, when you go back a few months and try to drill into a graph at a 5 minute interval, you get unexpected results.

I?d highly recommend looking at Graphite, as well. Once you get used to it, being able to apply functions[1] to aggregate, manipulate, and quickly find patterns in data is super useful (ex: look at all interfaces on this switch, only display graphs for the top 5 abnormal traffic). Jason Dixon has written some great blogs posts about it?s use on obfuscurity.com.

John
1: https://graphite.readthedocs.org/en/latest/functions.html

> On Mar 16, 2016, at 11:45 AM, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:
> 
> Would anyone care to share their experience using collectd as an
> alternative to rtg for high-resolution polling of interface traffic and
> long term storage?
> 
> I am investigating the various options for large data set size, lossless
> long term traffic charting (not RRAs which lose precision over time). One
> possible use is precision 95th billing.
> 
> https://collectd.org/


From louisk at cryptomonkeys.org  Wed Mar 16 19:35:26 2016
From: louisk at cryptomonkeys.org (Louis Kowolowski)
Date: Wed, 16 Mar 2016 12:35:26 -0700
Subject: collectd as alternative to RTG for high-resolution polling and
 long term storage?
In-Reply-To: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
References: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
Message-ID: <55C36510-9124-4404-A360-340CB0AE13D3@cryptomonkeys.org>

On Mar 16, 2016, at 11:45 AM, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:
> 
> Would anyone care to share their experience using collectd as an
> alternative to rtg for high-resolution polling of interface traffic and
> long term storage?
> 
> I am investigating the various options for large data set size, lossless
> long term traffic charting (not RRAs which lose precision over time). One
> possible use is precision 95th billing.
> 
> https://collectd.org/


Correct me if I?m wrong, but I believe that collectd uses RRD files for the backend, which you said you don?t want.

You might check out Grafana (http://grafana.org/ <http://grafana.org/>). Its based off graphite and uses something like opentsdb or influxdb for the backend. I think this is probably more what you?re looking for.

--
Louis Kowolowski                                louisk at cryptomonkeys.org <mailto:louisk at cryptomonkeys.org>
Cryptomonkeys:                                   http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>

Making life more interesting for people since 1977

-------------- 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/20160316/062d2f62/attachment.pgp>

From mark.tinka at seacom.mu  Wed Mar 16 19:42:54 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 16 Mar 2016 21:42:54 +0200
Subject: Cogent - Google - HE Fun
In-Reply-To: <CE555794-F675-468B-B0CE-FEAB10282678@delong.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
 <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
 <CAL9jLab9NrPRcsOrRseP8pDV-er1Dyiom6h3pJ5XXn55H3V8kg@mail.gmail.com>
 <933ae78f-a745-0ad4-7ff5-6f887345e444@seacom.mu>
 <CE555794-F675-468B-B0CE-FEAB10282678@delong.com>
Message-ID: <3dde96a6-d85c-a92b-c7d9-bd894dd076b0@seacom.mu>



On 16/Mar/16 21:23, Owen DeLong wrote:

> Please confirm that you in fact are receiving 174 * 6939 IPv6 paths from them?
>
> Seems unlikely to me.

Nope (neither IPv4 nor IPv6) - they are about 1,500 IPv6 routes short
from what we see from the others.

You're welcome to poke if you want to test my perspective:

    http://as37100.net/

They've obviously regressed a little bit, although it appears they never
did have any engagement with HE in particular, for either IP protocol.
In fairness, we knew getting into bed with Cogent would bring Daily Joy,
which is why we considered them last of all the major networks to on-board.

But as I said before, we have sufficient transit and peering that
Cogent's insufficiencies do not impact us. For now, what they have on
their network offers us some value (and they aren't necessarily any
cheaper than any of our other transit providers). If that value should
drop below a level where having them on the network is neither here nor
there, they'll get the boot.

Mark.


From jlk at thrashyour.com  Wed Mar 16 19:48:30 2016
From: jlk at thrashyour.com (John Kinsella)
Date: Wed, 16 Mar 2016 12:48:30 -0700
Subject: collectd as alternative to RTG for high-resolution polling and
 long term storage?
In-Reply-To: <55C36510-9124-4404-A360-340CB0AE13D3@cryptomonkeys.org>
References: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
 <55C36510-9124-4404-A360-340CB0AE13D3@cryptomonkeys.org>
Message-ID: <DB64F14E-509D-4997-907E-F5535D5F702A@thrashyour.com>

Collectd supports a large number ?write? plugins[1] that can write out to various sources. I had been eyeing Grafana and OpenTSDB, they?re probably worth a look

John
1: https://collectd.org/wiki/index.php/Table_of_Plugins

> On Mar 16, 2016, at 12:35 PM, Louis Kowolowski <louisk at cryptomonkeys.org> wrote:
> 
> On Mar 16, 2016, at 11:45 AM, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:
>> 
>> Would anyone care to share their experience using collectd as an
>> alternative to rtg for high-resolution polling of interface traffic and
>> long term storage?
>> 
>> I am investigating the various options for large data set size, lossless
>> long term traffic charting (not RRAs which lose precision over time). One
>> possible use is precision 95th billing.
>> 
>> https://collectd.org/
> 
> 
> Correct me if I?m wrong, but I believe that collectd uses RRD files for the backend, which you said you don?t want.
> 
> You might check out Grafana (http://grafana.org/ <http://grafana.org/>). Its based off graphite and uses something like opentsdb or influxdb for the backend. I think this is probably more what you?re looking for.
> 
> --
> Louis Kowolowski                                louisk at cryptomonkeys.org <mailto:louisk at cryptomonkeys.org>
> Cryptomonkeys:                                   http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>
> 
> Making life more interesting for people since 1977
> 


From dwcarder at wisc.edu  Wed Mar 16 19:52:34 2016
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Wed, 16 Mar 2016 14:52:34 -0500
Subject: collectd as alternative to RTG for high-resolution polling and
 long term storage?
In-Reply-To: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
References: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
Message-ID: <20160316195234.GC44490@DOIT-2NW1MRFY-X.doit.wisc.edu>

Thus spake Eric Kuhnke (eric.kuhnke at gmail.com) on Wed, Mar 16, 2016 at 11:45:26AM -0700:
> Would anyone care to share their experience using collectd as an
> alternative to rtg for high-resolution polling of interface traffic and
> long term storage?
> 
> I am investigating the various options for large data set size, lossless
> long term traffic charting (not RRAs which lose precision over time).

No, the storage interval is configurable and so are the (optional) 
consolidation functions.  You may want to look tuning at the defaults 
your application is choosing.

Dale

From owen at delong.com  Wed Mar 16 20:17:52 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 16 Mar 2016 13:17:52 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <3dde96a6-d85c-a92b-c7d9-bd894dd076b0@seacom.mu>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
 <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
 <CAL9jLab9NrPRcsOrRseP8pDV-er1Dyiom6h3pJ5XXn55H3V8kg@mail.gmail.com>
 <933ae78f-a745-0ad4-7ff5-6f887345e444@seacom.mu>
 <CE555794-F675-468B-B0CE-FEAB10282678@delong.com> <3dde96a6-d85c-a92b-c!
 7d9-bd894dd076b0@seacom.mu>
Message-ID: <F72922C2-ABBC-4809-83F9-BB8AF72A2BD9@delong.com>


> On Mar 16, 2016, at 12:42 , Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 16/Mar/16 21:23, Owen DeLong wrote:
> 
>> Please confirm that you in fact are receiving 174 * 6939 IPv6 paths from them?
>> 
>> Seems unlikely to me.
> 
> Nope (neither IPv4 nor IPv6) - they are about 1,500 IPv6 routes short
> from what we see from the others.
> 

Which means that they didn?t meet your requirements, but you bought from them
anyway. Even in 2014, they still don?t have a full IPv6 table, despite their
claim to the contrary.



> You're welcome to poke if you want to test my perspective:
> 
>    http://as37100.net/
> 

I believe you.

> They've obviously regressed a little bit, although it appears they never
> did have any engagement with HE in particular, for either IP protocol.
> In fairness, we knew getting into bed with Cogent would bring Daily Joy,
> which is why we considered them last of all the major networks to on-board.
> 
> But as I said before, we have sufficient transit and peering that
> Cogent's insufficiencies do not impact us. For now, what they have on
> their network offers us some value (and they aren't necessarily any
> cheaper than any of our other transit providers). If that value should
> drop below a level where having them on the network is neither here nor
> there, they'll get the boot.

Sure, that?s valid and I?m not criticizing your decision. Just saying that
according to you, Cogent outright lied to you in 2014 and you let them get
away with it.

Owen


From mark.tinka at seacom.mu  Wed Mar 16 20:34:51 2016
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 16 Mar 2016 22:34:51 +0200
Subject: Cogent - Google - HE Fun
In-Reply-To: <F72922C2-ABBC-4809-83F9-BB8AF72A2BD9@delong.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <20160311073353.A98CB3087FB3_6E274E1B@mx1.seacom.mu>
 <3fc96990-57f3-ab7b-9544-95b7ccfefc7d@seacom.mu>
 <ea4360b0a8b748329d57a6eb8b99546e@EXCH02.sb.local>
 <B542CC3757123745918E6B7E4D2EEE93D846C9@zeus.lti.local>
 <8C2FC8BB-D0F4-406D-BCC6-74245C978E13@ipifony.com>
 <397C90CE-ABE1-4F28-87B2-EAFA6B16FDE6@n5tech.com>
 <714CF43F-7CFE-45D4-B008-3E4EACCBAEDD@n5tech.com>
 <CAJUvGzCfkJMHsx4PwEEkibMKRsZtR2vCkCMMuXVQbcsTbdHNxw@mail.gmail.com>
 <CAL9jLaae0v2J=e+ZGmqJw8uHj0rizjEETqRjsHF6a=-EYpn=jg@mail.gmail.com>
 <CAJUvGzC1hcFPn-_LpBXe2ryKiU4E8wNEN3BsGf891iTZwdkvBQ@mail.gmail.com>
 <CAL9jLab9NrPRcsOrRseP8pDV-er1Dyiom6h3pJ5XXn55H3V8kg@mail.gmail.com>
 <933ae78f-a745-0ad4-7ff5-6f887345e444@seacom.mu>
 <CE555794-F675-468B-B0CE-FEAB10282678@delong.com> <3dde96a6-d85c-a92b-c!
 7d9-bd894dd076b0@seacom.mu> <F72922C2-ABBC-4809-83F9-BB8AF72A2BD9@delong.com>
Message-ID: <ca925cdc-703f-1719-27f3-6077b3f72848@seacom.mu>



On 16/Mar/16 22:17, Owen DeLong wrote:

> Sure, that?s valid and I?m not criticizing your decision. Just saying that
> according to you, Cogent outright lied to you in 2014 and you let them get
> away with it.

I probably should have been clearer in stating that between 2010 and
2014, Cogent's IPv6 coverage improved significantly. Although we knew it
was not the complete view, it was close and had no material impact on
our IPv6 capabilities re: our customers either way, as a function of the
value their network offered us overall for the amount of money we pay to
them.

In 2010 and 2012, Cogent would have been in a position to be the sole or
one of two upstreams for the networks I represented.

In 2014, they are one of 7x upstreams + tons of peering. So we were more
relaxed.

Mark.


From chris at totalhighspeed.net  Wed Mar 16 21:18:04 2016
From: chris at totalhighspeed.net (Christopher Tyler)
Date: Wed, 16 Mar 2016 16:18:04 -0500 (CDT)
Subject: Craiglist blocked
In-Reply-To: <419783971.131096917.1458162942549.JavaMail.zimbra@totalhighspeed.net>
Message-ID: <1738743958.131097025.1458163084973.JavaMail.zimbra@totalhighspeed.net>

Does anyone have a contact at Craigslist? 
Some of our IP addresses got blocked and we are getting no response from the email address listed when attempting to visit their site. Our customers are threatening mutiny.

-- 
Christopher Tyler 
MTCRE/MTCNA/MTCTCE/MTCWE 
Total Highspeed Internet Services 
417.851.1107


From george.herbert at gmail.com  Wed Mar 16 21:22:38 2016
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 16 Mar 2016 14:22:38 -0700
Subject: Craiglist blocked
In-Reply-To: <1738743958.131097025.1458163084973.JavaMail.zimbra@totalhighspeed.net>
References: <1738743958.131097025.1458163084973.JavaMail.zimbra@totalhighspeed.net>
Message-ID: <16AF2A74-F7F0-4FBA-BC74-51A1687F8328@gmail.com>

I know someone (not ops but ha can forward internally);  forwarding to him.

George William Herbert
Sent from my iPhone

> On Mar 16, 2016, at 2:18 PM, Christopher Tyler <chris at totalhighspeed.net> wrote:
> 
> Does anyone have a contact at Craigslist? 
> Some of our IP addresses got blocked and we are getting no response from the email address listed when attempting to visit their site. Our customers are threatening mutiny.
> 
> -- 
> Christopher Tyler 
> MTCRE/MTCNA/MTCTCE/MTCWE 
> Total Highspeed Internet Services 
> 417.851.1107
> 

From mjwise at kapu.net  Wed Mar 16 21:29:25 2016
From: mjwise at kapu.net (Michael J Wise)
Date: Wed, 16 Mar 2016 14:29:25 -0700
Subject: Craiglist blocked
In-Reply-To: <16AF2A74-F7F0-4FBA-BC74-51A1687F8328@gmail.com>
References: <1738743958.131097025.1458163084973.JavaMail.zimbra@totalhighspeed.net>
 <16AF2A74-F7F0-4FBA-BC74-51A1687F8328@gmail.com>
Message-ID: <6a48565501e45f7c38a0025737f4b2c8.squirrel@secure.kapu.net>


> I know someone (not ops but ha can forward internally);  forwarding to
> him.

If George's contact doesn't pan out, I have a name that I can forward your
concern to.
Ping me at work (address in the Cc:) with details if there's no response?

> George William Herbert
> Sent from my iPhone
>
>> On Mar 16, 2016, at 2:18 PM, Christopher Tyler
>> <chris at totalhighspeed.net> wrote:
>>
>> Does anyone have a contact at Craigslist?
>> Some of our IP addresses got blocked and we are getting no response from
>> the email address listed when attempting to visit their site. Our
>> customers are threatening mutiny.
>>
>> --
>> Christopher Tyler
>> MTCRE/MTCNA/MTCTCE/MTCWE
>> Total Highspeed Internet Services
>> 417.851.1107
>>
>


Aloha mai Nai`a.
-- 
" So this is how Liberty dies ...          http://kapu.net/~mjwise/
" To Thunderous Applause.



From george.herbert at gmail.com  Wed Mar 16 21:37:36 2016
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 16 Mar 2016 14:37:36 -0700
Subject: Craiglist blocked
In-Reply-To: <6a48565501e45f7c38a0025737f4b2c8.squirrel@secure.kapu.net>
References: <1738743958.131097025.1458163084973.JavaMail.zimbra@totalhighspeed.net>
 <16AF2A74-F7F0-4FBA-BC74-51A1687F8328@gmail.com>
 <6a48565501e45f7c38a0025737f4b2c8.squirrel@secure.kapu.net>
Message-ID: <61302C89-0FE5-471B-AA89-4241D3B74F49@gmail.com>

My guy (who is coder team not ops) confirmed he got the forwarded email and is passing it to the right ops folks, but those ops folks will have to reach back out again to Chris.

You might try Michael's contacts if you don't hear anything in a few hours at most.

George William Herbert
Sent from my iPhone

> On Mar 16, 2016, at 2:29 PM, "Michael J Wise" <mjwise at kapu.net> wrote:
> 
> 
>> I know someone (not ops but ha can forward internally);  forwarding to
>> him.
> 
> If George's contact doesn't pan out, I have a name that I can forward your
> concern to.
> Ping me at work (address in the Cc:) with details if there's no response?
> 
>> George William Herbert
>> Sent from my iPhone
>> 
>>> On Mar 16, 2016, at 2:18 PM, Christopher Tyler
>>> <chris at totalhighspeed.net> wrote:
>>> 
>>> Does anyone have a contact at Craigslist?
>>> Some of our IP addresses got blocked and we are getting no response from
>>> the email address listed when attempting to visit their site. Our
>>> customers are threatening mutiny.
>>> 
>>> --
>>> Christopher Tyler
>>> MTCRE/MTCNA/MTCTCE/MTCWE
>>> Total Highspeed Internet Services
>>> 417.851.1107
> 
> 
> Aloha mai Nai`a.
> -- 
> " So this is how Liberty dies ...          http://kapu.net/~mjwise/
> " To Thunderous Applause.
> 
> 

From dhubbard at dino.hostasaurus.com  Wed Mar 16 21:48:18 2016
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 16 Mar 2016 21:48:18 +0000
Subject: 10gig pricing with Verizon crazy?
Message-ID: <ECD0779D-C19C-4561-90B7-CE7DB6D2F894@dino.hostasaurus.com>

Curious if anyone has had similar experience; looking for a 10gig transit circuit at a colo, contacted VZ as they?re on net in the facility, quoted me an astronomical amount at 10-20x going rates these days.  I?m curious if I just happened across a bad rep and should dig further, or that?s par for the course?  Rep was comfortable talking about BGP, v4/v6, etc. so I felt like I was talking to the right person until I saw the price lol.

Thanks,

David

From mjwise at kapu.net  Wed Mar 16 21:51:42 2016
From: mjwise at kapu.net (Michael J Wise)
Date: Wed, 16 Mar 2016 14:51:42 -0700
Subject: Craiglist blocked
In-Reply-To: <6a48565501e45f7c38a0025737f4b2c8.squirrel@secure.kapu.net>
References: <1738743958.131097025.1458163084973.JavaMail.zimbra@totalhighspeed.net>
 <16AF2A74-F7F0-4FBA-BC74-51A1687F8328@gmail.com>
 <6a48565501e45f7c38a0025737f4b2c8.squirrel@secure.kapu.net>
Message-ID: <d7902fd188a18b4940d846786ae3a0ee.squirrel@secure.kapu.net>


>
>> I know someone (not ops but ha can forward internally);  forwarding to
>> him.
>
> If George's contact doesn't pan out, I have a name that I can forward your
> concern to.
> Ping me at work (address in the Cc:) with details if there's no response?

/facepalm

Let's try that again, once more with feeling.


>> George William Herbert
>> Sent from my iPhone
>>
>>> On Mar 16, 2016, at 2:18 PM, Christopher Tyler
>>> <chris at totalhighspeed.net> wrote:
>>>
>>> Does anyone have a contact at Craigslist?
>>> Some of our IP addresses got blocked and we are getting no response
>>> from
>>> the email address listed when attempting to visit their site. Our
>>> customers are threatening mutiny.
>>>
>>> --
>>> Christopher Tyler
>>> MTCRE/MTCNA/MTCTCE/MTCWE
>>> Total Highspeed Internet Services
>>> 417.851.1107
>>>
>>
>
>
> Aloha mai Nai`a.
> --
> " So this is how Liberty dies ...          http://kapu.net/~mjwise/
> " To Thunderous Applause.
>
>
>


Aloha mai Nai`a.
-- 
" So this is how Liberty dies ...          http://kapu.net/~mjwise/
" To Thunderous Applause.



From dan at drakontas.org  Wed Mar 16 21:56:36 2016
From: dan at drakontas.org (Daniel C. Eckert)
Date: Wed, 16 Mar 2016 14:56:36 -0700
Subject: 10gig pricing with Verizon crazy?
In-Reply-To: <ECD0779D-C19C-4561-90B7-CE7DB6D2F894@dino.hostasaurus.com>
References: <ECD0779D-C19C-4561-90B7-CE7DB6D2F894@dino.hostasaurus.com>
Message-ID: <CAGNc-gDMkRK_-xfQTGwb47EV=8x5-pWszO1Vj_arc8soCz3pUQ@mail.gmail.com>

What's your state/region and the general ballpark of the price quoted?
?


On Wed, Mar 16, 2016 at 2:48 PM, David Hubbard <
dhubbard at dino.hostasaurus.com> wrote:

> Curious if anyone has had similar experience; looking for a 10gig transit
> circuit at a colo, contacted VZ as they?re on net in the facility, quoted
> me an astronomical amount at 10-20x going rates these days.  I?m curious if
> I just happened across a bad rep and should dig further, or that?s par for
> the course?  Rep was comfortable talking about BGP, v4/v6, etc. so I felt
> like I was talking to the right person until I saw the price lol.
>
> Thanks,
>
> David
>

?

From jared at puck.nether.net  Wed Mar 16 21:58:37 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 16 Mar 2016 17:58:37 -0400
Subject: 10gig pricing with Verizon crazy?
In-Reply-To: <ECD0779D-C19C-4561-90B7-CE7DB6D2F894@dino.hostasaurus.com>
References: <ECD0779D-C19C-4561-90B7-CE7DB6D2F894@dino.hostasaurus.com>
Message-ID: <9481CC5E-8408-46C7-BD8B-6527215796DB@puck.nether.net>


> On Mar 16, 2016, at 5:48 PM, David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
> 
> Curious if anyone has had similar experience; looking for a 10gig transit circuit at a colo, contacted VZ as they?re on net in the facility, quoted me an astronomical amount at 10-20x going rates these days.  I?m curious if I just happened across a bad rep and should dig further, or that?s par for the course?  Rep was comfortable talking about BGP, v4/v6, etc. so I felt like I was talking to the right person until I saw the price lol.

In the brief period of time when I was not at my current employer I had a similar experience.  It wasn?t even worth my time to negotiate with them for a proper price, I basically told them they were way too high and moved on.

I?ve heard the right reps can get the proper pricing, but I wonder how much this is facility costs vs something else.

Carriers in my experience are pretty good at knowing their local market options, and unless you?re all going to locked-in 701 eyeballs it may be worthwhile to talk to someone else.

- Jared


From george.herbert at gmail.com  Wed Mar 16 22:12:28 2016
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 16 Mar 2016 15:12:28 -0700
Subject: Craiglist blocked
In-Reply-To: <d7902fd188a18b4940d846786ae3a0ee.squirrel@secure.kapu.net>
References: <1738743958.131097025.1458163084973.JavaMail.zimbra@totalhighspeed.net>
 <16AF2A74-F7F0-4FBA-BC74-51A1687F8328@gmail.com>
 <6a48565501e45f7c38a0025737f4b2c8.squirrel@secure.kapu.net>
 <d7902fd188a18b4940d846786ae3a0ee.squirrel@secure.kapu.net>
Message-ID: <E28B47D9-08EC-44B8-9734-004AC65D6137@gmail.com>





> On Mar 16, 2016, at 2:51 PM, "Michael J Wise" <mjwise at kapu.net> wrote:
> 
> Let's try that again, once more with feeling.

Put that tablet away
I'm asking you, please, no
It isn't right, it isn't fair!
There were firewalls everywhere
I think that exploit wasn't there...



George William Herbert
Sent from my iPhone

From henson at acm.org  Thu Mar 17 00:26:44 2016
From: henson at acm.org (Paul B. Henson)
Date: Wed, 16 Mar 2016 17:26:44 -0700
Subject: So Cal Verizon Business FIOS to Frontier cutover
Message-ID: <027a01d17fe3$af9fe350$0edfa9f0$@acm.org>

So the transition from Verizon to Frontier is coming up, and I recently got
a notice from Verizon pointing me to the following website:

http://meetfrontier.com/

Evidently one of the things Verizon did not sell to Frontier is their IP
address space, as it seems customers with static IP addresses are going to
have to change their allocations :(. I have five statics, and while it is
not the end of the world, it will certainly be annoying to have to
reconfigure not only my equipment but also update the configurations of my
clients that access it and the other service providers I access who restrict
based on it <sigh>. I was hoping to get some simple additional information
regarding this migration, such as:

* How far in advance of the cutover will we be notified?
* How far in advance of the cutover will we be supplied with the new static
IP addresses?
* How big will the cutover window be, and will it be attended or unattended?
* How will reverse DNS resolution be handled?

So I called the phone number on the website that was provided for questions
or additional information. I'm not quite sure why they provided it, as the
person who answered it had absolutely no information to provide other than
that that was already on the website, and said they were unable to direct me
to anyone who could provide any further information; I guess it was for
people who needed the website read to them?

Any chance there is a Frontier engineer on the list who might be able to
provide this information, anonymously if necessary :)? Or someone who has
gone through a Verizon to Frontier FIOS static IP address transition in
another location who might describe their experience with the assumption it
will be similar in California?

As far as reverse DNS, the only thing I can seem to find is this:

http://hostmaster.frontier.com/reverse.html

Which talks about "Business Class DSL and Dedicated Internet" customers, not
sure if it applies to FIOS? What I'd really like is to get my PTR entries
delegated to me via CNAMEs so I could control the TTLs and update them
whenever I wanted to without having to hassle the provider (one of my
colleagues has this arrangement with charter business cable), Verizon was
never willing to do that.

On another note, does anybody have any idea regarding Frontier's position on
rolling out IPv6 for business FIOS :)? Hopefully they won't be quite as
archaic and stuck in the mud as Verizon has been on that topic :(.

Thanks much for any info.



From jason at thebaughers.com  Thu Mar 17 00:39:45 2016
From: jason at thebaughers.com (Jason Baugher)
Date: Wed, 16 Mar 2016 19:39:45 -0500
Subject: 10gig pricing with Verizon crazy?
In-Reply-To: <ECD0779D-C19C-4561-90B7-CE7DB6D2F894@dino.hostasaurus.com>
References: <ECD0779D-C19C-4561-90B7-CE7DB6D2F894@dino.hostasaurus.com>
Message-ID: <CAGbD49p9WRFXaaD2j=-dFbk+_XiUvKQesUZ8C0gvC1cNq6dd8w@mail.gmail.com>

We were talking to AT&T once about using them for last-mile in their
territories. The first pricing we got was astronomical. One we recovered
from the shock and scrolled down, we saw all the 98%discount this, 95%
discount that tables, which after being applied brought them into the
ballpark. I seem to remember the initial price being their tariff rate.
Verizon may be playing the same games.

On Wed, Mar 16, 2016 at 4:48 PM, David Hubbard <
dhubbard at dino.hostasaurus.com> wrote:

> Curious if anyone has had similar experience; looking for a 10gig transit
> circuit at a colo, contacted VZ as they?re on net in the facility, quoted
> me an astronomical amount at 10-20x going rates these days.  I?m curious if
> I just happened across a bad rep and should dig further, or that?s par for
> the course?  Rep was comfortable talking about BGP, v4/v6, etc. so I felt
> like I was talking to the right person until I saw the price lol.
>
> Thanks,
>
> David
>

From peter.phaal at gmail.com  Thu Mar 17 00:52:46 2016
From: peter.phaal at gmail.com (Peter Phaal)
Date: Wed, 16 Mar 2016 17:52:46 -0700
Subject: collectd as alternative to RTG for high-resolution polling and
 long term storage?
In-Reply-To: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
References: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
Message-ID: <CAB8g2zzeohsasvsJZs3XsacEbeoMvYKFp3yNJCTOz-vZbnx5gQ@mail.gmail.com>

On Wed, Mar 16, 2016 at 11:45 AM, Eric Kuhnke <eric.kuhnke at gmail.com> wrote:
> Would anyone care to share their experience using collectd as an
> alternative to rtg for high-resolution polling of interface traffic and
> long term storage?
>
> I am investigating the various options for large data set size, lossless
> long term traffic charting (not RRAs which lose precision over time). One
> possible use is precision 95th billing.
>
> https://collectd.org/

Devices that support sFlow natively implement collectd type
functionality for streaming interface counters to a time series
database (InfluxDB, Graphite, OpenTSB, etc.) Tools like Grafana can be
used to query the database and build dashboards.

Host sFlow (http://sflow.net) is very similar to collectd in the
metrics it exports, but with the added ability to export flow data
from host adapters, bridges, vSwitches, firewalls, routing, VMs,
containers etc.

From randy at psg.com  Thu Mar 17 06:41:36 2016
From: randy at psg.com (Randy Bush)
Date: Thu, 17 Mar 2016 15:41:36 +0900
Subject: transferring [legacy] address space from arin to ripe
Message-ID: <m2bn6dli73.wl%randy@psg.com>

i have just finished $subject.  arin and ripe host and admin folk were
cooperative and helpful to the point of being embarrassing; dealing with
me when the moon is in klutz has to be a major pita.  but inter-rir
transfer works, works well, and works for legacy space.

we are continuing by bringing up an rpki CA under ripe's CA, step by
step over the next couple of weeks.  normally, it would be trivial; so
to make it exciting, we are doing it with pilot versions of the ripe and
dragon labs code bases which support the new rrdb [0], as well as rsync,
propagation methods.

i hope to report success in boring technical detail at the iepg meeting
on 2016.04.03 in BA.  but i thought it worth reporting that inter-rir
transfer works and works well.  thank you ripe and arin.

randy

[0] draft-ietf-sidr-delta-protocol-01.txt

From charles at phukish.com  Thu Mar 17 17:02:00 2016
From: charles at phukish.com (Charles van Niman)
Date: Thu, 17 Mar 2016 12:02:00 -0500
Subject: Latency in ATT DSL from Houston.
Message-ID: <CABD6Mzt-hf1kpjWpH+RbWQpSu=ASioYn9V+sx=9X9Dbpsc2CrA@mail.gmail.com>

Hello All,

    I am trying to get some assistance with latency I am seeing inside
ATT. DSL Support has been next to useless, and I am already pursing
different connectivity options, but getting this fixed would be
awesome. The problem is two fold, I see latency to pretty much any
destination, that starts after my modem / gateway. The second part of
the problem is mostly clerical, ATT seems to be using IANA
documentation space inside their network, which DSL support has no
explanation for.

    If someone from ATT could reach out to me off-list, that would be
greatly appreciated.

db-353-fw01> traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets


 1  75.39.205.94 (75.39.205.94)  2.451 ms  2.713 ms  2.693 ms
 2  192.0.2.100 (192.0.2.100)  882.693 ms  1375.347 ms  682.396 ms
 3  12.83.37.201 (12.83.37.201)  993.819 ms  1436.967 ms  616.373 ms
 4  12.122.85.197 (12.122.85.197)  944.982 ms  911.500 ms  676.696 ms
 5  206.121.120.70 (206.121.120.70)  937.521 ms  1312.248 ms
206.121.120.66 (206.121.120.66)  1353.350 ms
 6  216.239.40.139 (216.239.40.139)  1756.335 ms 216.239.54.109
(216.239.54.109)  1117.386 ms *
 7  72.14.238.45 (72.14.238.45)  1710.237 ms 64.233.175.9
(64.233.175.9)  1005.727 ms 64.233.174.151 (64.233.174.151)  1707.119
ms
 8  google-public-dns-a.google.com (8.8.8.8)  1468.629 ms  1529.764 ms
 834.876 ms


admin at db-353-fw01> traceroute 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 40 byte packets
 1  75.39.205.94 (75.39.205.94)  2.702 ms  5.745 ms  6.493 ms
 2  192.0.2.100 (192.0.2.100)  1986.510 ms  621.122 ms  604.383 ms
 3  12.83.37.201 (12.83.37.201)  1202.705 ms  1886.382 ms  1821.073 ms
 4  gar26.dlstx.ip.att.net (12.123.16.109)  1458.154 ms  1338.124 ms
1766.894 ms
 5  * * *
 6  ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  999.252 ms
ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  1597.016 ms  1843.397
ms
 7  ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  2156.637 ms
ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  1125.729 ms
ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  1912.391 ms
 8  b.resolvers.Level3.net (4.2.2.2)  1282.430 ms  1640.264 ms  1037.577 ms

admin at db-353-fw01> traceroute 12.123.16.109
traceroute to 12.123.16.109 (12.123.16.109), 30 hops max, 40 byte packets
 1  75.39.205.94 (75.39.205.94)  2.994 ms  3.034 ms  2.660 ms
 2  192.0.2.100 (192.0.2.100)  626.326 ms  1637.689 ms  1883.235 ms
 3  12.83.37.205 (12.83.37.205)  1972.528 ms !X * *

/Charles

From rekoil at semihuman.com  Thu Mar 17 17:49:37 2016
From: rekoil at semihuman.com (Chris Woodfield)
Date: Thu, 17 Mar 2016 10:49:37 -0700
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <56E11663.6090100@geier.ne.tz>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net> <56E112E2.5090306@forthnet.gr>
 <56E11663.6090100@geier.ne.tz>
Message-ID: <450A80D2-9519-47AD-AA11-46B70891A999@semihuman.com>

I think that?s the problem in a nutshell?until every vendor agrees on the size of a ?jumbo? packet/frame (and as such, allows that size to be set with a non-numerical configuration flag). As is, every vendor has a default that results in 1500-byte IP MTU, but changing that requires entering a value?which varies from vendor to vendor.

The IEEE *really* should be the ones driving this particular standardization, but it seems that they?ve explicitly decided not to. This is?annoying to say the least. Have their been any efforts on the IETF side of things to standardize this, at least for IPv4/v6 packets?

-C

> On Mar 9, 2016, at 10:38 PM, Frank Habicht <geier at geier.ne.tz> wrote:
> 
> Hi,
> 
> On 3/10/2016 9:23 AM, Tassos Chatzithomaoglou wrote:
>> Niels Bakker wrote on 10/3/16 02:44:
>>> * nanog at nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]:
>>>> I'm pretty confident there is no need for a specific MTU consensus and not all IXP participants are obligated to raise their interface MTU if the IXP starts allowing jumbo frames.
>>> 
>>> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too Big messages.  That's why everybody must agree on one MTU.
>>> 
>>> 
>> Isn't that the case for IXP's current/default MTU?
>> If an IXP currently uses 1500, what effect will it have to its customers if it's increased to 9200 but not announced to them?
> 
> none.
> everyone has agreed on 1500. it is near impossible to get close to
> everyone to agree on 9200 (or similar number) and implement it (at the
> same time or in a separate VLAN) (Nick argues, and i see the problem).
> The agreement and actions of the (various) operators of L3 devices
> connected at the IXP is what matters and seems not trivial.
> They are not under one control.
> 
> Frank


From shopik+lists at nvcube.net  Thu Mar 17 18:15:21 2016
From: shopik+lists at nvcube.net (Nikolay Shopik)
Date: Thu, 17 Mar 2016 21:15:21 +0300
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <450A80D2-9519-47AD-AA11-46B70891A999@semihuman.com>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net> <56E112E2.5090306@forthnet.gr>
 <56E11663.6090100@geier.ne.tz>
 <450A80D2-9519-47AD-AA11-46B70891A999@semihuman.com>
Message-ID: <c8197d91-a0da-e4c9-8dc4-f4928fe2506a@nvcube.net>

There was one draft few years ago

https://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00#section-3.1

On 17/03/2016 20:49, Chris Woodfield wrote:
> Have their been any efforts on the IETF side of things to standardize this, at least for IPv4/v6 packets?

From baldur.norddahl at gmail.com  Thu Mar 17 18:28:35 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 17 Mar 2016 19:28:35 +0100
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <c8197d91-a0da-e4c9-8dc4-f4928fe2506a@nvcube.net>
References: <CAPbn28=P8A1HGwF1x_8OBMtmExdfDBu3OHbomzgHtMAKStvuwA@mail.gmail.com>
 <56E0A224.1050806@forthnet.gr>
 <CAPbn28ki8Bk9uiP3n0yhamk_AkdNWpYyy-uAhiG2ZWMZWEnR+Q@mail.gmail.com>
 <20160310004407.GA6838@excession.tpb.net>
 <56E112E2.5090306@forthnet.gr> <56E11663.6090100@geier.ne.tz>
 <450A80D2-9519-47AD-AA11-46B70891A999@semihuman.com>
 <c8197d91-a0da-e4c9-8dc4-f4928fe2506a@nvcube.net>
Message-ID: <CAPkb-7A_8u2Mqy-CwYCH7Lhiso1rdpeoCUz0PWE_x9PYWLSxbA@mail.gmail.com>

Put MTU in BGP announcements? Imagine how much fun we could have if you
could make routing decisions based on available path MTU...

Regards,

Baldur

From stl at wiredrive.com  Thu Mar 17 20:09:35 2016
From: stl at wiredrive.com (Scott Larson)
Date: Thu, 17 Mar 2016 13:09:35 -0700
Subject: collectd as alternative to RTG for high-resolution polling and
 long term storage?
In-Reply-To: <CAB8g2zzeohsasvsJZs3XsacEbeoMvYKFp3yNJCTOz-vZbnx5gQ@mail.gmail.com>
References: <CAB69EHjNfaePN0fW+9nC5zJo3rZXLN+ZfWDpKisK_4rZfA9j=g@mail.gmail.com>
 <CAB8g2zzeohsasvsJZs3XsacEbeoMvYKFp3yNJCTOz-vZbnx5gQ@mail.gmail.com>
Message-ID: <CAFt8naFVw=+9E3t4LnRJ7=0WPwnDMuRSzsGTHet-yrLkn_90vQ@mail.gmail.com>

     Prometheus is also worth taking a look at.
     http://prometheus.io/docs/introduction/comparison/


*[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 Wed, Mar 16, 2016 at 5:52 PM, Peter Phaal <peter.phaal at gmail.com> wrote:

> On Wed, Mar 16, 2016 at 11:45 AM, Eric Kuhnke <eric.kuhnke at gmail.com>
> wrote:
> > Would anyone care to share their experience using collectd as an
> > alternative to rtg for high-resolution polling of interface traffic and
> > long term storage?
> >
> > I am investigating the various options for large data set size, lossless
> > long term traffic charting (not RRAs which lose precision over time). One
> > possible use is precision 95th billing.
> >
> > https://collectd.org/
>
> Devices that support sFlow natively implement collectd type
> functionality for streaming interface counters to a time series
> database (InfluxDB, Graphite, OpenTSB, etc.) Tools like Grafana can be
> used to query the database and build dashboards.
>
> Host sFlow (http://sflow.net) is very similar to collectd in the
> metrics it exports, but with the added ability to export flow data
> from host adapters, bridges, vSwitches, firewalls, routing, VMs,
> containers etc.
>

From baldur.norddahl at gmail.com  Thu Mar 17 21:33:58 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Thu, 17 Mar 2016 22:33:58 +0100
Subject: transferring [legacy] address space from arin to ripe
In-Reply-To: <m2bn6dli73.wl%randy@psg.com>
References: <m2bn6dli73.wl%randy@psg.com>
Message-ID: <CAPkb-7C3NJoef2bhHmUF2OBcWwcn3=3MaWC3Tstb_-0Xi6eSUQ@mail.gmail.com>

The interesting thing is how much trouble you will get from the geolocation
circus.

Or maybe you will get additional revenue from Netflix customers that love
the American Netflix.

Regards

Baldur
Den 17/03/2016 07.42 skrev "Randy Bush" <randy at psg.com>:

> i have just finished $subject.  arin and ripe host and admin folk were
> cooperative and helpful to the point of being embarrassing; dealing with
> me when the moon is in klutz has to be a major pita.  but inter-rir
> transfer works, works well, and works for legacy space.
>
> we are continuing by bringing up an rpki CA under ripe's CA, step by
> step over the next couple of weeks.  normally, it would be trivial; so
> to make it exciting, we are doing it with pilot versions of the ripe and
> dragon labs code bases which support the new rrdb [0], as well as rsync,
> propagation methods.
>
> i hope to report success in boring technical detail at the iepg meeting
> on 2016.04.03 in BA.  but i thought it worth reporting that inter-rir
> transfer works and works well.  thank you ripe and arin.
>
> randy
>
> [0] draft-ietf-sidr-delta-protocol-01.txt
>

From Marla.Azinger at FTR.com  Fri Mar 18 16:24:45 2016
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Fri, 18 Mar 2016 16:24:45 +0000
Subject: So Cal Verizon Business FIOS to Frontier cutover
In-Reply-To: <027a01d17fe3$af9fe350$0edfa9f0$@acm.org>
References: <027a01d17fe3$af9fe350$0edfa9f0$@acm.org>
Message-ID: <DM3PR0601MB202534EF8F11F32D8456C829E48C0@DM3PR0601MB2025.namprd06.prod.outlook.com>

Hi Paul

I will email you privately to address your concerns.

Regards
Marla Azinger
Supervisor Network ENG
IP Address Management



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul B. Henson
Sent: Wednesday, March 16, 2016 5:27 PM
To: nanog at nanog.org
Subject: So Cal Verizon Business FIOS to Frontier cutover

So the transition from Verizon to Frontier is coming up, and I recently got a notice from Verizon pointing me to the following website:

http://meetfrontier.com/

Evidently one of the things Verizon did not sell to Frontier is their IP address space, as it seems customers with static IP addresses are going to have to change their allocations :(. I have five statics, and while it is not the end of the world, it will certainly be annoying to have to reconfigure not only my equipment but also update the configurations of my clients that access it and the other service providers I access who restrict based on it <sigh>. I was hoping to get some simple additional information regarding this migration, such as:

* How far in advance of the cutover will we be notified?
* How far in advance of the cutover will we be supplied with the new static IP addresses?
* How big will the cutover window be, and will it be attended or unattended?
* How will reverse DNS resolution be handled?

So I called the phone number on the website that was provided for questions or additional information. I'm not quite sure why they provided it, as the person who answered it had absolutely no information to provide other than that that was already on the website, and said they were unable to direct me to anyone who could provide any further information; I guess it was for people who needed the website read to them?

Any chance there is a Frontier engineer on the list who might be able to provide this information, anonymously if necessary :)? Or someone who has gone through a Verizon to Frontier FIOS static IP address transition in another location who might describe their experience with the assumption it will be similar in California?

As far as reverse DNS, the only thing I can seem to find is this:

http://hostmaster.frontier.com/reverse.html

Which talks about "Business Class DSL and Dedicated Internet" customers, not sure if it applies to FIOS? What I'd really like is to get my PTR entries delegated to me via CNAMEs so I could control the TTLs and update them whenever I wanted to without having to hassle the provider (one of my colleagues has this arrangement with charter business cable), Verizon was never willing to do that.

On another note, does anybody have any idea regarding Frontier's position on rolling out IPv6 for business FIOS :)? Hopefully they won't be quite as archaic and stuck in the mud as Verizon has been on that topic :(.

Thanks much for any info.



________________________________

This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.

From vwittkop at nanog.org  Fri Mar 18 16:40:46 2016
From: vwittkop at nanog.org (Valerie Wittkop)
Date: Fri, 18 Mar 2016 12:40:46 -0400
Subject: [NANOG-announce] NANOG On The Road Comes to Raleigh!
Message-ID: <2BCD4024-E728-4570-AA17-CF7F28DC2D0B@nanog.org>

We are very excited to be holding the next NOTR event in Raleigh/Durham Research Triangle on April 12, 2016, 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 NANOG On The Road <https://www.nanog.org/meetings/road10/home> Raleigh event is perfect for you!

Date:  April 12, 2016
Time:  Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM
Location:  Embassy Suites Hilton Raleigh Durham Research Triangle <https://www.nanog.org/meetings/road10/hotel> - 201 Harrison Oaks Blvd, Cary, NC 27513

The FREE to attend event is open for registration.  Register Now! <https://www.cvent.com/events/notr-raleigh/registration-4a40a6ccc9e141b39e56f22d4654147a.aspx>

Agenda Topics <http://nanog.org/meetings/road10/agenda> are posted, which include:
- Life After IPv4
- DNSSEC & RPKI
- Traceroute Tutorial
- IPv6 Tutorial
- BGP Tutorial

If you are, or will be, in the Raleigh 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 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 Mar 18 18:11:07 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 19 Mar 2016 04:11:07 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201603181811.u2IIB7eB024518@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

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

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

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

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

Analysis Summary
----------------

BGP routing table entries examined:                              587053
    Prefixes after maximum aggregation (per Origin AS):          215951
    Deaggregation factor:                                          2.72
    Unique aggregates announced (without unneeded subnets):      287098
Total ASes present in the Internet Routing Table:                 53151
    Prefixes per ASN:                                             11.05
Origin-only ASes present in the Internet Routing Table:           36631
Origin ASes announcing only one prefix:                           15776
Transit ASes present in the Internet Routing Table:                6384
Transit-only ASes present in the Internet Routing Table:            165
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      39
    Max AS path prepend of ASN ( 40285)                              34
Prefixes from unregistered ASNs in the Routing Table:              1026
    Unregistered ASNs in the Routing Table:                         358
Number of 32-bit ASNs allocated by the RIRs:                      13113
Number of 32-bit ASNs visible in the Routing Table:               10136
Prefixes from 32-bit ASNs in the Routing Table:                   39613
Number of bogon 32-bit ASNs visible in the Routing Table:            14
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            338
Number of addresses announced to Internet:                   2808150724
    Equivalent to 167 /8s, 96 /16s and 250 /24s
    Percentage of available address space announced:               75.8
    Percentage of allocated address space announced:               75.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.1
Total number of prefixes smaller than registry allocations:      192177

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   150202
    Total APNIC prefixes after maximum aggregation:               41868
    APNIC Deaggregation factor:                                    3.59
Prefixes being announced from the APNIC address blocks:          160226
    Unique aggregates announced from the APNIC address blocks:    65408
APNIC Region origin ASes present in the Internet Routing Table:    5155
    APNIC Prefixes per ASN:                                       31.08
APNIC Region origin ASes announcing only one prefix:               1184
APNIC Region transit ASes present in the Internet Routing Table:    909
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         39
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1941
Number of APNIC addresses announced to Internet:              753104644
    Equivalent to 44 /8s, 227 /16s and 119 /24s
    Percentage of available APNIC address space announced:         88.0

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:                    180160
    Total ARIN prefixes after maximum aggregation:                88954
    ARIN Deaggregation factor:                                     2.03
Prefixes being announced from the ARIN address blocks:           185089
    Unique aggregates announced from the ARIN address blocks:     87856
ARIN Region origin ASes present in the Internet Routing Table:    16403
    ARIN Prefixes per ASN:                                        11.28
ARIN Region origin ASes announcing only one prefix:                5881
ARIN Region transit ASes present in the Internet Routing Table:    1706
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          37
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1081
Number of ARIN addresses announced to Internet:              1102292288
    Equivalent to 65 /8s, 179 /16s and 165 /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:                    141179
    Total RIPE prefixes after maximum aggregation:                69758
    RIPE Deaggregation factor:                                     2.02
Prefixes being announced from the RIPE address blocks:           149900
    Unique aggregates announced from the RIPE address blocks:     92518
RIPE Region origin ASes present in the Internet Routing Table:    18056
    RIPE Prefixes per ASN:                                         8.30
RIPE Region origin ASes announcing only one prefix:                7939
RIPE Region transit ASes present in the Internet Routing Table:    2980
Average RIPE Region AS path length visible:                         4.3
    Max RIPE Region AS path length visible:                          31
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4568
Number of RIPE addresses announced to Internet:               703950208
    Equivalent to 41 /8s, 245 /16s and 109 /24s
    Percentage of available RIPE address space announced:         102.3

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:                   61593
    Total LACNIC prefixes after maximum aggregation:              12162
    LACNIC Deaggregation factor:                                   5.06
Prefixes being announced from the LACNIC address blocks:          75518
    Unique aggregates announced from the LACNIC address blocks:   35353
LACNIC Region origin ASes present in the Internet Routing Table:   2472
    LACNIC Prefixes per ASN:                                      30.55
LACNIC Region origin ASes announcing only one prefix:               587
LACNIC Region transit ASes present in the Internet Routing Table:   552
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2354
Number of LACNIC addresses announced to Internet:             170478336
    Equivalent to 10 /8s, 41 /16s and 75 /24s
    Percentage of available LACNIC address space announced:       101.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:                  14226
    Total AfriNIC prefixes after maximum aggregation:              3168
    AfriNIC Deaggregation factor:                                  4.49
Prefixes being announced from the AfriNIC address blocks:         15982
    Unique aggregates announced from the AfriNIC address blocks:   5664
AfriNIC Region origin ASes present in the Internet Routing Table:   738
    AfriNIC Prefixes per ASN:                                     21.66
AfriNIC Region origin ASes announcing only one prefix:              185
AfriNIC Region transit ASes present in the Internet Routing Table:  166
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       18
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  192
Number of AfriNIC addresses announced to Internet:             77965056
    Equivalent to 4 /8s, 165 /16s and 167 /24s
    Percentage of available AfriNIC address space announced:       77.5

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5589       4192          76   China Education and Research 
 7545     3268        352         188   TPG Telecom Limited
 4766     3146      11142        1116   Korea Telecom
17974     2912        914          96   PT Telekomunikasi Indonesia
 9829     2404       1449         429   National Internet Backbone
 4755     2097        432         244   TATA Communications formerly 
 9808     1857       8717          30   Guangdong Mobile Communicatio
 4808     1640       2287         526   CNCGROUP IP network China169 
 4788     1519        645          62   TM Net, Internet Service Prov
 9583     1519        121         564   Sify Limited

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     3346       2948         145   Cox Communications Inc.
 6389     2371       3687          42   BellSouth.net Inc.
18566     2211        394         275   MegaPath Corporation
20115     1917       1927         401   Charter Communications
30036     1735        342         244   Mediacom Communications Corp
 6983     1692        849         232   EarthLink, Inc.
 4323     1578       1004         390   tw telecom holdings, inc.
  209     1539       4493        1246   Qwest Communications Company,
  701     1389      11452         661   MCI Communications Services, 
11492     1267        235         591   CABLE ONE, INC.

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     2515        135           9   SaudiNet, Saudi Telecom Compa
20940     2397        917        1722   Akamai International B.V.
34984     1953        323         413   TELLCOM ILETISIM HIZMETLERI A
 8551     1258        376          54   Bezeq International-Ltd
 6849     1179        355          21   JSC "Ukrtelecom"
12479     1145        980          86   France Telecom Espana SA
 8402     1134        544          15   OJSC "Vimpelcom"
13188     1077         98          78   TOV "Bank-Inform"
31148     1041         47          41   Freenet Ltd.
 9198      925        352          25   JSC Kazakhtelecom

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     3434        539         173   Telmex Colombia S.A.
 8151     2209       3415         543   Uninet S.A. de C.V.
 7303     1520        940         242   Telecom Argentina S.A.
11830     1441        366          25   Instituto Costarricense de El
 6503     1432        453          56   Axtel, S.A.B. de C.V.
 6147     1043        377          27   Telefonica del Peru S.A.A.
 3816      994        478         185   COLOMBIA TELECOMUNICACIONES S
26615      994       2325          34   Tim Celular S.A.
 7738      992       1882          41   Telemar Norte Leste S.A.
28573      888       2170         158   NET Servi?os de Comunica??o S

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     1235        402          35   Link Egypt (Link.NET)
 8452      736       1472          15   TE-AS
37611      644         48           2   Afrihost-Brevis Computer Serv
36903      584        294         104   Office National des Postes et
36992      505       1357          25   ETISALAT MISR
37492      380        233          65   Orange Tunisie
24835      338        146          12   Vodafone Data
29571      267         21          12   Cote d'Ivoire Telecom
 2018      249        327          74   TENET (The UNINET Project)
36947      233        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
 4538     5589       4192          76   China Education and Research 
10620     3434        539         173   Telmex Colombia S.A.
22773     3346       2948         145   Cox Communications Inc.
 7545     3268        352         188   TPG Telecom Limited
 4766     3146      11142        1116   Korea Telecom
17974     2912        914          96   PT Telekomunikasi Indonesia
39891     2515        135           9   SaudiNet, Saudi Telecom Compa
 9829     2404       1449         429   National Internet Backbone
20940     2397        917        1722   Akamai International B.V.
 6389     2371       3687          42   BellSouth.net Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
10620      3434        3261      Telmex Colombia S.A.
22773      3346        3201      Cox Communications Inc.
 7545      3268        3080      TPG Telecom Limited
17974      2912        2816      PT Telekomunikasi Indonesia
39891      2515        2506      SaudiNet, Saudi Telecom Compa
 6389      2371        2329      BellSouth.net Inc.
 4766      3146        2030      Korea Telecom
 9829      2404        1975      National Internet Backbone
18566      2211        1936      MegaPath Corporation
 4755      2097        1853      TATA Communications formerly 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
16589   UNALLOCATED  8.20.247.0/24        35838       CCANET Limited
16589   UNALLOCATED  8.26.56.0/24         35838       CCANET Limited
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.
37.46.15.0/24        36351     SoftLayer Technologies Inc.
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.3.0/24         37004     >>UNKNOWN<<
41.73.4.0/24         37004     >>UNKNOWN<<

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:101     /12:267     
/13:517     /14:1030    /15:1766    /16:12974   /17:7558    /18:12687   
/19:25805   /20:38108   /21:40034   /22:65035   /23:56283   /24:323222  
/25:540     /26:591     /27:397     /28:20      /29:16      /30:12      
/31:0       /32:25      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2527          3346      Cox Communications Inc.
39891     2472          2515      SaudiNet, Saudi Telecom Compa
18566     2113          2211      MegaPath Corporation
30036     1550          1735      Mediacom Communications Corp
 6389     1512          2371      BellSouth.net Inc.
 6983     1341          1692      EarthLink, Inc.
10620     1332          3434      Telmex Colombia S.A.
34984     1241          1953      TELLCOM ILETISIM HIZMETLERI A
11492     1177          1267      CABLE ONE, INC.
 6849      997          1179      JSC "Ukrtelecom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1640      2:737       4:20        5:2136      6:27        8:926    
  12:1778     13:38       14:1643     15:45       16:2        17:72     
  18:20       20:49       23:1426     24:1748     27:2266     31:1760   
  32:54       33:2        34:2        35:5        36:251      37:2267   
  38:1179     39:27       40:87       41:2812     42:388      43:1675   
  44:40       45:1752     46:2450     47:71       49:1131     50:843    
  51:8        52:134      54:198      55:3        56:6        57:44     
  58:1524     59:867      60:574      61:1800     62:1483     63:1926   
  64:4445     65:2157     66:4013     67:2120     68:1103     69:3263   
  70:1045     71:469      72:1970     74:2543     75:338      76:432    
  77:1368     78:1293     79:847      80:1304     81:1364     82:900    
  83:677      84:802      85:1588     86:467      87:1049     88:570    
  89:1927     90:168      91:6048     92:857      93:2297     94:2341   
  95:2309     96:461      97:351      98:956      99:45      100:69     
 101:1020    103:10020   104:2304    105:148     106:395     107:1155   
 108:654     109:2117    110:1262    111:1623    112:948     113:1137   
 114:1055    115:1701    116:1540    117:1416    118:2142    119:1568   
 120:514     121:1175    122:2226    123:1998    124:1612    125:1744   
 128:732     129:378     130:413     131:1275    132:604     133:173    
 134:451     135:122     136:354     137:332     138:1737    139:212    
 140:339     141:468     142:634     143:874     144:613     145:161    
 146:847     147:657     148:1467    149:478     150:651     151:828    
 152:606     153:271     154:556     155:912     156:491     157:445    
 158:348     159:1099    160:432     161:726     162:2306    163:539    
 164:728     165:1122    166:314     167:1071    168:1596    169:624    
 170:1578    171:265     172:503     173:1675    174:720     175:901    
 176:1532    177:4057    178:2243    179:1099    180:2038    181:1693   
 182:1954    183:671     184:814     185:5969    186:3005    187:2057   
 188:2140    189:1758    190:7682    191:1244    192:8903    193:5723   
 194:4375    195:3764    196:1674    197:1103    198:5522    199:5632   
 200:6890    201:3692    202:10150   203:9615    204:4644    205:2706   
 206:2961    207:3108    208:4079    209:3892    210:3947    211:2039   
 212:2640    213:2189    214:827     215:73      216:5751    217:1917   
 218:763     219:561     220:1676    221:855     222:665     223:936    


End of report

From kburke at burlingtontelecom.com  Fri Mar 18 20:19:39 2016
From: kburke at burlingtontelecom.com (Kevin Burke)
Date: Fri, 18 Mar 2016 20:19:39 +0000
Subject: CALEA Requirements
In-Reply-To: <031701d17e32$aa36d5c0$fea48140$@hathcock.org>
References: <031701d17e32$aa36d5c0$fea48140$@hathcock.org>
Message-ID: <BN3PR11MB01326233A4BEDC11F1B5D1E1D08C0@BN3PR11MB0132.namprd11.prod.outlook.com>

Ignore it until you get the paperwork.  The local law enforcement can not get a warrant for the real time, full data capture.  Only FBI or other national agencies can get those subpeona's.  We went through this with our local police department.  They wanted to make sure we were prepared and wanted a test for the real time number capture on phone calls.  They didn't mention they don't have any equipment on their side to connect the T1.  

Ask your local neighbors.  Some area's have a number of local federal investigations.  If you get the deer in the headlights look from your competition then you may never get one of these.

The full data captures are rare.

Kevin Burke
802-540-0979
Burlington Telecom - City of Burlington
200 Church St, Burlington, VT 05401

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock
Sent: Monday, March 14, 2016 4:47 PM
To: 'NANOG list' <nanog at nanog.org>
Subject: CALEA Requirements

NANOG:

 

Can someone point me to the current CALEA requirements?

 

As an ISP, should I be recording all internet traffic that passes my routers?  Or do I only have to record when and if I receive a court order?

 

I'm not under any court order now, I just want to be sure that I am compliant going forward in my capabilities.

 

Thanks!

 

Lorell Hathcock


From khelms at zcorum.com  Fri Mar 18 20:28:21 2016
From: khelms at zcorum.com (Scott Helms)
Date: Fri, 18 Mar 2016 16:28:21 -0400
Subject: CALEA Requirements
In-Reply-To: <BN3PR11MB01326233A4BEDC11F1B5D1E1D08C0@BN3PR11MB0132.namprd11.prod.outlook.com>
References: <031701d17e32$aa36d5c0$fea48140$@hathcock.org>
 <BN3PR11MB01326233A4BEDC11F1B5D1E1D08C0@BN3PR11MB0132.namprd11.prod.outlook.com>
Message-ID: <CAMrdfRyJZHekTPVhVmTkcWUddsT=23HjTbrRbCBBKpcihCb=Ug@mail.gmail.com>

Kevin,

That's largely true, but keep in mind that it's normal for people who have
had to fulfill a request to be disallowed from talking about it which makes
them seem even more rare than they actually are.  I'm also not familiar
with any laws that prevent state or local agencies from leveraging CALEA
and I've certainly seen it used on the voice side by state level law
enforcement.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Fri, Mar 18, 2016 at 4:19 PM, Kevin Burke <kburke at burlingtontelecom.com>
wrote:

> Ignore it until you get the paperwork.  The local law enforcement can not
> get a warrant for the real time, full data capture.  Only FBI or other
> national agencies can get those subpeona's.  We went through this with our
> local police department.  They wanted to make sure we were prepared and
> wanted a test for the real time number capture on phone calls.  They didn't
> mention they don't have any equipment on their side to connect the T1.
>
> Ask your local neighbors.  Some area's have a number of local federal
> investigations.  If you get the deer in the headlights look from your
> competition then you may never get one of these.
>
> The full data captures are rare.
>
> Kevin Burke
> 802-540-0979
> Burlington Telecom - City of Burlington
> 200 Church St, Burlington, VT 05401
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock
> Sent: Monday, March 14, 2016 4:47 PM
> To: 'NANOG list' <nanog at nanog.org>
> Subject: CALEA Requirements
>
> NANOG:
>
>
>
> Can someone point me to the current CALEA requirements?
>
>
>
> As an ISP, should I be recording all internet traffic that passes my
> routers?  Or do I only have to record when and if I receive a court order?
>
>
>
> I'm not under any court order now, I just want to be sure that I am
> compliant going forward in my capabilities.
>
>
>
> Thanks!
>
>
>
> Lorell Hathcock
>
>

From kraig at enguity.com  Fri Mar 18 20:31:43 2016
From: kraig at enguity.com (Kraig Beahn)
Date: Fri, 18 Mar 2016 16:31:43 -0400
Subject: CALEA Requirements
In-Reply-To: <CAMrdfRyJZHekTPVhVmTkcWUddsT=23HjTbrRbCBBKpcihCb=Ug@mail.gmail.com>
References: <031701d17e32$aa36d5c0$fea48140$@hathcock.org>
 <BN3PR11MB01326233A4BEDC11F1B5D1E1D08C0@BN3PR11MB0132.namprd11.prod.outlook.com>
 <CAMrdfRyJZHekTPVhVmTkcWUddsT=23HjTbrRbCBBKpcihCb=Ug@mail.gmail.com>
Message-ID: <CALsiHpxi+yFhvzc01a4uBsr4v9YW_AZ9Zbsw6oP+eBt_UtcPsg@mail.gmail.com>

I believe Scott, just hit the nail on the head...
"but keep in mind that it's normal for people who have
had to fulfill a request *to be disallowed from talking about it* which
makes
them seem even more rare than they actually are."

On Fri, Mar 18, 2016 at 4:28 PM, Scott Helms <khelms at zcorum.com> wrote:

> Kevin,
>
> That's largely true, but keep in mind that it's normal for people who have
> had to fulfill a request to be disallowed from talking about it which makes
> them seem even more rare than they actually are.  I'm also not familiar
> with any laws that prevent state or local agencies from leveraging CALEA
> and I've certainly seen it used on the voice side by state level law
> enforcement.
>
>
> Scott Helms
> Chief Technology Officer
> ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
>
> On Fri, Mar 18, 2016 at 4:19 PM, Kevin Burke <kburke at burlingtontelecom.com
> >
> wrote:
>
> > Ignore it until you get the paperwork.  The local law enforcement can not
> > get a warrant for the real time, full data capture.  Only FBI or other
> > national agencies can get those subpeona's.  We went through this with
> our
> > local police department.  They wanted to make sure we were prepared and
> > wanted a test for the real time number capture on phone calls.  They
> didn't
> > mention they don't have any equipment on their side to connect the T1.
> >
> > Ask your local neighbors.  Some area's have a number of local federal
> > investigations.  If you get the deer in the headlights look from your
> > competition then you may never get one of these.
> >
> > The full data captures are rare.
> >
> > Kevin Burke
> > 802-540-0979
> > Burlington Telecom - City of Burlington
> > 200 Church St, Burlington, VT 05401
> >
> > -----Original Message-----
> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell
> Hathcock
> > Sent: Monday, March 14, 2016 4:47 PM
> > To: 'NANOG list' <nanog at nanog.org>
> > Subject: CALEA Requirements
> >
> > NANOG:
> >
> >
> >
> > Can someone point me to the current CALEA requirements?
> >
> >
> >
> > As an ISP, should I be recording all internet traffic that passes my
> > routers?  Or do I only have to record when and if I receive a court
> order?
> >
> >
> >
> > I'm not under any court order now, I just want to be sure that I am
> > compliant going forward in my capabilities.
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Lorell Hathcock
> >
> >
>

From lorell at hathcock.org  Fri Mar 18 21:14:58 2016
From: lorell at hathcock.org (Lorell Hathcock)
Date: Fri, 18 Mar 2016 16:14:58 -0500
Subject: CALEA Requirements
In-Reply-To: <CALsiHpxi+yFhvzc01a4uBsr4v9YW_AZ9Zbsw6oP+eBt_UtcPsg@mail.gmail.com>
References: <031701d17e32$aa36d5c0$fea48140$@hathcock.org>
 <BN3PR11MB01326233A4BEDC11F1B5D1E1D08C0@BN3PR11MB0132.namprd11.prod.outlook.com>
 <CAMrdfRyJZHekTPVhVmTkcWUddsT=23HjTbrRbCBBKpcihCb=Ug@mail.gmail.com>
 <CALsiHpxi+yFhvzc01a4uBsr4v9YW_AZ9Zbsw6oP+eBt_UtcPsg@mail.gmail.com>
Message-ID: <3B0009DB-9EDF-4F2C-9B85-E6CC9F6B981E@hathcock.org>

Thanks for the tips. All good info. 

Sent from my iPhone

> On Mar 18, 2016, at 3:31 PM, Kraig Beahn <kraig at enguity.com> wrote:
> 
> I believe Scott, just hit the nail on the head...
> "but keep in mind that it's normal for people who have
> had to fulfill a request *to be disallowed from talking about it* which
> makes
> them seem even more rare than they actually are."
> 
>> On Fri, Mar 18, 2016 at 4:28 PM, Scott Helms <khelms at zcorum.com> wrote:
>> 
>> Kevin,
>> 
>> That's largely true, but keep in mind that it's normal for people who have
>> had to fulfill a request to be disallowed from talking about it which makes
>> them seem even more rare than they actually are.  I'm also not familiar
>> with any laws that prevent state or local agencies from leveraging CALEA
>> and I've certainly seen it used on the voice side by state level law
>> enforcement.
>> 
>> 
>> Scott Helms
>> Chief Technology Officer
>> ZCorum
>> (678) 507-5000
>> --------------------------------
>> http://twitter.com/kscotthelms
>> --------------------------------
>> 
>> On Fri, Mar 18, 2016 at 4:19 PM, Kevin Burke <kburke at burlingtontelecom.com
>> wrote:
>> 
>>> Ignore it until you get the paperwork.  The local law enforcement can not
>>> get a warrant for the real time, full data capture.  Only FBI or other
>>> national agencies can get those subpeona's.  We went through this with
>> our
>>> local police department.  They wanted to make sure we were prepared and
>>> wanted a test for the real time number capture on phone calls.  They
>> didn't
>>> mention they don't have any equipment on their side to connect the T1.
>>> 
>>> Ask your local neighbors.  Some area's have a number of local federal
>>> investigations.  If you get the deer in the headlights look from your
>>> competition then you may never get one of these.
>>> 
>>> The full data captures are rare.
>>> 
>>> Kevin Burke
>>> 802-540-0979
>>> Burlington Telecom - City of Burlington
>>> 200 Church St, Burlington, VT 05401
>>> 
>>> -----Original Message-----
>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell
>> Hathcock
>>> Sent: Monday, March 14, 2016 4:47 PM
>>> To: 'NANOG list' <nanog at nanog.org>
>>> Subject: CALEA Requirements
>>> 
>>> NANOG:
>>> 
>>> 
>>> 
>>> Can someone point me to the current CALEA requirements?
>>> 
>>> 
>>> 
>>> As an ISP, should I be recording all internet traffic that passes my
>>> routers?  Or do I only have to record when and if I receive a court
>> order?
>>> 
>>> 
>>> 
>>> I'm not under any court order now, I just want to be sure that I am
>>> compliant going forward in my capabilities.
>>> 
>>> 
>>> 
>>> Thanks!
>>> 
>>> 
>>> 
>>> Lorell Hathcock
>> 

From nanog at jima.us  Fri Mar 18 21:17:01 2016
From: nanog at jima.us (Jima)
Date: Fri, 18 Mar 2016 15:17:01 -0600
Subject: transferring [legacy] address space from arin to ripe
In-Reply-To: <m2bn6dli73.wl%randy@psg.com>
References: <m2bn6dli73.wl%randy@psg.com>
Message-ID: <56EC704D.5070705@jima.us>

On 2016-03-17 00:41, Randy Bush wrote:
> i have just finished $subject.  arin and ripe host and admin folk were
> cooperative and helpful to the point of being embarrassing; dealing with
> me when the moon is in klutz has to be a major pita.  but inter-rir
> transfer works, works well, and works for legacy space.

Apparently my data analytics skills are sharp enough to have found those 
networks in under 5 minutes. A /16, a /22 (effectively), and two /24s, 
right?

I see another /18 got transferred to RIPE the day after yours, so 
apparently you're not the only one doing this.

      Jima

From jheitz at cisco.com  Fri Mar 18 21:29:44 2016
From: jheitz at cisco.com (Jakob Heitz (jheitz))
Date: Fri, 18 Mar 2016 21:29:44 +0000
Subject: Internet Exchanges supporting jumbo frames?
Message-ID: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>

What's driving the desire for larger packets?

A single bit error will drop a whole packet.
Larger packets will cause more loss. Cables will need to be
shorter or bitrates lower to compensate.

Byte overhead of packet headers?

Are we seeing degradation of packets per second in forwarding
due to the increase in IPv6? Are we seeing IPv6 packets with
hop-by hop extension headers (which forward on the slow path)?

Increasing the packet size will reduce the number of TCP
packets as well as the number of TCP ack packets.
TCP ACK packets are significantly larger in IPv6 than IPv4.

TCP slow start is faster with large MTU. Is this an issue?

Are IPv6 packets with extension headers causing performance
degradation in firewalls?

Thanks,
Jakob.


From dwcarder at wisc.edu  Fri Mar 18 22:02:48 2016
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Fri, 18 Mar 2016 17:02:48 -0500
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
References: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
Message-ID: <20160318220248.GF44490@DOIT-2NW1MRFY-X.doit.wisc.edu>

Thus spake Jakob Heitz (jheitz) (jheitz at cisco.com) on Fri, Mar 18, 2016 at 09:29:44PM +0000:
> What's driving the desire for larger packets?

In our little corner of the internet, it is to increase the performance
of a low number of high-bdp flows which are typically dataset transfers.
All of our non-commercial peers support 9k.  

Dale

From jheitz at cisco.com  Fri Mar 18 22:21:20 2016
From: jheitz at cisco.com (Jakob Heitz (jheitz))
Date: Fri, 18 Mar 2016 22:21:20 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <20160318220248.GF44490@DOIT-2NW1MRFY-X.doit.wisc.edu>
References: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
 <20160318220248.GF44490@DOIT-2NW1MRFY-X.doit.wisc.edu>
Message-ID: <84be9c0e00df4e1698ab70a32dd77055@XCH-ALN-014.cisco.com>

Then it's mainly TCP slowstart that you're trying to improve?

Thanks,
Jakob.

> -----Original Message-----
> From: Dale W. Carder [mailto:dwcarder at wisc.edu]
> Sent: Friday, March 18, 2016 3:03 PM
> To: Jakob Heitz (jheitz) <jheitz at cisco.com>
> Cc: nanog at nanog.org
> Subject: Re: Internet Exchanges supporting jumbo frames?
> 
> Thus spake Jakob Heitz (jheitz) (jheitz at cisco.com) on Fri, Mar 18, 2016 at 09:29:44PM +0000:
> > What's driving the desire for larger packets?
> 
> In our little corner of the internet, it is to increase the performance
> of a low number of high-bdp flows which are typically dataset transfers.
> All of our non-commercial peers support 9k.
> 
> Dale

From jay at west.net  Fri Mar 18 23:46:58 2016
From: jay at west.net (Jay Hennigan)
Date: Fri, 18 Mar 2016 16:46:58 -0700
Subject: Cogent - Google - HE Fun
In-Reply-To: <BN1PR06MB2324D843A1B02F356FAD39FA9B50@BN1PR06MB232.namprd06.prod.outlook.com>
References: <B542CC3757123745918E6B7E4D2EEE93D6DF99@zeus.lti.local>
 <3debaeb9bd7d4f12a745762cbb1f8ba5@anx-i-dag02.anx.local>
 <Pine.LNX.4.61.1603091217490.6833@soloth.lewis.org>
 <B542CC3757123745918E6B7E4D2EEE93D73653@zeus.lti.local>
 <CAP-guGVTNXXeUNa_AXCK6gk5G3DATEr5XERmnENBKddVmD1z5g@mail.gmail.com>
 <2FD50E6D13594B4C93B743BFCF9F52843D1545B0@EXCH01.sb.local>
 <B12F2BAD-1FEC-4D93-908B-C554F147B9DD@init7.net>
 <96E55947-ABE3-4596-9D67-929C6CE18876@ipifony.com>
 <20160310222957.C2B8D44412DD@rock.dv.isc.org>
 <A2E44AE0-5A51-4E2D-88D8-76B55D10AF3C@ipifony.com>
 <BN1PR06MB2324D843A1B02F356FAD39FA9B50@BN1PR06MB232.namprd06.prod.outlook.com>
Message-ID: <56EC9372.6000300@west.net>

On 3/11/16 7:18 AM, Robert Jacobs wrote:
>  Till we have exclusive content on IPV6 or it is a shorter, faster, bigger, better path then we are still fighting this uphill battle to get more adoption of IPV6 and it will not matter to the majority of Cogent customers that they can't get full IPV6 routes and connections from Cogent.

Time to resurrect "The Great IPv6 Experiment"?

--
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 jay at west.net  Sat Mar 19 00:20:55 2016
From: jay at west.net (Jay Hennigan)
Date: Fri, 18 Mar 2016 17:20:55 -0700
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
Message-ID: <56EC9B67.2030906@west.net>

On 3/11/16 9:03 AM, Sean Donelan wrote:

> https://datacenters.cio.gov/optimization/
>
> "For the purposes of this memorandum, rooms with at least one server,
> providing services (whether in a production, test, stage, development,
> or any other environment), are considered data centers. However, rooms
> containing only routing equipment, switches, security devices (such as
> firewalls), or other telecommunications components shall not be
> considered data centers."

In other words, Hillary Clinton's bathroom closet is a data center.

-- 
--
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 jay at west.net  Sat Mar 19 01:42:14 2016
From: jay at west.net (Jay Hennigan)
Date: Fri, 18 Mar 2016 18:42:14 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAO0-hXaDg26oAiYHFN9+rKnLb4+FTcWmYh1tOLKe0JqRc62DPg@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <CAO0-hXaDg26oAiYHFN9+rKnLb4+FTcWmYh1tOLKe0JqRc62DPg@mail.gmail.com>
Message-ID: <56ECAE76.5060106@west.net>

On 3/12/16 12:15 PM, Joe Hamelin wrote:
> I know at Clearwire data centers we used gray for network, blue for
> management and orange for RS-232 console.  At least for the initial build.
> Later re-work or additions were whatever the tech had on hand ;)  They also
> had labels on each end of each wire showing the path through the system,
> sometimes up to six lines.  It did make it easy to bring up a data center
> and find cabling errors.  To see the system last more than a year or two up
> upgrades would take some strong rules and oversight.  I think it would be
> worth it if your management system can keep the religion.

That's the issue, keeping it that way. "Gray for network" is likely to 
result in mostly gray cables which won't really help to differentiate 
things in the long run. Breaking it down further can get tricky in terms 
of definition. Each network has a color, but then there's this trunk 
link....

We had a customer who had a scheme involving five different colors. When 
they did the initial build their wiring vendor came in with barrels of 
new cables of various lengths and colors and it looked really nice with 
cable management and all.

After a couple of years it was pretty much random in terms of color 
coding. Keeping multiple lengths on hand for dressing in raceway without 
incurring either tons of slack or bow-string taut wires is tough but 
possible, doing that in half a dozen colors can be daunting.

The electrons on the inside can't see the jacket on the outside and most 
of them are rumored to be color-blind anyway.

Maybe a compromise of a single color for most things and a different one 
for specials.

--
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 todd.crane at n5tech.com  Sat Mar 19 04:28:04 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Fri, 18 Mar 2016 22:28:04 -0600
Subject: Why the US Government has so many data centers
In-Reply-To: <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
Message-ID: <3B1CC2C8-560A-4D02-8AED-3CE8180EC7FA@n5tech.com>

I was trying to resist the urge to chime in on this one, but this discussion has continued for much longer than I had anticipated... So here it goes

I spent 5 years in the Marines (out now) in which one of my MANY duties was to manage these "data centers" (a part of me just died as I used that word to describe these server rooms). I can't get into what exactly I did or with what systems on such a public forum, but I'm pretty sure that most of the servers I managed would be exempted from this paper/policy.

Anyways, I came across a lot of servers in my time, but I never came across one that I felt should've been located elsewhere. People have brought up the case of personal share drive, but what about the combat camera (think public relations) that has to store large quantities (100s of 1000s) of high resolution photos and retain them for years. Should I remove that COTS (commercial off the shelf) NAS underneath the Boss' desk and put in a data center 4 miles down the road, and force all that traffic down a network that was designed for light to moderate web browsing and email traffic just so I can check a box for some politician's reelection campaign ads on how they made the government "more efficient"

Better yet, what about the backhoe operator who didn't call before he dug, and cut my line to the datacenter? Now we cannot respond effectively to a natural disaster in the Asian Pacific or a bombing in the Middle East or a platoon that has come under fire and will die if they can't get air support, all because my watch officer can't even login to his machine since I can no longer have a backup domain controller on-site

These seem very far fetched to most civilian network operators, but to anybody who has maintained military systems, this is a very real scenario. As mentioned, I'm pretty sure my systems would be exempted, but most would not. When these systems are vital to national security and life & death situations, it can become a very real problem. I realize that this policy was intended for more run of the mill scenarios, but the military is almost always grouped in with everyone else anyways. 

Furthermore, I don't think most people realize the scale of these networks. NMCI, the network that the Navy and Marine Corps used (when I was in), had over 500,000 active users in the AD forest. When you have a network that size, you have to be intentional about every decision, and you should not leave it up to a political appointee who has trouble even checking their email. 

When you read how about much money the US military hemorrhages, just remember.... 
- The multi million dollar storage array combined with a complete network overhaul, and multiple redundant 100G+ DWDM links was "more efficient" than a couple of NAS that we picked up off of Amazon for maybe $300 sitting under a desk connected to the local switch. 
- Using an old machine that would otherwise be collecting dust to ensure that users can login to their computers despite conditions outside of our control is apparently akin to treason and should be dealt with accordingly.
</rant>


--Todd

Sent from my iPad

> On Mar 14, 2016, at 11:01 AM, George Metz <george.metz at gmail.com> wrote:
> 
>> On Mon, Mar 14, 2016 at 12:44 PM, Lee <ler762 at gmail.com> wrote:
>> 
>> 
>> Yes, *sigh*, another what kind of people _do_ we have running the govt
>> story.  Altho, looking on the bright side, it could have been much
>> worse than a final summing up of "With the current closing having been
>> reported to have saved over $2.5 billion it is clear that inroads are
>> being made, but ... one has to wonder exactly how effective the
>> initiative will be at achieving a more effective and efficient use of
>> government monies in providing technology services."
>> 
>> Best Regards,
>> Lee
> 
> That's an inaccurate cost savings though most likely; it probably doesn't
> take into account the impacts of the consolidation on other items. As a
> personal example, we're in the middle of upgrading my site from an OC-3 to
> an OC-12, because we're running routinely at 95+% utilization on the OC-3
> with 4,000+ seats at the site. The reason we're running that high is
> because several years ago, they "consolidated" our file storage, so instead
> of file storage (and, actually, dot1x authentication though that's
> relatively minor) being local, everyone has to hit a datacenter some 500+
> miles away over that OC-3 every time they have to access a file share. And
> since they're supposed to save everything to their personal share drive
> instead of the actual machine they're sitting at, the results are
> predictable.
> 
> So how much is it going to cost for the OC-12 over the OC-3 annually? Is
> that difference higher or lower than the cost to run a couple of storage
> servers on-site? I don't know the math personally, but I do know that if we
> had storage (and RADIUS auth and hell, even a shell server) on site, we
> wouldn't be needing to upgrade to an OC-12.

From jheitz at cisco.com  Sat Mar 19 04:33:47 2016
From: jheitz at cisco.com (Jakob Heitz (jheitz))
Date: Sat, 19 Mar 2016 04:33:47 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <910665b3e62c455babf3469690dc7e92@baseworx.net>
References: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
 <20160318220248.GF44490@DOIT-2NW1MRFY-X.doit.wisc.edu>
 <84be9c0e00df4e1698ab70a32dd77055@XCH-ALN-014.cisco.com>,
 <910665b3e62c455babf3469690dc7e92@baseworx.net>
Message-ID: <D7B8992A-B4EC-4EBF-8332-A0F87D9B8FE3@cisco.com>

You would hardly notice it.
Helium is 4 times as heavy as hydrogen, but only marginally less buoyant.

Header overhead:
Ethernet=38
IPv4=20
TCP=20
Total=78
Protocol efficiency:
1500: 1500/1578 = 95%
9000: 9000/9078 = 99%

That's 4% better for a TCP packet, not 600%.

Thanks,
Jakob.


> On Mar 18, 2016, at 6:45 PM, Tim McKee <tim at baseworx.net> wrote:
> 
> I would hazard a guess that reducing the packet header overhead *and* the Ethernet interframe gap time by a factor of 6 could make enough of an improvement to be quite noticeable when dealing with huge dataset transfers.
> 
> Tim McKee
> 
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jakob Heitz (jheitz)
> Sent: Friday, March 18, 2016 18:21
> To: Dale W. Carder
> Cc: nanog at nanog.org
> Subject: RE: Internet Exchanges supporting jumbo frames?
> 
> Then it's mainly TCP slowstart that you're trying to improve?
> 
> Thanks,
> Jakob.
> 
>> -----Original Message-----
>> From: Dale W. Carder [mailto:dwcarder at wisc.edu]
>> Sent: Friday, March 18, 2016 3:03 PM
>> To: Jakob Heitz (jheitz) <jheitz at cisco.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Internet Exchanges supporting jumbo frames?
>> 
>> Thus spake Jakob Heitz (jheitz) (jheitz at cisco.com) on Fri, Mar 18, 2016 at 09:29:44PM +0000:
>>> What's driving the desire for larger packets?
>> 
>> In our little corner of the internet, it is to increase the 
>> performance of a low number of high-bdp flows which are typically dataset transfers.
>> All of our non-commercial peers support 9k.
>> 
>> Dale
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6189 / Virus Database: 4542/11829 - Release Date: 03/17/16

From george.herbert at gmail.com  Sat Mar 19 05:21:01 2016
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 18 Mar 2016 22:21:01 -0700
Subject: Why the US Government has so many data centers
In-Reply-To: <3B1CC2C8-560A-4D02-8AED-3CE8180EC7FA@n5tech.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <DF2489DC-41F7-42C0-A75E-C8D435ABE502@arbor.net>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
 <3B1CC2C8-560A-4D02-8AED-3CE8180EC7FA@n5tech.com>
Message-ID: <C56B4D6A-F03B-42CE-9EF9-54563547CB44@gmail.com>


So...

Before I go on, I have not been in Todd's shoes, either serving nor directly supporting an org like that.

However, I have indirectly supported orgs like that and consulted at or supported literally hundreds of commercial and a few educational and nonprofit orgs over the last 30 years. 

There are corner cases where distributed resilience is paramount, including a lot of field operations (of all sorts) on ships (and aircraft and spacecraft), or places where the net really is unstable.  Any generalizations that wrap those legitimate exceptions in are overreaching their valid descriptive range.

That said, the vast bulk of normal world environments, individuals make justifications like Todd's and argue for distributed services, private servers, etc.  And then do not run them reliably, with patches, backups, central security management, asset tracking, redundancy, DR plans, etc.

And then they break, and in some cases are and will forever be lost.  In other cases they will "merely" take 2, 5, 10, in one case more than 100 times longer to repair and more money to recover than they should have.

Statistically these are very very poor operational practice.  Not so much because of location (some) but because of lack of care and quality management when they get distributed and lost out of IT's view.

Statistically, several hundred clients in and a hundred or so organizational assessments in, if I find servers that matter under desks you have about a 2% chance that your IT org can handle supporting and managing them appropriately.

If you think that 98% of servers in a particular category being at high risk of unrecoverable or very difficult recovery when problems crop up is acceptable, your successor may be hiring me or someone else who consults a lot for a very bad day's cleanup.

I have literally been at a billion dollar IT disaster and at tens of smaller multimillion dollar ones trying to clean it up.  This is a very sad type of work.

I am not nearly as cheap for recoveries as for preventive management and proactive fixes. 


George William Herbert
Sent from my iPhone

> On Mar 18, 2016, at 9:28 PM, Todd Crane <todd.crane at n5tech.com> wrote:
> 
> I was trying to resist the urge to chime in on this one, but this discussion has continued for much longer than I had anticipated... So here it goes
> 
> I spent 5 years in the Marines (out now) in which one of my MANY duties was to manage these "data centers" (a part of me just died as I used that word to describe these server rooms). I can't get into what exactly I did or with what systems on such a public forum, but I'm pretty sure that most of the servers I managed would be exempted from this paper/policy.
> 
> Anyways, I came across a lot of servers in my time, but I never came across one that I felt should've been located elsewhere. People have brought up the case of personal share drive, but what about the combat camera (think public relations) that has to store large quantities (100s of 1000s) of high resolution photos and retain them for years. Should I remove that COTS (commercial off the shelf) NAS underneath the Boss' desk and put in a data center 4 miles down the road, and force all that traffic down a network that was designed for light to moderate web browsing and email traffic just so I can check a box for some politician's reelection campaign ads on how they made the government "more efficient"
> 
> Better yet, what about the backhoe operator who didn't call before he dug, and cut my line to the datacenter? Now we cannot respond effectively to a natural disaster in the Asian Pacific or a bombing in the Middle East or a platoon that has come under fire and will die if they can't get air support, all because my watch officer can't even login to his machine since I can no longer have a backup domain controller on-site
> 
> These seem very far fetched to most civilian network operators, but to anybody who has maintained military systems, this is a very real scenario. As mentioned, I'm pretty sure my systems would be exempted, but most would not. When these systems are vital to national security and life & death situations, it can become a very real problem. I realize that this policy was intended for more run of the mill scenarios, but the military is almost always grouped in with everyone else anyways. 
> 
> Furthermore, I don't think most people realize the scale of these networks. NMCI, the network that the Navy and Marine Corps used (when I was in), had over 500,000 active users in the AD forest. When you have a network that size, you have to be intentional about every decision, and you should not leave it up to a political appointee who has trouble even checking their email. 
> 
> When you read how about much money the US military hemorrhages, just remember.... 
> - The multi million dollar storage array combined with a complete network overhaul, and multiple redundant 100G+ DWDM links was "more efficient" than a couple of NAS that we picked up off of Amazon for maybe $300 sitting under a desk connected to the local switch. 
> - Using an old machine that would otherwise be collecting dust to ensure that users can login to their computers despite conditions outside of our control is apparently akin to treason and should be dealt with accordingly.
> </rant>
> 
> 
> --Todd
> 
> Sent from my iPad
> 
>>> On Mar 14, 2016, at 11:01 AM, George Metz <george.metz at gmail.com> wrote:
>>> 
>>> On Mon, Mar 14, 2016 at 12:44 PM, Lee <ler762 at gmail.com> wrote:
>>> 
>>> 
>>> Yes, *sigh*, another what kind of people _do_ we have running the govt
>>> story.  Altho, looking on the bright side, it could have been much
>>> worse than a final summing up of "With the current closing having been
>>> reported to have saved over $2.5 billion it is clear that inroads are
>>> being made, but ... one has to wonder exactly how effective the
>>> initiative will be at achieving a more effective and efficient use of
>>> government monies in providing technology services."
>>> 
>>> Best Regards,
>>> Lee
>> 
>> That's an inaccurate cost savings though most likely; it probably doesn't
>> take into account the impacts of the consolidation on other items. As a
>> personal example, we're in the middle of upgrading my site from an OC-3 to
>> an OC-12, because we're running routinely at 95+% utilization on the OC-3
>> with 4,000+ seats at the site. The reason we're running that high is
>> because several years ago, they "consolidated" our file storage, so instead
>> of file storage (and, actually, dot1x authentication though that's
>> relatively minor) being local, everyone has to hit a datacenter some 500+
>> miles away over that OC-3 every time they have to access a file share. And
>> since they're supposed to save everything to their personal share drive
>> instead of the actual machine they're sitting at, the results are
>> predictable.
>> 
>> So how much is it going to cost for the OC-12 over the OC-3 annually? Is
>> that difference higher or lower than the cost to run a couple of storage
>> servers on-site? I don't know the math personally, but I do know that if we
>> had storage (and RADIUS auth and hell, even a shell server) on site, we
>> wouldn't be needing to upgrade to an OC-12.

From dmitry at interhost.net  Sat Mar 19 05:38:03 2016
From: dmitry at interhost.net (Dmitry Sherman)
Date: Sat, 19 Mar 2016 05:38:03 +0000
Subject: www.cisco.com no resolve?
Message-ID: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>

dig www.cisco.com @8.8.8.8


; <<>> DiG 9.8.3-P1 <<>> www.cisco.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60416
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:
;www.cisco.com.			IN	A


;; AUTHORITY SECTION:
cisco.com.		1247	IN	SOA	edns-rtp5-1-l. postmaster.cisco.com. 16034550 7200 1800 864000 86400


;; Query time: 94 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Mar 19 07:36:22 2016
;; MSG SIZE  rcvd: 91





? 
Dmitry Sherman
Interhost Networks Ltd
dmitry at interhost.net
office: 972-74-7029881
mobile: 972-54-3181182
http://www.interhost.co.il





>

From owen at delong.com  Sat Mar 19 05:40:12 2016
From: owen at delong.com (Owen DeLong)
Date: Fri, 18 Mar 2016 22:40:12 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <56ECAE76.5060106@west.net>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <CAO0-hXaDg26oAiYHFN9+rKnLb4+FTcWmYh1tOLKe0JqRc62DPg@mail.gmail.com>
 <56ECAE76.5060106@west.net>
Message-ID: <EC3FFD05-BA49-4C50-BC66-5915F0001D73@delong.com>


> On Mar 18, 2016, at 18:42 , Jay Hennigan <jay at west.net> wrote:
> 
> On 3/12/16 12:15 PM, Joe Hamelin wrote:
>> I know at Clearwire data centers we used gray for network, blue for
>> management and orange for RS-232 console.  At least for the initial build.
>> Later re-work or additions were whatever the tech had on hand ;)  They also
>> had labels on each end of each wire showing the path through the system,
>> sometimes up to six lines.  It did make it easy to bring up a data center
>> and find cabling errors.  To see the system last more than a year or two up
>> upgrades would take some strong rules and oversight.  I think it would be
>> worth it if your management system can keep the religion.
> 
> That's the issue, keeping it that way. "Gray for network" is likely to result in mostly gray cables which won't really help to differentiate things in the long run. Breaking it down further can get tricky in terms of definition. Each network has a color, but then there's this trunk link....
> 
> We had a customer who had a scheme involving five different colors. When they did the initial build their wiring vendor came in with barrels of new cables of various lengths and colors and it looked really nice with cable management and all.
> 
> After a couple of years it was pretty much random in terms of color coding. Keeping multiple lengths on hand for dressing in raceway without incurring either tons of slack or bow-string taut wires is tough but possible, doing that in half a dozen colors can be daunting.

Yes and no.

If you have a requirement that all cabling between racks goes via fixed cabling from patch panels and patch cables are only used for intra-rack runs between equipment in the same rack and/or equipment<->patch panel in the same rack, it gets a lot less so. This can also help keep a lot of other things more sane in the long run as well.

I found that you could deal pretty well with any intra-rack run (assuming 7? racks) if you stocked the following lengths:

	0.5?
	1?
	1.5?
	2?
	2.5?
	3?
	4?
	5?
	6?
	7?
	8?
	10?

That?s a total of 12 lengths. We kept those in stock in Yellow (SMF), Orange (MMF), Other colors all Cat 6: Blue, Red, Purple, Green.

Total of 72 part numbers to keep track of. We got one of those roll-around bin carts that had 4 rows of 9 drawers on each side. Worked out perfectly to have 72 kinds of cables. (IIRC, we did 3 columns per color working up in size from left to right).

We had a guy who was responsible for making sure none of the bins were ever empty. I think he checked the cart twice a week and ordered once a month most months. I think we tended to keep at least 5 on the cart and topped the bins up to 20 for most sizes and 40 for the popular size/color combinations.

We didn?t have any trouble maintaining the system and as long as the right color was available, we got pretty good compliance from the people installing cables. (Our ?retraining? method for people who ran a wrong-colored cable didn?t hurt, either.)

YMMV.

Owen


From jlk at thrashyour.com  Sat Mar 19 05:53:15 2016
From: jlk at thrashyour.com (John Kinsella)
Date: Fri, 18 Mar 2016 22:53:15 -0700
Subject: www.cisco.com no resolve?
In-Reply-To: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>
References: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>
Message-ID: <BCBCEF5D-0E54-468B-B3E4-6BBA8ED8F326@thrashyour.com>

Confirmed in Northern California, on all 3 primary NS servers. A little Friday night maintenance window, maybe?

Looks like it?s just the www record...

> On Mar 18, 2016, at 10:38 PM, Dmitry Sherman <dmitry at interhost.net> wrote:
> 
> dig www.cisco.com @8.8.8.8
> 
> 
> ; <<>> DiG 9.8.3-P1 <<>> www.cisco.com @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60416
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> 
> ;; QUESTION SECTION:
> ;www.cisco.com.			IN	A
> 
> 
> ;; AUTHORITY SECTION:
> cisco.com.		1247	IN	SOA	edns-rtp5-1-l. postmaster.cisco.com. 16034550 7200 1800 864000 86400
> 
> 
> ;; Query time: 94 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Mar 19 07:36:22 2016
> ;; MSG SIZE  rcvd: 91
> 
> 
> 
> 
> 
> ? 
> Dmitry Sherman
> Interhost Networks Ltd
> dmitry at interhost.net
> office: 972-74-7029881
> mobile: 972-54-3181182
> http://www.interhost.co.il
> 
> 
> 
> 
> 
>> 


From bortzmeyer at nic.fr  Sat Mar 19 14:45:05 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sat, 19 Mar 2016 15:45:05 +0100
Subject: www.cisco.com no resolve?
In-Reply-To: <BCBCEF5D-0E54-468B-B3E4-6BBA8ED8F326@thrashyour.com>
References: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>
 <BCBCEF5D-0E54-468B-B3E4-6BBA8ED8F326@thrashyour.com>
Message-ID: <20160319144505.GA3954@nic.fr>

On Fri, Mar 18, 2016 at 10:53:15PM -0700,
 John Kinsella <jlk at thrashyour.com> wrote 
 a message of 49 lines which said:

> Confirmed in Northern California, on all 3 primary NS servers. A
> little Friday night maintenance window, maybe?

Isn't it simply because the alias chain is awfully long (five steps)
and it may fail with resolvers which are hardened against the
"infinite recursion" attack?

% dig A www.cisco.com
...
;; ANSWER SECTION:
www.cisco.com.		3538 IN	CNAME www.cisco.com.akadns.net.
www.cisco.com.akadns.net. 238 IN CNAME wwwds.cisco.com.edgekey.net.
wwwds.cisco.com.edgekey.net. 21538 IN CNAME wwwds.cisco.com.edgekey.net.globalredir.akadns.net.
wwwds.cisco.com.edgekey.net.globalredir.akadns.net. 3538 IN CNAME e144.dscb.akamaiedge.net.
e144.dscb.akamaiedge.net. 20 IN	A 104.93.242.137

http://www.ssi.gouv.fr/uploads/2014/12/idns_attack_anssi.pdf

From bortzmeyer at nic.fr  Sat Mar 19 14:51:40 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sat, 19 Mar 2016 15:51:40 +0100
Subject: www.cisco.com no resolve?
In-Reply-To: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>
References: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>
Message-ID: <20160319145140.GA4981@nic.fr>

On Sat, Mar 19, 2016 at 05:38:03AM +0000,
 Dmitry Sherman <dmitry at interhost.net> wrote 
 a message of 13 lines which said:

> dig www.cisco.com @8.8.8.8

Better to test through the authoritative name servers. The problem was
there, as documented in
<https://www.reddit.com/r/networking/comments/4b2bgo/cisco_website_is_down/d15iu63>

So, it was not because of the long CNAME chain, unlike what I wrote
previously.


From Valdis.Kletnieks at vt.edu  Sun Mar 20 00:12:32 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 19 Mar 2016 20:12:32 -0400
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
References: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
Message-ID: <8681.1458432752@turing-police.cc.vt.edu>

On Fri, 18 Mar 2016 21:29:44 -0000, "Jakob Heitz (jheitz)" said:
> A single bit error will drop a whole packet.
> Larger packets will cause more loss. Cables will need to be
> shorter or bitrates lower to compensate.

If that's an actual concern in your production network, you probably have
bigger issues you need to be dealing with....
-------------- 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/20160319/d768716f/attachment.pgp>

From mike-nanog at tiedyenetworks.com  Sun Mar 20 01:28:41 2016
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Sat, 19 Mar 2016 18:28:41 -0700
Subject: junkmailers take the day off....?
Message-ID: <56EDFCC9.4050305@tiedyenetworks.com>

Hi,

     This is not a complaint, but today seems to be a major disturbance 
in the force...my junkmail load seems to be WAAAYYYY down today, like 
they all are out at the beach or something... some major botnet get 
shutdown or something???

Mike

From mel at beckman.org  Sun Mar 20 01:50:31 2016
From: mel at beckman.org (Mel Beckman)
Date: Sun, 20 Mar 2016 01:50:31 +0000
Subject: junkmailers take the day off....?
In-Reply-To: <56EDFCC9.4050305@tiedyenetworks.com>
References: <56EDFCC9.4050305@tiedyenetworks.com>
Message-ID: <62CEBB91-D4F8-4F71-BE53-522236566CDA@beckman.org>

I'm seeing the same thing. Weird. 

-mel via cell

> On Mar 19, 2016, at 6:29 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> 
> Hi,
> 
>    This is not a complaint, but today seems to be a major disturbance in the force...my junkmail load seems to be WAAAYYYY down today, like they all are out at the beach or something... some major botnet get shutdown or something???
> 
> Mike

From mansaxel at besserwisser.org  Sun Mar 20 10:12:29 2016
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Sun, 20 Mar 2016 11:12:29 +0100
Subject: junkmailers take the day off....?
In-Reply-To: <62CEBB91-D4F8-4F71-BE53-522236566CDA@beckman.org>
References: <56EDFCC9.4050305@tiedyenetworks.com>
 <62CEBB91-D4F8-4F71-BE53-522236566CDA@beckman.org>
Message-ID: <20160320101229.GP4287@besserwisser.org>

Subject: Re: junkmailers take the day off....? Date: Sun, Mar 20, 2016 at 01:50:31AM +0000 Quoting Mel Beckman (mel at beckman.org):
> I'm seeing the same thing. Weird. 
> 
> -mel via cell
> 
> > On Mar 19, 2016, at 6:29 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> > 
> > Hi,
> > 
> >    This is not a complaint, but today seems to be a major disturbance in the force...my junkmail load seems to be WAAAYYYY down today, like they all are out at the beach or something... some major botnet get shutdown or something???

A large portion of the Swedish newspaper web sites were hit with a fairly
large attack yesterday evening MET, around 1830UTC. Perhaps the keyword is
"retasked". Fwiw, I also saw a decline in my spamcount. 

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
VICARIOUSLY experience some reason to LIVE!!
-------------- 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/20160320/6c876980/attachment.pgp>

From nanog at yacl.net  Tue Mar 15 18:14:49 2016
From: nanog at yacl.net (ML-NANOG-Stefan-Jakob)
Date: Tue, 15 Mar 2016 18:14:49 +0000
Subject: Low density Juniper (or alternative) Edge
In-Reply-To: <0a03a53f-b7c1-52e0-800f-9bce6f87ca08@seacom.mu>
References: <01872ABF-5272-4426-B98E-A8703EB79B0E@gmail.com>
 <56B1B32E.4030609@foobar.org> <0a03a53f-b7c1-52e0-800f-9bce6f87ca08@seacom.mu>
Message-ID: <CAEQS+Yc=c4LfeAJDZk+FqW_nB4B-fZSn_C8+_bAUz_A9n=db7w@mail.gmail.com>

Hi Mark,

Mark Tinka <mark.tinka at seacom.mu> schrieb am So., 28. Feb. 2016 07:13:

>
>
> On 3/Feb/16 09:58, Nick Hilliard wrote:
>
> > Typically the features that fall by the wayside first are: reasonable
> > port buffers, qos knobs and decent lag/ecmp hashing support for mpls
> > packets.
>
> Cisco, in general, are suffering here, i.e., QoS on LAG's.
>
> IOS, IOS XE and IOS XR suffer massively.
>
> We find that Junos does a better job here.
>
> Mark.
>

Do yo have more details what's wrong with the XR platform?

Which hardware do we talk about and which XR version is your statement
applying?

Rgds, Stefan

>

From michael at crossivity.com  Wed Mar 16 08:42:53 2016
From: michael at crossivity.com (Michael Rave)
Date: Wed, 16 Mar 2016 09:42:53 +0100
Subject: remote serial console (IP to Serial)
In-Reply-To: <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
References: <CAKuzA1FJfAeUBb0uF8PM1q5T1+wQ10K9G1weu8Q_Mz0cJ6kdpw@mail.gmail.com>
 <CAN9qwJ9Y4f3unNt7BdvPRgpEBj3paGUOVFo=CVxwu8ePpx9nng@mail.gmail.com>
Message-ID: <80CC3ADF-AD0D-44F2-B2DF-0E13F11A9673@crossivity.com>


> On 08 Mar 2016, at 16:34, Josh Luthman <josh at imaginenetworksllc.com> wrote:
> 
> AirConsole has an "all in one" solution with software and such.

+1 for AirConsole, use it for many situations and works really well.


Regards,

Michael Rave
Crossivity

From daniel.p.lacey at gmail.com  Wed Mar 16 17:31:57 2016
From: daniel.p.lacey at gmail.com (Dan Lacey)
Date: Wed, 16 Mar 2016 11:31:57 -0600
Subject: E911 (was CALEA Requirements)
In-Reply-To: <A5ACF3E4-657D-419C-99BA-E87836346166@n5tech.com>
References: <A5ACF3E4-657D-419C-99BA-E87836346166@n5tech.com>
Message-ID: <56E9988D.30001@gmail.com>

Todd,

Could you pick a more problematic venture in telecom? ;-)
I have done a couple of these.
(I just joined the list and have no idea how much you know on the subject)

My clients are wholesale customers of different local LECs (Local 
Exchange Carrier).
These are the guys that own the wire centers in your location (e.g. 
CenturyLink, Verizon, etc.)
I do not know how they work with non-wholesale customers with regards to 
E911 services.

The specifics of what will be required differ from LEC to LEC and also 
depend on the PSAP (E911 center) you will connect to.
Most people use a consultant to get this done since there will be many 
technical details related to the circuits and technical meetings with 
the LEC and PSAP.
The LECs and PSAPs are not in the business of building your network... 
so they typically don't offer much assistance.
(If you have ever submitted an ASR to a LEC, you will know what I mean).

Your first step is to get in touch with your LEC and find out what 
services they can provide.
You could also contact your PSAP and find out their interconnection 
requirements.
Then you will have some scope on the project.

If you go the wholesale route you really will need someone to guide you 
through the process.
On the other hand, if you are already a wholesale customer of a LEC, 
experienced with placing ASRs for DS0s, DS1s and multiplexors, then you 
probably can get this done in-house.

Sincerely,
Dan


From jbotctc at gmail.com  Wed Mar 16 17:54:42 2016
From: jbotctc at gmail.com (Jim Wininger)
Date: Wed, 16 Mar 2016 13:54:42 -0400
Subject: Wireless (WiFi) MOS equivalent?
Message-ID: <8D8F46F3-EA73-49CF-8FA9-686C64F5FA45@gmail.com>

Hello all,

Is there a WiFi equivalent to the VoIP MOS score?

We are looking for a way to measure performance of a fairly large WiFi deployment.

We have 8000+ access points (All Cisco). WE have the standard Cisco tools for managing the wireless network (ISE, Prime etc). But we are coming up short with a way to ?score? the network.

Does anyone have experience with this that might be able to help? How do large conferences ?measure? wireless service quality etc? We are already doing end user surveys etc. We have ?soft date?, we really need data points.

?Jim

From robert.haylock at gmail.com  Wed Mar 16 23:20:40 2016
From: robert.haylock at gmail.com (Robert Haylock)
Date: Wed, 16 Mar 2016 16:20:40 -0700
Subject: CALEA Requirements
In-Reply-To: <20160314135756.5CE29921@m0087793.ppops.net>
References: <20160314135756.5CE29921@m0087793.ppops.net>
Message-ID: <CAOfVTCFogrfJzcXC5tprNadArLQrCUsmrGo_efpinugj461rmw@mail.gmail.com>

If you are a wireline ISP, start with the ATIS-1000013* docs, you will see
from the FBI link below, different services and carrier types (e.g. voice
or cable) have additional needs on top of this.

As Scott said, your legal/regulatory team needs to guide you to exactly
which in the listMAY apply in your situation, but from a technical point of
view you can at least get an idea about what you might have to do by
starting with the ATIS specs:

https://askcalea.fbi.gov/standards.html

Rob

On 14 March 2016 at 13:57, Scott Weeks <surfer at mauigateway.com> wrote:

>
>
> --- lorell at hathcock.org wrote:
> From: "Lorell Hathcock" <lorell at hathcock.org>
>
> Can someone point me to the current CALEA requirements?
>
> As an ISP, should I be recording all internet traffic that passes my
> routers?  Or do I only have to record when and if I receive a court order?
>
> I'm not under any court order now, I just want to be sure that I am
> compliant going forward in my capabilities.
> -----------------------------------------
>
>
> This is something your company's lawyers should hash out.
> That said, you shouldn't record anything unless forced to
> do so.  It'll just make pervasive surveillance easier.
>
> scott
>

From h-kaneko at dr.jp.nec.com  Thu Mar 17 05:22:50 2016
From: h-kaneko at dr.jp.nec.com (Hiroya Kaneko)
Date: Thu, 17 Mar 2016 05:22:50 +0000
Subject: JANOG38 Meeting Call for Presentations
Message-ID: <DC46640E18378943B889470D0F6F018F8122FCCF@BPXM05GP.gisp.nec.co.jp>

Hello,

JANOG38 Meeting will take place on 6-8 July 2016 in OKINAWA, Japan.


JANOG is making a call for presentations until 15 April 2016.
Our meetings are in Japanese, but we have had several non-Japanese speakers who made presentations in the past.

We are looking forward to your proposals for presentations.


Shishio Tsuchiya,Hiroya Kaneko
JANOG38 Programme Committee Co-Chairs


----------------------------------------------------------------------
** JANOG38 MEETING
----------------------------------------------------------------------

 - Host    : OKIT Corporation 
 - Date    : 6 July., 2016 - 8 July., 2016
 - Venue   : TBD (Naha, Okinawa)
 - Fees    : Conference(6-8 July): Free
             Banquet(in the evening on 7th): TBD
----------------------------------------------------------------------
** HOW TO SUBMIT PRESENTATIONS
----------------------------------------------------------------------

If you are interested to give a presentation, submissions are welcome via e-mail at:"meeting-38[at]janog.gr.jp" with the following information.

 1. Speaker's name(s)
 2. Speaker's organization(s)
 3. Preferred contact email address
 4. Submission category (General Session or Panel Session)
    * If your choice is panel, please tell us the number of speakers  5. Presentation title  6. Abstract  7. Desired presentation time and discussion time  8. Slides (attachment or URL), in PowerPoint or PDF format.

Our Meetings are in Japanese, so non-Japanese speakers usually arrange an informal interpreter.
If you are interested in making a presentation at JANOG but cannot arrange an interpreter by yourself, you could consult with us at:
"meeting-38[at]janog.gr.jp". Although we cannot guarantee, we may be able to help you on volunteer basis.
Let us know if you have any questions : meeting-38[at]janog.gr.jp


----------------------------------------------------------------------
** THE KEY DATE FOR JANOG38 SUBMISSIONS
----------------------------------------------------------------------

CFP Deadline : 15 April 23:59 JST
The Program Committee will notify you after 25th April about your submission.


----------------------------------------------------------------------
** VISA
----------------------------------------------------------------------

Foreign visitor entering Japan must have a passport which has valid period during you stay in Japan. Passport holders from some countries are required to have a visa to visit Japan before they depart toward Japan. Many are exempt from this requirement and can get their visa on entry to Japan. Please determine whether you are exempt from the visa requirement.

Please refer to the official website from Ministry of Foreign Affairs of Japan or any other appropriate website to get more information about Visa application. Ministry of Foreign Affairs of Japan - Guide to Japanese Visas http://www.mofa.go.jp/j_info/visit/visa/index.html

List of Countries and Regions for Visa Exemptions http://www.mofa.go.jp/j_info/visit/visa/short/novisa.html

Please note that JANOG can not assist you with your visa application.
If you have any questions about the meeting, please feel free to contact meeting-38[at]janog.gr.jp.


----------------------------------------------------------------------
** ABOUT JANOG
----------------------------------------------------------------------

JANOG webpage in English is available at: http://www.janog.gr.jp/en/

----------------------------------------------------------------------

*******************************************************
Hiroya Kaneko
NEC Cloud System Research Laboratories
1753, Shimonumabe, Nakahara-ku, Kawasaki Kanagawa 211-8666, Japan TEL +8150-3381-7597
Mail: h-kaneko at dr.jp.nec.com


From edee at globalvision.net  Fri Mar 18 20:34:23 2016
From: edee at globalvision.net (Ethan E. Dee)
Date: Fri, 18 Mar 2016 16:34:23 -0400
Subject: Charter DDOS scrubbing.
Message-ID: <56EC664F.6070202@globalvision.net>

Globalvision is an ISP in greenville sc.
We are currently peering with two other ISP's we have a gig link with 
charter and are getting hammered quite hard with a full gig and more of 
DDoS on SIP, DNS, NTP, and other random UDP traffic. Alot of folks have 
said that charter will do DDoS scrubbing. Charter however is telling me 
they absolutely cannot offer this service.
Does anyone have any info on contacting charter or who to bug about this 
to get it in the works? Or does any know for certain that there's no 
reason to even ask?

-- 
Ethan Dee
Network Admin
Globalvision
864 704 3600
edee at globalvision.net

Gv-support at globalvision.net
864 467 1333



--
This message has been scanned by E.F.A. Project and is believed to be clean.



From tim at baseworx.net  Sat Mar 19 01:45:02 2016
From: tim at baseworx.net (Tim McKee)
Date: Sat, 19 Mar 2016 01:45:02 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <84be9c0e00df4e1698ab70a32dd77055@XCH-ALN-014.cisco.com>
References: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
 <20160318220248.GF44490@DOIT-2NW1MRFY-X.doit.wisc.edu>
 <84be9c0e00df4e1698ab70a32dd77055@XCH-ALN-014.cisco.com>
Message-ID: <910665b3e62c455babf3469690dc7e92@baseworx.net>

I would hazard a guess that reducing the packet header overhead *and* the Ethernet interframe gap time by a factor of 6 could make enough of an improvement to be quite noticeable when dealing with huge dataset transfers.

Tim McKee

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, March 18, 2016 18:21
To: Dale W. Carder
Cc: nanog at nanog.org
Subject: RE: Internet Exchanges supporting jumbo frames?

Then it's mainly TCP slowstart that you're trying to improve?

Thanks,
Jakob.

> -----Original Message-----
> From: Dale W. Carder [mailto:dwcarder at wisc.edu]
> Sent: Friday, March 18, 2016 3:03 PM
> To: Jakob Heitz (jheitz) <jheitz at cisco.com>
> Cc: nanog at nanog.org
> Subject: Re: Internet Exchanges supporting jumbo frames?
> 
> Thus spake Jakob Heitz (jheitz) (jheitz at cisco.com) on Fri, Mar 18, 2016 at 09:29:44PM +0000:
> > What's driving the desire for larger packets?
> 
> In our little corner of the internet, it is to increase the 
> performance of a low number of high-bdp flows which are typically dataset transfers.
> All of our non-commercial peers support 9k.
> 
> Dale

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6189 / Virus Database: 4542/11829 - Release Date: 03/17/16

From david at zeromail.us  Sat Mar 19 06:06:59 2016
From: david at zeromail.us (David S.)
Date: Sat, 19 Mar 2016 13:06:59 +0700
Subject: www.cisco.com no resolve?
In-Reply-To: <BCBCEF5D-0E54-468B-B3E4-6BBA8ED8F326@thrashyour.com>
References: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>
 <BCBCEF5D-0E54-468B-B3E4-6BBA8ED8F326@thrashyour.com>
Message-ID: <CANzCtXrqriPNEqWbRw_v6kS=niyB0yi+wtXysPMG1JYFN2-C=w@mail.gmail.com>

Hi,

Here is the dig results, yes it seems only happened to www

gizmos:~ david$ dig www.cisco.com +trace


; <<>> DiG 9.8.3-P1 <<>> www.cisco.com +trace

;; global options: +cmd

. 131 IN NS c.root-servers.net.

. 131 IN NS d.root-servers.net.

. 131 IN NS i.root-servers.net.

. 131 IN NS l.root-servers.net.

. 131 IN NS a.root-servers.net.

. 131 IN NS f.root-servers.net.

. 131 IN NS k.root-servers.net.

. 131 IN NS b.root-servers.net.

. 131 IN NS m.root-servers.net.

. 131 IN NS e.root-servers.net.

. 131 IN NS j.root-servers.net.

. 131 IN NS h.root-servers.net.

. 131 IN NS g.root-servers.net.

;; Received 228 bytes from 103.234.208.150#53(103.234.208.150) in 2473 ms


com. 172800 IN NS a.gtld-servers.net.

com. 172800 IN NS b.gtld-servers.net.

com. 172800 IN NS c.gtld-servers.net.

com. 172800 IN NS d.gtld-servers.net.

com. 172800 IN NS e.gtld-servers.net.

com. 172800 IN NS f.gtld-servers.net.

com. 172800 IN NS g.gtld-servers.net.

com. 172800 IN NS h.gtld-servers.net.

com. 172800 IN NS i.gtld-servers.net.

com. 172800 IN NS j.gtld-servers.net.

com. 172800 IN NS k.gtld-servers.net.

com. 172800 IN NS l.gtld-servers.net.

com. 172800 IN NS m.gtld-servers.net.

;; Received 491 bytes from 198.97.190.53#53(198.97.190.53) in 799 ms


cisco.com. 172800 IN NS ns1.cisco.com.

cisco.com. 172800 IN NS ns2.cisco.com.

cisco.com. 172800 IN NS ns3.cisco.com.

;; Received 217 bytes from 192.26.92.30#53(192.26.92.30) in 1197 ms


cisco.com. 86400 IN SOA edns-rtp5-1-l. postmaster.cisco.com. 16034550 7200
1800 864000 86400

;; Received 91 bytes from 72.163.5.201#53(72.163.5.201) in 243 ms


gizmos:~ david$ dig cisco.com +trace


; <<>> DiG 9.8.3-P1 <<>> cisco.com +trace

;; global options: +cmd

. 120 IN NS b.root-servers.net.

. 120 IN NS c.root-servers.net.

. 120 IN NS j.root-servers.net.

. 120 IN NS e.root-servers.net.

. 120 IN NS m.root-servers.net.

. 120 IN NS l.root-servers.net.

. 120 IN NS h.root-servers.net.

. 120 IN NS a.root-servers.net.

. 120 IN NS g.root-servers.net.

. 120 IN NS k.root-servers.net.

. 120 IN NS i.root-servers.net.

. 120 IN NS d.root-servers.net.

. 120 IN NS f.root-servers.net.

;; Received 228 bytes from 103.234.208.150#53(103.234.208.150) in 48 ms


com. 172800 IN NS d.gtld-servers.net.

com. 172800 IN NS l.gtld-servers.net.

com. 172800 IN NS g.gtld-servers.net.

com. 172800 IN NS e.gtld-servers.net.

com. 172800 IN NS b.gtld-servers.net.

com. 172800 IN NS c.gtld-servers.net.

com. 172800 IN NS k.gtld-servers.net.

com. 172800 IN NS i.gtld-servers.net.

com. 172800 IN NS m.gtld-servers.net.

com. 172800 IN NS j.gtld-servers.net.

com. 172800 IN NS f.gtld-servers.net.

com. 172800 IN NS h.gtld-servers.net.

com. 172800 IN NS a.gtld-servers.net.

;; Received 499 bytes from 192.36.148.17#53(192.36.148.17) in 41 ms


cisco.com. 172800 IN NS ns1.cisco.com.

cisco.com. 172800 IN NS ns2.cisco.com.

cisco.com. 172800 IN NS ns3.cisco.com.

;; Received 213 bytes from 192.31.80.30#53(192.31.80.30) in 355 ms


cisco.com. 86400 IN A 72.163.4.161

cisco.com. 86400 IN NS ns2.cisco.com.

cisco.com. 86400 IN NS ns3.cisco.com.

cisco.com. 86400 IN NS ns1.cisco.com.

;; Received 229 bytes from 72.163.5.201#53(72.163.5.201) in 415 ms


Thank you

Best regards,
David S.
------------------------------------------------
e. david at zeromail.us

On Sat, Mar 19, 2016 at 12:53 PM, John Kinsella <jlk at thrashyour.com> wrote:

> Confirmed in Northern California, on all 3 primary NS servers. A little
> Friday night maintenance window, maybe?
>
> Looks like it?s just the www record...
>
> > On Mar 18, 2016, at 10:38 PM, Dmitry Sherman <dmitry at interhost.net>
> wrote:
> >
> > dig www.cisco.com @8.8.8.8
> >
> >
> > ; <<>> DiG 9.8.3-P1 <<>> www.cisco.com @8.8.8.8
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60416
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> >
> >
> > ;; QUESTION SECTION:
> > ;www.cisco.com.                       IN      A
> >
> >
> > ;; AUTHORITY SECTION:
> > cisco.com.            1247    IN      SOA     edns-rtp5-1-l.
> postmaster.cisco.com. 16034550 7200 1800 864000 86400
> >
> >
> > ;; Query time: 94 msec
> > ;; SERVER: 8.8.8.8#53(8.8.8.8)
> > ;; WHEN: Sat Mar 19 07:36:22 2016
> > ;; MSG SIZE  rcvd: 91
> >
> >
> >
> >
> >
> > ?
> > Dmitry Sherman
> > Interhost Networks Ltd
> > dmitry at interhost.net
> > office: 972-74-7029881
> > mobile: 972-54-3181182
> > http://www.interhost.co.il
> >
> >
> >
> >
> >
> >>
>
>

From daniel.p.lacey at gmail.com  Sat Mar 19 16:09:52 2016
From: daniel.p.lacey at gmail.com (Dan Lacey)
Date: Sat, 19 Mar 2016 10:09:52 -0600
Subject: www.cisco.com no resolve?
In-Reply-To: <20160319145140.GA4981@nic.fr>
References: <A64074E9-E5EA-41C6-A3E0-9A71B9F44723@interhost.net>
 <20160319145140.GA4981@nic.fr>
Message-ID: <56ED79D0.3010408@gmail.com>

They did announce a maintenance window on their website.
Must have been a doozy.

On 3/19/16 8:51 AM, Stephane Bortzmeyer wrote:
> On Sat, Mar 19, 2016 at 05:38:03AM +0000,
>   Dmitry Sherman <dmitry at interhost.net> wrote
>   a message of 13 lines which said:
>
>> dig www.cisco.com @8.8.8.8
> Better to test through the authoritative name servers. The problem was
> there, as documented in
> <https://www.reddit.com/r/networking/comments/4b2bgo/cisco_website_is_down/d15iu63>
>
> So, it was not because of the long CNAME chain, unlike what I wrote
> previously.
>
>


From tim at baseworx.net  Sat Mar 19 21:49:01 2016
From: tim at baseworx.net (Tim McKee)
Date: Sat, 19 Mar 2016 21:49:01 +0000
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <D7B8992A-B4EC-4EBF-8332-A0F87D9B8FE3@cisco.com>
References: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
 <20160318220248.GF44490@DOIT-2NW1MRFY-X.doit.wisc.edu>
 <84be9c0e00df4e1698ab70a32dd77055@XCH-ALN-014.cisco.com>,
 <910665b3e62c455babf3469690dc7e92@baseworx.net>
 <D7B8992A-B4EC-4EBF-8332-A0F87D9B8FE3@cisco.com>
Message-ID: <08d0aa25565c44679307ca50a074e38b@baseworx.net>

The factor of 6 was just in reduction of overhead.  Granted in the greater scheme of things the overall 4% is relatively insignificant, but there have been many times when doing multiple 10-100+GB transfers that I would have welcomed a 4% reduction of time spent twiddling thumbs!

-----Original Message-----
From: Jakob Heitz (jheitz) [mailto:jheitz at cisco.com] 
Sent: Saturday, March 19, 2016 00:34
To: Tim McKee
Cc: Dale W. Carder; nanog at nanog.org
Subject: Re: Internet Exchanges supporting jumbo frames?

You would hardly notice it.
Helium is 4 times as heavy as hydrogen, but only marginally less buoyant.

Header overhead:
Ethernet=38
IPv4=20
TCP=20
Total=78
Protocol efficiency:
1500: 1500/1578 = 95%
9000: 9000/9078 = 99%

That's 4% better for a TCP packet, not 600%.

Thanks,
Jakob.


> On Mar 18, 2016, at 6:45 PM, Tim McKee <tim at baseworx.net> wrote:
> 
> I would hazard a guess that reducing the packet header overhead *and* the Ethernet interframe gap time by a factor of 6 could make enough of an improvement to be quite noticeable when dealing with huge dataset transfers.
> 
> Tim McKee
> 
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jakob Heitz 
> (jheitz)
> Sent: Friday, March 18, 2016 18:21
> To: Dale W. Carder
> Cc: nanog at nanog.org
> Subject: RE: Internet Exchanges supporting jumbo frames?
> 
> Then it's mainly TCP slowstart that you're trying to improve?
> 
> Thanks,
> Jakob.
> 
>> -----Original Message-----
>> From: Dale W. Carder [mailto:dwcarder at wisc.edu]
>> Sent: Friday, March 18, 2016 3:03 PM
>> To: Jakob Heitz (jheitz) <jheitz at cisco.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Internet Exchanges supporting jumbo frames?
>> 
>> Thus spake Jakob Heitz (jheitz) (jheitz at cisco.com) on Fri, Mar 18, 2016 at 09:29:44PM +0000:
>>> What's driving the desire for larger packets?
>> 
>> In our little corner of the internet, it is to increase the 
>> performance of a low number of high-bdp flows which are typically dataset transfers.
>> All of our non-commercial peers support 9k.
>> 
>> Dale
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6189 / Virus Database: 4542/11829 - Release Date: 
> 03/17/16

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6189 / Virus Database: 4542/11841 - Release Date: 03/19/16

From warren at kumari.net  Sat Mar 19 23:16:33 2016
From: warren at kumari.net (Warren Kumari)
Date: Sat, 19 Mar 2016 23:16:33 +0000
Subject: Oh dear, we've all been made redundant...
Message-ID: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>

Found on Staple's website:
http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686

Fixes all issues, less downtime, less stress...
Improves performance, eliminates buffering...
It slices, it dices in teeny, tiny slices.
It makes mounds of julienne fries in just seconds.
...

Description - copied here for convenience:

All the issues associated with the Internet being down can be solved by
power cycling the modem and router. But that can be hard to do! NetReset
resolves network issues by offering sequential power cycling. This means
that when the modem and router are plugged into the device, they are
powered up at different times. The modem is powered up first, then a minute
later, the router is powered up. This rebooting will occur at initial
setup, every 24 hours and after a power failure. Do you have a modem/router
combo? No problem! NetReset will also power cycle the modem/router combo.


Automatically resets user's Internet every 24 hours
Maximizes Internet speed & reliability
Eliminates media stream buffering
Hands-free Internet reset
Resets hard-to-reach modem/router
Less Internet downtime
Less daily stress
No need to manually reset
Reset occurs at programmed time
Updated information from Internet service provider
Proper reboot after a power failure
Resetting allows equipment to auto-correct issues

From tim at baseworx.net  Sun Mar 20 01:30:22 2016
From: tim at baseworx.net (Tim McKee)
Date: Sun, 20 Mar 2016 01:30:22 +0000
Subject: junkmailers take the day off....?
In-Reply-To: <56EDFCC9.4050305@tiedyenetworks.com>
References: <56EDFCC9.4050305@tiedyenetworks.com>
Message-ID: <c7ffd92ec6424f63b390a355a2679c8a@baseworx.net>

We can only hope it is so...

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike
Sent: Saturday, March 19, 2016 21:29
To: nanog at nanog.org
Subject: junkmailers take the day off....?

Hi,

     This is not a complaint, but today seems to be a major disturbance in the force...my junkmail load seems to be WAAAYYYY down today, like they all are out at the beach or something... some major botnet get shutdown or something???

Mike

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6189 / Virus Database: 4542/11841 - Release Date: 03/19/16

From dovid at telecurve.com  Sun Mar 20 15:20:35 2016
From: dovid at telecurve.com (Dovid Bender)
Date: Sun, 20 Mar 2016 11:20:35 -0400
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <CAM3TTh0Ej-qJqX-Nf3GUej+Pranp4OycOFvf6GP8ZhOvTNB5tg@mail.gmail.com>

How does a reboot fix layer 2 issues?

On Sat, Mar 19, 2016 at 7:16 PM, Warren Kumari <warren at kumari.net> wrote:

> Found on Staple's website:
>
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
>
> Fixes all issues, less downtime, less stress...
> Improves performance, eliminates buffering...
> It slices, it dices in teeny, tiny slices.
> It makes mounds of julienne fries in just seconds.
> ...
>
> Description - copied here for convenience:
>
> All the issues associated with the Internet being down can be solved by
> power cycling the modem and router. But that can be hard to do! NetReset
> resolves network issues by offering sequential power cycling. This means
> that when the modem and router are plugged into the device, they are
> powered up at different times. The modem is powered up first, then a minute
> later, the router is powered up. This rebooting will occur at initial
> setup, every 24 hours and after a power failure. Do you have a modem/router
> combo? No problem! NetReset will also power cycle the modem/router combo.
>
>
> Automatically resets user's Internet every 24 hours
> Maximizes Internet speed & reliability
> Eliminates media stream buffering
> Hands-free Internet reset
> Resets hard-to-reach modem/router
> Less Internet downtime
> Less daily stress
> No need to manually reset
> Reset occurs at programmed time
> Updated information from Internet service provider
> Proper reboot after a power failure
> Resetting allows equipment to auto-correct issues
>

From floriancrosnier at hacari.net  Sun Mar 20 15:27:05 2016
From: floriancrosnier at hacari.net (Florian Crosnier)
Date: Sun, 20 Mar 2016 16:27:05 +0100
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAM3TTh0Ej-qJqX-Nf3GUej+Pranp4OycOFvf6GP8ZhOvTNB5tg@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <CAM3TTh0Ej-qJqX-Nf3GUej+Pranp4OycOFvf6GP8ZhOvTNB5tg@mail.gmail.com>
Message-ID: <56EEC149.9070503@hacari.net>

"Have you tried turning it off and on again ?"

On 03/20/2016 04:20 PM, Dovid Bender wrote:
> How does a reboot fix layer 2 issues?
>
> On Sat, Mar 19, 2016 at 7:16 PM, Warren Kumari <warren at kumari.net> wrote:
>
>> Found on Staple's website:
>>
>> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
>>
>> Fixes all issues, less downtime, less stress...
>> Improves performance, eliminates buffering...
>> It slices, it dices in teeny, tiny slices.
>> It makes mounds of julienne fries in just seconds.
>> ...
>>
>> Description - copied here for convenience:
>>
>> All the issues associated with the Internet being down can be solved by
>> power cycling the modem and router. But that can be hard to do! NetReset
>> resolves network issues by offering sequential power cycling. This means
>> that when the modem and router are plugged into the device, they are
>> powered up at different times. The modem is powered up first, then a minute
>> later, the router is powered up. This rebooting will occur at initial
>> setup, every 24 hours and after a power failure. Do you have a modem/router
>> combo? No problem! NetReset will also power cycle the modem/router combo.
>>
>>
>> Automatically resets user's Internet every 24 hours
>> Maximizes Internet speed & reliability
>> Eliminates media stream buffering
>> Hands-free Internet reset
>> Resets hard-to-reach modem/router
>> Less Internet downtime
>> Less daily stress
>> No need to manually reset
>> Reset occurs at programmed time
>> Updated information from Internet service provider
>> Proper reboot after a power failure
>> Resetting allows equipment to auto-correct issues
>>


From cb.list6 at gmail.com  Sun Mar 20 16:00:08 2016
From: cb.list6 at gmail.com (Ca By)
Date: Sun, 20 Mar 2016 09:00:08 -0700
Subject: Charter DDOS scrubbing.
In-Reply-To: <56EC664F.6070202@globalvision.net>
References: <56EC664F.6070202@globalvision.net>
Message-ID: <CAD6AjGQAr6STv9PZbW8zJWSkZ_x-=zS7SokmDdcHQCMSP5DbDA@mail.gmail.com>

On Friday, March 18, 2016, Ethan E. Dee <edee at globalvision.net> wrote:

> Globalvision is an ISP in greenville sc.
> We are currently peering with two other ISP's we have a gig link with
> charter and are getting hammered quite hard with a full gig and more of
> DDoS on SIP, DNS, NTP, and other random UDP traffic. Alot of folks have
> said that charter will do DDoS scrubbing. Charter however is telling me
> they absolutely cannot offer this service.
> Does anyone have any info on contacting charter or who to bug about this
> to get it in the works? Or does any know for certain that there's no reason
> to even ask?
>
> --
> Ethan Dee
> Network Admin
> Globalvision
> 864 704 3600
> edee at globalvision.net
>
> Gv-support at globalvision.net
> 864 467 1333
>
>
If you are paying them, they should be able to police ipv4 udp to some
reasonable baseline.  This is a smart proactive method.

They should also be able to put in an acl to simply block udp source ports
that are problem ... Each of these need to be weighed on customer impact
for blocking source udp 53, ntp, ssdp , chargen , frags..

There is also rtbh.

I would avoid scrubbers, acls and policers and rtbh work.



>
> --
> This message has been scanned by E.F.A. Project and is believed to be
> clean.
>
>
>

From sean at donelan.com  Sun Mar 20 16:04:15 2016
From: sean at donelan.com (Sean Donelan)
Date: Sun, 20 Mar 2016 12:04:15 -0400 (EDT)
Subject: CALEA Requirements
In-Reply-To: <CAOfVTCFogrfJzcXC5tprNadArLQrCUsmrGo_efpinugj461rmw@mail.gmail.com>
References: <20160314135756.5CE29921@m0087793.ppops.net>
 <CAOfVTCFogrfJzcXC5tprNadArLQrCUsmrGo_efpinugj461rmw@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1603201146220.22084@cnex.qbaryna.pbz>

The FBI CALEA folks have always had a somewhat expansive interpretation of 
their authorities.

For example, "dialed digit extraction."  The court cases supporting pen 
registers are based on business record exception, i.e. Smith v. Maryland 
says dial numbers are disclosed to the telephone company so the phone 
company can connect and bill the call do not have a reasonable 
expectation of privacy. The FBI expanded its pen-register authority to 
include all numbers dialed *DURING* the call because in the 1970's 
pen-register technology didn't stop recording digits (i.e. the "clicks") 
after a call was answered.  Although modern pen-register technology can 
distinguish between numbers dialed for the purpose of connecting the call, 
and numbers dialed during the call (i.e. your online banking PIN), and 
dialed digit extraction during VOIP calls is an extreme pain in the ass.

In the 1990's, the FBI convinced the FCC to order carriers under CALEA to 
do dialed digit extraction because "that's what they've always done," not 
because its what the law and court cases required.  Even the FCC says in 
its CALEA order, the FBI's justification was flimsy but the FCC wasn't 
willing to oppose the FBI.

As several folks have pointed out, talk to your own legal counsel.  The
FBI CALEA website is the FBI's interpretation of its authority, not 
necessarily what your own counsel would advise.

From todd.crane at n5tech.com  Sun Mar 20 16:10:07 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Sun, 20 Mar 2016 09:10:07 -0700
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <65D1D6DC-5F83-4193-B02D-607A852FE2D0@n5tech.com>

"Eliminates media stream buffering?

Well, hell? my job is done here. [drops mic, walks out]

> On Mar 19, 2016, at 4:16 PM, Warren Kumari <warren at kumari.net> wrote:
> 
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
> 
> Fixes all issues, less downtime, less stress...
> Improves performance, eliminates buffering...
> It slices, it dices in teeny, tiny slices.
> It makes mounds of julienne fries in just seconds.
> ...
> 
> Description - copied here for convenience:
> 
> All the issues associated with the Internet being down can be solved by
> power cycling the modem and router. But that can be hard to do! NetReset
> resolves network issues by offering sequential power cycling. This means
> that when the modem and router are plugged into the device, they are
> powered up at different times. The modem is powered up first, then a minute
> later, the router is powered up. This rebooting will occur at initial
> setup, every 24 hours and after a power failure. Do you have a modem/router
> combo? No problem! NetReset will also power cycle the modem/router combo.
> 
> 
> Automatically resets user's Internet every 24 hours
> Maximizes Internet speed & reliability
> Eliminates media stream buffering
> Hands-free Internet reset
> Resets hard-to-reach modem/router
> Less Internet downtime
> Less daily stress
> No need to manually reset
> Reset occurs at programmed time
> Updated information from Internet service provider
> Proper reboot after a power failure
> Resetting allows equipment to auto-correct issues

-------------- 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/20160320/b8e0eca0/attachment.pgp>

From mike-nanog at tiedyenetworks.com  Sun Mar 20 17:22:05 2016
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Sun, 20 Mar 2016 10:22:05 -0700
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <56EEDC3D.4010804@tiedyenetworks.com>


This is great, I now have something I can show to my customers to 
confirm that all this power cycling and such really is an 'accepted 
problem'...

On 03/19/2016 04:16 PM, Warren Kumari wrote:
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
>
> Fixes all issues, less downtime, less stress...
> Improves performance, eliminates buffering...
> It slices, it dices in teeny, tiny slices.
> It makes mounds of julienne fries in just seconds.
> ...
>
> Description - copied here for convenience:
>
> All the issues associated with the Internet being down can be solved by
> power cycling the modem and router. But that can be hard to do! NetReset
> resolves network issues by offering sequential power cycling. This means
> that when the modem and router are plugged into the device, they are
> powered up at different times. The modem is powered up first, then a minute
> later, the router is powered up. This rebooting will occur at initial
> setup, every 24 hours and after a power failure. Do you have a modem/router
> combo? No problem! NetReset will also power cycle the modem/router combo.
>
>
> Automatically resets user's Internet every 24 hours
> Maximizes Internet speed & reliability
> Eliminates media stream buffering
> Hands-free Internet reset
> Resets hard-to-reach modem/router
> Less Internet downtime
> Less daily stress
> No need to manually reset
> Reset occurs at programmed time
> Updated information from Internet service provider
> Proper reboot after a power failure
> Resetting allows equipment to auto-correct issues
>
>


From david.soltero at icann.org  Sun Mar 20 18:38:07 2016
From: david.soltero at icann.org (David Soltero)
Date: Sun, 20 Mar 2016 18:38:07 +0000
Subject: Reminder of the L-Root IPv6 address renumbering
In-Reply-To: <4976098F-4F4F-4CFF-B8D5-056FEF8A200C@icann.org>
References: <4976098F-4F4F-4CFF-B8D5-056FEF8A200C@icann.org>
Message-ID: <3E34C989-D54C-4AC4-803E-A721D7574CD9@icann.org>

This is reminder that there is a scheduled change to the IPv6 addresses for the L-Root server, that will take effect on March 23, 2016.

The new IP addresses for the L.ROOT-SERVERS.NET will be:
199.7.83.42
2001:500:9f::42

Please remember to update your root ?hints? files on your DNS infrastructure.

From bzs at theworld.com  Sun Mar 20 18:37:00 2016
From: bzs at theworld.com (bzs at theworld.com)
Date: Sun, 20 Mar 2016 14:37:00 -0400
Subject: junkmailers take the day off....?
In-Reply-To: <56EDFCC9.4050305@tiedyenetworks.com>
References: <56EDFCC9.4050305@tiedyenetworks.com>
Message-ID: <22254.60876.365331.144305@pcls8.std.com>


On March 19, 2016 at 18:28 mike-nanog at tiedyenetworks.com (Mike) wrote:
 > Hi,
 > 
 >      This is not a complaint, but today seems to be a major disturbance 
 > in the force...my junkmail load seems to be WAAAYYYY down today, like 
 > they all are out at the beach or something... some major botnet get 
 > shutdown or something???

Something which has long worried me is that they get smart enough to
stop spamming network admins and similar.

-- 
        -Barry Shein

Software Tool & Die    | bzs at TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

From mmg at transtelco.net  Sun Mar 20 18:58:43 2016
From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=)
Date: Sun, 20 Mar 2016 12:58:43 -0600
Subject: 10G tester recommendation
Message-ID: <CAD0TWZ_75CwaC_-pjo++Ss4xrdRQmD2QyO70zkkfPR6hu6J4Tw@mail.gmail.com>

Hi Nanog community


We are looking 10G testers for BER and RFC2544 tests and I was wondering if
additional to the JDSU/Viavi, is there something else that you can
recommend like Exfo, Fluke, etc?

Your input will be appreciate it

Thank you and have a great day

From r.engehausen at gmail.com  Sun Mar 20 19:07:31 2016
From: r.engehausen at gmail.com (Roy)
Date: Sun, 20 Mar 2016 12:07:31 -0700
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <56EEDC3D.4010804@tiedyenetworks.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
Message-ID: <56EEF4F3.6030201@gmail.com>



Here is an even better one.  This one recycles the power when it loses 
contact with the internet.

http://resetplug.com/

On 3/20/2016 10:22 AM, Mike wrote:
>
> This is great, I now have something I can show to my customers to 
> confirm that all this power cycling and such really is an 'accepted 
> problem'...
>
> On 03/19/2016 04:16 PM, Warren Kumari wrote:
>> Found on Staple's website:
>> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686 
>>
>>
>> Fixes all issues, less downtime, less stress...
>> Improves performance, eliminates buffering...
>> It slices, it dices in teeny, tiny slices.
>> It makes mounds of julienne fries in just seconds.
>> ...
>>
>> Description - copied here for convenience:
>>
>> All the issues associated with the Internet being down can be solved by
>> power cycling the modem and router. But that can be hard to do! NetReset
>> resolves network issues by offering sequential power cycling. This means
>> that when the modem and router are plugged into the device, they are
>> powered up at different times. The modem is powered up first, then a 
>> minute
>> later, the router is powered up. This rebooting will occur at initial
>> setup, every 24 hours and after a power failure. Do you have a 
>> modem/router
>> combo? No problem! NetReset will also power cycle the modem/router 
>> combo.
>>
>>
>> Automatically resets user's Internet every 24 hours
>> Maximizes Internet speed & reliability
>> Eliminates media stream buffering
>> Hands-free Internet reset
>> Resets hard-to-reach modem/router
>> Less Internet downtime
>> Less daily stress
>> No need to manually reset
>> Reset occurs at programmed time
>> Updated information from Internet service provider
>> Proper reboot after a power failure
>> Resetting allows equipment to auto-correct issues
>>
>>
>
>


From jared at puck.nether.net  Sun Mar 20 19:34:04 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Sun, 20 Mar 2016 15:34:04 -0400
Subject: Wireless (WiFi) MOS equivalent?
In-Reply-To: <8D8F46F3-EA73-49CF-8FA9-686C64F5FA45@gmail.com>
References: <8D8F46F3-EA73-49CF-8FA9-686C64F5FA45@gmail.com>
Message-ID: <B50638E6-EA39-4F2A-8B2A-BEB2C01DE9EE@puck.nether.net>

I've seen some conferences do a virtual participant device that joins the wifi and reports back data. 

Jared Mauch

> On Mar 16, 2016, at 1:54 PM, Jim Wininger <jbotctc at gmail.com> wrote:
> 
> Hello all,
> 
> Is there a WiFi equivalent to the VoIP MOS score?
> 
> We are looking for a way to measure performance of a fairly large WiFi deployment.
> 
> We have 8000+ access points (All Cisco). WE have the standard Cisco tools for managing the wireless network (ISE, Prime etc). But we are coming up short with a way to ?score? the network.
> 
> Does anyone have experience with this that might be able to help? How do large conferences ?measure? wireless service quality etc? We are already doing end user surveys etc. We have ?soft date?, we really need data points.
> 
> ?Jim


From joelja at bogus.com  Sun Mar 20 19:41:05 2016
From: joelja at bogus.com (joel jaeggli)
Date: Sun, 20 Mar 2016 12:41:05 -0700
Subject: Wireless (WiFi) MOS equivalent?
In-Reply-To: <B50638E6-EA39-4F2A-8B2A-BEB2C01DE9EE@puck.nether.net>
References: <8D8F46F3-EA73-49CF-8FA9-686C64F5FA45@gmail.com>
 <B50638E6-EA39-4F2A-8B2A-BEB2C01DE9EE@puck.nether.net>
Message-ID: <9ff0aab1-7fd0-bf64-0d7e-face86c4d137@bogus.com>

On 3/20/16 12:34 PM, Jared Mauch wrote:
> I've seen some conferences do a virtual participant device that joins the wifi and reports back data. 

netbeez is an example of one such device.

https://netbeez.net

> Jared Mauch
> 
>> On Mar 16, 2016, at 1:54 PM, Jim Wininger <jbotctc at gmail.com> wrote:
>>
>> Hello all,
>>
>> Is there a WiFi equivalent to the VoIP MOS score?
>>
>> We are looking for a way to measure performance of a fairly large WiFi deployment.
>>
>> We have 8000+ access points (All Cisco). WE have the standard Cisco tools for managing the wireless network (ISE, Prime etc). But we are coming up short with a way to ?score? the network.
>>
>> Does anyone have experience with this that might be able to help? How do large conferences ?measure? wireless service quality etc? We are already doing end user surveys etc. We have ?soft date?, we really need data points.
>>
>> ?Jim
> 
> 


-------------- 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/20160320/fc0d3066/attachment.pgp>

From dan at drakontas.org  Sun Mar 20 19:42:38 2016
From: dan at drakontas.org (Daniel C. Eckert)
Date: Sun, 20 Mar 2016 12:42:38 -0700
Subject: Wireless (WiFi) MOS equivalent?
In-Reply-To: <B50638E6-EA39-4F2A-8B2A-BEB2C01DE9EE@puck.nether.net>
References: <8D8F46F3-EA73-49CF-8FA9-686C64F5FA45@gmail.com>
 <B50638E6-EA39-4F2A-8B2A-BEB2C01DE9EE@puck.nether.net>
Message-ID: <CAGNc-gALyOY94XWTCjBxVYNeLBU7xAi3Cv2oaCoRQ-=eFT8j+g@mail.gmail.com>

When we do large events, we use the "virtual participant" type of testing
(throughput, latency, connection time from clients we control at different
locations in the venue) in addition to regular infrastructure-side metrics
like RSSI, SNR, last known receive data rate, and system-specific metrics
(we often use Aerohive gear, which has additional metrics like Radio
Health, Network Health, Application Health).

I'd suggest taking a look at what aspects of the network matter most for
your deployments and developing a score based on the primary influencing
metrics; most of it should be doable from the infrastructure side, but you
may also consider the virtual participant option for additional data
collection.

Dan

On Sun, Mar 20, 2016 at 12:34 PM, Jared Mauch <jared at puck.nether.net> wrote:

> I've seen some conferences do a virtual participant device that joins the
> wifi and reports back data.
>
> Jared Mauch
>
> > On Mar 16, 2016, at 1:54 PM, Jim Wininger <jbotctc at gmail.com> wrote:
> >
> > Hello all,
> >
> > Is there a WiFi equivalent to the VoIP MOS score?
> >
> > We are looking for a way to measure performance of a fairly large WiFi
> deployment.
> >
> > We have 8000+ access points (All Cisco). WE have the standard Cisco
> tools for managing the wireless network (ISE, Prime etc). But we are coming
> up short with a way to ?score? the network.
> >
> > Does anyone have experience with this that might be able to help? How do
> large conferences ?measure? wireless service quality etc? We are already
> doing end user surveys etc. We have ?soft date?, we really need data points.
> >
> > ?Jim
>
>
?

From eric at lumaoptics.net  Sun Mar 20 20:38:17 2016
From: eric at lumaoptics.net (Eric Litvin)
Date: Sun, 20 Mar 2016 13:38:17 -0700
Subject: 10G tester recommendation
In-Reply-To: <CAD0TWZ_75CwaC_-pjo++Ss4xrdRQmD2QyO70zkkfPR6hu6J4Tw@mail.gmail.com>
References: <CAD0TWZ_75CwaC_-pjo++Ss4xrdRQmD2QyO70zkkfPR6hu6J4Tw@mail.gmail.com>
Message-ID: <47082DC1-1DC3-4FC4-AB01-5016C9D3FA5A@lumaoptics.net>

Manuel- my company, luma optics,  has a handheld  to offer at a very affordable price relative to the big brands. It would be my pleasure to follow up with you to discuss further.

Regards

Eric Litvin
650 996 7270
Eric at lumaoptics.net
PROGRAMMABLE SFP XFP QSFP CFP & Optical Test Equipment



> On Mar 20, 2016, at 11:58 AM, Manuel Mar?n <mmg at transtelco.net> wrote:
> 
> Hi Nanog community
> 
> 
> We are looking 10G testers for BER and RFC2544 tests and I was wondering if
> additional to the JDSU/Viavi, is there something else that you can
> recommend like Exfo, Fluke, etc?
> 
> Your input will be appreciate it
> 
> Thank you and have a great day

From Valdis.Kletnieks at vt.edu  Sun Mar 20 22:13:57 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 20 Mar 2016 18:13:57 -0400
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <56EEF4F3.6030201@gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com> <56EEF4F3.6030201@gmail.com>
Message-ID: <96313.1458512037@turing-police.cc.vt.edu>

On Sun, 20 Mar 2016 12:07:31 -0700, Roy said:

> Here is an even better one.  This one recycles the power when it loses
> contact with the internet.

Depending on its definition of "lose contact with the Interent", that could
result in interesting failure modes - everything from hundreds of them bouncing
boxes if an upstream router has a BGP flap, to thousands of them DDoS'ing
the test point, and then bouncing boxes... It probably also interacts
badly with power monitoring hardware/software that labels too many power
"faults" in a period of time as a danger situation and holds off on bringing
boxes back online until stability is restored....
-------------- 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/20160320/263870e6/attachment.pgp>

From larrysheldon at cox.net  Mon Mar 21 04:00:36 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sun, 20 Mar 2016 23:00:36 -0500
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <56EF71E4.4070501@cox.net>

On 3/19/2016 18:16, Warren Kumari wrote:
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
>
> Fixes all issues, less downtime, less stress...

etc...
.......
........
...and so forth
................
.................
..................and so on.

> Resetting allows equipment to auto-correct issues

Recalls to mind years ago in the Toll testroom where I work, the 
evenings equipment man (charged with and assigned to the task of 
repairing equipment that had been "patched out" by the day shift) would, 
when he arrived for work each day, retrieve the piece of 2 X 4 from its 
hiding place and whack each bay of relay-rich equipment as he walked in 
the area.

Then, after some coffee and a cigarette, he would go through the 
trouble-ticket collection, retest the item, mark the ticket "NTF" and 
proceed to the next item.

-- 
sed quis custodiet ipsos custodes? (Juvenal)

From khelms at zcorum.com  Mon Mar 21 11:35:52 2016
From: khelms at zcorum.com (Scott Helms)
Date: Mon, 21 Mar 2016 07:35:52 -0400
Subject: Wireless (WiFi) MOS equivalent?
In-Reply-To: <8D8F46F3-EA73-49CF-8FA9-686C64F5FA45@gmail.com>
References: <8D8F46F3-EA73-49CF-8FA9-686C64F5FA45@gmail.com>
Message-ID: <CAMrdfRyr3tBNhs50GQ3wfQ0XsuqQgr=_tMPp_DntWZ=8Onc6rw@mail.gmail.com>

Jim,

There isn't such an animal and that's because the notion of an opinion
score for voice is pretty easy to quantify, but a good WiFi experience
depends a lot more on what you find to be acceptable for your deployment
and that normally depends a lot on your budget.  What we do is determine
what our target metrics are and then measure to that, most of the
commercial APs and controllers can provide all this data, average speed,
clients per AP, average RSSI, number of associations and auths per minute,
and error counts.  The reason you can't just get an industry standardized
score is that while most conferences are happy if the average PHY speed is
over 6 mbps that's clearly bad in an enterprise service.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Wed, Mar 16, 2016 at 1:54 PM, Jim Wininger <jbotctc at gmail.com> wrote:

> Hello all,
>
> Is there a WiFi equivalent to the VoIP MOS score?
>
> We are looking for a way to measure performance of a fairly large WiFi
> deployment.
>
> We have 8000+ access points (All Cisco). WE have the standard Cisco tools
> for managing the wireless network (ISE, Prime etc). But we are coming up
> short with a way to ?score? the network.
>
> Does anyone have experience with this that might be able to help? How do
> large conferences ?measure? wireless service quality etc? We are already
> doing end user surveys etc. We have ?soft date?, we really need data points.
>
> ?Jim

From eric at lumaoptics.net  Mon Mar 21 15:17:19 2016
From: eric at lumaoptics.net (Eric Litvin)
Date: Mon, 21 Mar 2016 08:17:19 -0700
Subject: 10G tester recommendation
In-Reply-To: <7463E81A-CA51-48E7-A262-E022D7CBC38F@onholyground.com>
References: <CAD0TWZ_75CwaC_-pjo++Ss4xrdRQmD2QyO70zkkfPR6hu6J4Tw@mail.gmail.com>
 <47082DC1-1DC3-4FC4-AB01-5016C9D3FA5A@lumaoptics.net>
 <7463E81A-CA51-48E7-A262-E022D7CBC38F@onholyground.com>
Message-ID: <15246E54-D20E-4604-AA93-6DAC2E6A0D57@lumaoptics.net>

Yes Darrell   We have a 19" rackmount 1U optical channel monitoring.  Unit plugs into the monitor port of the Mux and enables DWDM Channel Monitoring - i.e power levels and OSNR.  It can be accessed remotely over SNMP. 

Regards,

Eric Litvin
650 996 7270
Eric at lumaoptics.net
PROGRAMMABLE SFP XFP QSFP CFP



> On Mar 21, 2016, at 8:04 AM, Darrell Budic <budic at onholyground.com> wrote:
> 
> Eric, saw this on the NANOG lists, figured I?d ask. I?m looking for a device to set on the monitor port of a DWDM mux and provide statistics over an attached network interface via SNMP or cli. Do you have such a product, or know of one?
> 
> Thanks!
> 
>  -Darrell
> 
> 
>> On Mar 20, 2016, at 3:38 PM, Eric Litvin <eric at lumaoptics.net> wrote:
>> 
>> Manuel- my company, luma optics,  has a handheld  to offer at a very affordable price relative to the big brands. It would be my pleasure to follow up with you to discuss further.
>> 
>> Regards
>> 
>> Eric Litvin
>> 650 996 7270
>> Eric at lumaoptics.net
>> PROGRAMMABLE SFP XFP QSFP CFP & Optical Test Equipment
>> 
>> 
>> 
>>> On Mar 20, 2016, at 11:58 AM, Manuel Mar?n <mmg at transtelco.net> wrote:
>>> 
>>> Hi Nanog community
>>> 
>>> 
>>> We are looking 10G testers for BER and RFC2544 tests and I was wondering if
>>> additional to the JDSU/Viavi, is there something else that you can
>>> recommend like Exfo, Fluke, etc?
>>> 
>>> Your input will be appreciate it
>>> 
>>> Thank you and have a great day
> 

From dot at dotat.at  Mon Mar 21 15:26:18 2016
From: dot at dotat.at (Tony Finch)
Date: Mon, 21 Mar 2016 15:26:18 +0000
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <alpine.LSU.2.00.1603211526000.19314@hermes-2.csi.cam.ac.uk>

Warren Kumari <warren at kumari.net> wrote:

> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686

http://thedailywtf.com/articles/ITAPPMONROBOT

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Northwesterly 5 to 7, decreasing 4 later. Moderate or
rough. Occasional rain. Moderate or good.

From chuckchurch at gmail.com  Mon Mar 21 15:42:27 2016
From: chuckchurch at gmail.com (Chuck Church)
Date: Mon, 21 Mar 2016 11:42:27 -0400
Subject: Internet Exchanges supporting jumbo frames?
In-Reply-To: <08d0aa25565c44679307ca50a074e38b@baseworx.net>
References: <fe4a793a6e694c50af7d08ff7043fa30@XCH-ALN-014.cisco.com>
 <20160318220248.GF44490@DOIT-2NW1MRFY-X.doit.wisc.edu>
 <84be9c0e00df4e1698ab70a32dd77055@XCH-ALN-014.cisco.com>,
 <910665b3e62c455babf3469690dc7e92@baseworx.net>
 <D7B8992A-B4EC-4EBF-8332-A0F87D9B8FE3@cisco.com>
 <08d0aa25565c44679307ca50a074e38b@baseworx.net>
Message-ID: <02da01d18388$481bfe00$d853fa00$@gmail.com>

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tim McKee

>The factor of 6 was just in reduction of overhead.  Granted in the greater
scheme of things the overall 4% is relatively insignificant, but there have
been many times when doing >multiple 10-100+GB transfers that I would have
welcomed a 4% reduction of time spent twiddling thumbs!


The 4% increase in available bandwidth is only part of the equation though.
I would think that having to encap/decap 1/6 the number of packets(frames)
from host to host and all routers/switches along the way would be
beneficial, especially since some of these could be processing these in
software.  Certainly if there are FW or IPS involved.  I'm not sure about
the host side of things, but I'm guessing there would be efficiency
increases there as well.

Chuck


From Curtis.Starnes at granburyisd.org  Mon Mar 21 15:53:51 2016
From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS)
Date: Mon, 21 Mar 2016 15:53:51 +0000
Subject: DataCenter color-coding cabling schema
In-Reply-To: <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
Message-ID: <CO2PR0801MB677EA3FB1DE213D8BC3E10C9E8F0@CO2PR0801MB677.namprd08.prod.outlook.com>

Just to throw it out there but I always try not to use RED cable.
Normally, RED wire in any building is dedicated as FIRE system cabling.


Curtis Starnes
Senior Network Administrator
Granbury ISD
600 W. Bridge St. Ste. 40
Granbury, Texas? 76048
(817) 408-4104
(817) 408-4126 Fax
curtis.starnes at granburyisd.org
www.granburyisd.org 
?
?

OPEN RECORDS NOTICE: This email and responses may be subject to Texas Open Records laws and may be disclosed to the public upon request. 



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong
Sent: Sunday, March 13, 2016 7:10 PM
To: Yardiel Fuentes <yardiel at gmail.com>
Cc: nanog at nanog.org
Subject: Re: DataCenter color-coding cabling schema

I don?t know of any universal standards, but I?ve used the following in several installatins I was responsible for to good avail:

Twisted Pair:

RED:	Untrusted Network (Internet or possibly DMZ)
YELLOW:	Optional for DMZ networks though I preferred to avoid documented in [1] below
BLUE:	Trusted Network (back-end, internal, etc.)
GREEN:	RS-232 straight-thru
PURPLE:	RS-232 X-Over (effectively Null Modem) 12345678 <-> 87654321 pin map.
ORANGE:	Ethernet X-Over (Best avoided documented in [2] below)
GREY:	Special purpose cabling not in one of the above categories

Fiber:
Orange ? Multimode Fiber
Yellow ? Singlemode Fiber

The absolute most useful thing you can do if you can impose the discipline to update the cable map rigorously and/or allocate manpower for periodic audits is to apply a unique serial number to each cable. I preferred to document not only the cable ID, but also the length. For the installations where I have worked, 5 digits was sufficient unique ID, so I used formats like IIIII-L[.L] where IIIII was a unique ID and L.L was the length of the cable in feet. (e.g. 00123-6.5 is cable number 123 which is 6.5 feet in length).

The labels are (ideally) the self-laminating wrap-around types. I prefer the Brady labeling system which will automatically print 2-4 (depending on font size) instances of the label text on the self-laminating label such that it can be read from virtually any side of the cable without requiring you to rotate the label into view in most cases.

The Brady labeling system is a bit overpriced compared to the Brother P-Touch, but the expanded capabilities and the quality of the label adhesives and such is, IMHO, sufficiently superior to justify the cost.

Whatever you do, please do not use Flag labels on cables? I HATE THEM. They are a constant source of entanglement and snags. They often get knocked off as a result or mangled beyond recognition, rendering them useless.

Similarly, I?ve found that circuit-ID and end-point labels on cables are often ill-maintained, so if you do use them, please make sure you remove them when the cable is moved/removed.

The length is very useful because it gives you a radius within which the other end of the cable must be located and you can usually expect it to be reasonably close to the outer edge of that radius.

More than a few times I?ve prevented a serious outage by giving the port number to the remote hands guy and then insisting that he read me the cable ID. ?No, try the other port FE-0/2/4? You?re off by one. It?s above/left/right/below you.?

[1] I prefer to avoid Yellow cables because some people have trouble understanding that Yellow Fiber and Yellow UTP might have different meanings. I also feel that the distinction between UNTRUSTED and DMZ networks is usually not all that important in most cabling situations. YMMV.

[2] In this era of Auto-MDI/MDI-X ports and the like, it?s very rare to encounter a situation that truly requires a crossover cable with no viable alternative. If such is needed, I prefer to document it on the cable tags rather than using a special color code. Again, you have the risk of people not understanding that orange Fiber might not mean what Orange copper means. YMMV

Yes, I know you can now get virtually any type of fiber in virtually any color, but the simple fact of the matter remains that when you send skippy out to buy emergency jumpers or such, you?re most likely going to either get orange multimode or yellow singlemode and that?s just the way it is.

Owen

> On Mar 12, 2016, at 11:11 , Yardiel Fuentes <yardiel at gmail.com> wrote:
> 
> Hello Nanog-ers,
> 
> Have any of you had the option or; conversely, do you know of ?best 
> practices" or ?common standards?,  to color code physical cabling for 
> your connections in DataCenters for Base-T and FX connections? If so, 
> Could you share  any ttype of color-coding schema you are aware of ??. 
> Yes, this is actually considering paying for customized color-coded 
> cabling in a Data Center...
> 
> Mr. Google did not really provide me with relevant answers on the 
> above? beyond the typical (Orange is for MMF, yellow for SMF, etc)?
> 
> Any reasons for or against it welcome too...
> 
> --
> Yardiel Fuentes


From jchisolm at computer.org  Mon Mar 21 16:26:41 2016
From: jchisolm at computer.org (Joe Chisolm)
Date: Mon, 21 Mar 2016 11:26:41 -0500
Subject: Charter DDOS scrubbing.
In-Reply-To: <56EC664F.6070202@globalvision.net>
References: <56EC664F.6070202@globalvision.net>
Message-ID: <56F020C1.3000003@computer.org>

One option is to do it yourself.  Contact some of the ddos vendors.  I know RioRey ( www.riorey.com ) has mb, gb and 10g+ products and a scrubbing center.

On 03/18/2016 03:34 PM, Ethan E. Dee wrote:
> Globalvision is an ISP in greenville sc.
> We are currently peering with two other ISP's we have a gig link with charter and are getting hammered quite hard with a full gig and more of DDoS on SIP, DNS, NTP, and other random UDP traffic. Alot of folks have said that charter will do DDoS scrubbing. Charter however is telling me they 
> absolutely cannot offer this service.
> Does anyone have any info on contacting charter or who to bug about this to get it in the works? Or does any know for certain that there's no reason to even ask?
>
-- 
Joe Chisolm
Computer Translations, Inc.
Marble Falls, Tx.


From chuckchurch at gmail.com  Mon Mar 21 17:06:35 2016
From: chuckchurch at gmail.com (Chuck Church)
Date: Mon, 21 Mar 2016 13:06:35 -0400
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <56EEDC3D.4010804@tiedyenetworks.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
Message-ID: <033701d18394$07e01720$17a04560$@gmail.com>

Uggghhh.  I've always hated this 'reboot, see if it fixes it' methodology.  If the CPEs can't recover from error conditions correctly, they shouldn't be used.  I blame Microsoft for making this concept acceptable.  LOL.

Chuck

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike
Sent: Sunday, March 20, 2016 1:22 PM
To: nanog at nanog.org
Subject: Re: Oh dear, we've all been made redundant...


This is great, I now have something I can show to my customers to confirm that all this power cycling and such really is an 'accepted problem'...

On 03/19/2016 04:16 PM, Warren Kumari wrote:
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-
> Routers/product_1985686
>
> Fixes all issues, less downtime, less stress...
> Improves performance, eliminates buffering...
> It slices, it dices in teeny, tiny slices.
> It makes mounds of julienne fries in just seconds.
> ...
>
> Description - copied here for convenience:
>
> All the issues associated with the Internet being down can be solved 
> by power cycling the modem and router. But that can be hard to do! 
> NetReset resolves network issues by offering sequential power cycling. 
> This means that when the modem and router are plugged into the device, 
> they are powered up at different times. The modem is powered up first, 
> then a minute later, the router is powered up. This rebooting will 
> occur at initial setup, every 24 hours and after a power failure. Do 
> you have a modem/router combo? No problem! NetReset will also power cycle the modem/router combo.
>
>
> Automatically resets user's Internet every 24 hours Maximizes Internet 
> speed & reliability Eliminates media stream buffering Hands-free 
> Internet reset Resets hard-to-reach modem/router Less Internet 
> downtime Less daily stress No need to manually reset Reset occurs at 
> programmed time Updated information from Internet service provider 
> Proper reboot after a power failure Resetting allows equipment to 
> auto-correct issues
>
>


From math at sizone.org  Mon Mar 21 17:31:41 2016
From: math at sizone.org (Ken Chase)
Date: Mon, 21 Mar 2016 13:31:41 -0400
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <033701d18394$07e01720$17a04560$@gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
 <033701d18394$07e01720$17a04560$@gmail.com>
Message-ID: <20160321173141.GI7202@sizone.org>

"how many times did he reboot it?" "once."  "well, i think he needs to try a
few more times."

The Website Is Down: https://www.youtube.com/watch?v=uRGljemfwUE#t=6m30s

(old but good.)

/kc


On Mon, Mar 21, 2016 at 01:06:35PM -0400, Chuck Church said:
  >Uggghhh.  I've always hated this 'reboot, see if it fixes it' methodology.  If the CPEs can't recover from error conditions correctly, they shouldn't be used.  I blame Microsoft for making this concept acceptable.  LOL.
  >
  >Chuck
  >
  >-----Original Message-----
  >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike
  >Sent: Sunday, March 20, 2016 1:22 PM
  >To: nanog at nanog.org
  >Subject: Re: Oh dear, we've all been made redundant...
  >
  >
  >This is great, I now have something I can show to my customers to confirm that all this power cycling and such really is an 'accepted problem'...
  >
  >On 03/19/2016 04:16 PM, Warren Kumari wrote:
  >> Found on Staple's website:
  >> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-
  >> Routers/product_1985686
  >>
  >> Fixes all issues, less downtime, less stress...
  >> Improves performance, eliminates buffering...
  >> It slices, it dices in teeny, tiny slices.
  >> It makes mounds of julienne fries in just seconds.
  >> ...
  >>
  >> Description - copied here for convenience:
  >>
  >> All the issues associated with the Internet being down can be solved 
  >> by power cycling the modem and router. But that can be hard to do! 
  >> NetReset resolves network issues by offering sequential power cycling. 
  >> This means that when the modem and router are plugged into the device, 
  >> they are powered up at different times. The modem is powered up first, 
  >> then a minute later, the router is powered up. This rebooting will 
  >> occur at initial setup, every 24 hours and after a power failure. Do 
  >> you have a modem/router combo? No problem! NetReset will also power cycle the modem/router combo.
  >>
  >>
  >> Automatically resets user's Internet every 24 hours Maximizes Internet 
  >> speed & reliability Eliminates media stream buffering Hands-free 
  >> Internet reset Resets hard-to-reach modem/router Less Internet 
  >> downtime Less daily stress No need to manually reset Reset occurs at 
  >> programmed time Updated information from Internet service provider 
  >> Proper reboot after a power failure Resetting allows equipment to 
  >> auto-correct issues
  >>
  >>
  >

--
Ken Chase - math at sizone.org

From baconzombie at gmail.com  Mon Mar 21 19:30:18 2016
From: baconzombie at gmail.com (Bacon Zombie)
Date: Mon, 21 Mar 2016 20:30:18 +0100
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <20160321173141.GI7202@sizone.org>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
 <033701d18394$07e01720$17a04560$@gmail.com>
 <20160321173141.GI7202@sizone.org>
Message-ID: <CAPz7E52KoQiyNmoA7zJcLsLU3u=UYDhhA6xrFz1ytmTep2DzMw@mail.gmail.com>

Every time I have to ring about my home internet the first think they ask
be to do is reboot the modem and then connect via cable and check the link
light is green.

Had to fight with them before since the  *FRITZ!**Box* they supplied did
not have network link LEDs. Also I know it was a PPPoE auth  issue looking
at the pcap from the router.

Still did not stop them from insisting it was a modem issues and sent me
out 3 replacements.
On 21 Mar 2016 18:33, "Ken Chase" <math at sizone.org> wrote:

> "how many times did he reboot it?" "once."  "well, i think he needs to try
> a
> few more times."
>
> The Website Is Down: https://www.youtube.com/watch?v=uRGljemfwUE#t=6m30s
>
> (old but good.)
>
> /kc
>
>
> On Mon, Mar 21, 2016 at 01:06:35PM -0400, Chuck Church said:
>   >Uggghhh.  I've always hated this 'reboot, see if it fixes it'
> methodology.  If the CPEs can't recover from error conditions correctly,
> they shouldn't be used.  I blame Microsoft for making this concept
> acceptable.  LOL.
>   >
>   >Chuck
>   >
>   >-----Original Message-----
>   >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike
>   >Sent: Sunday, March 20, 2016 1:22 PM
>   >To: nanog at nanog.org
>   >Subject: Re: Oh dear, we've all been made redundant...
>   >
>   >
>   >This is great, I now have something I can show to my customers to
> confirm that all this power cycling and such really is an 'accepted
> problem'...
>   >
>   >On 03/19/2016 04:16 PM, Warren Kumari wrote:
>   >> Found on Staple's website:
>   >>
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-
>   >> Routers/product_1985686
>   >>
>   >> Fixes all issues, less downtime, less stress...
>   >> Improves performance, eliminates buffering...
>   >> It slices, it dices in teeny, tiny slices.
>   >> It makes mounds of julienne fries in just seconds.
>   >> ...
>   >>
>   >> Description - copied here for convenience:
>   >>
>   >> All the issues associated with the Internet being down can be solved
>   >> by power cycling the modem and router. But that can be hard to do!
>   >> NetReset resolves network issues by offering sequential power cycling.
>   >> This means that when the modem and router are plugged into the device,
>   >> they are powered up at different times. The modem is powered up first,
>   >> then a minute later, the router is powered up. This rebooting will
>   >> occur at initial setup, every 24 hours and after a power failure. Do
>   >> you have a modem/router combo? No problem! NetReset will also power
> cycle the modem/router combo.
>   >>
>   >>
>   >> Automatically resets user's Internet every 24 hours Maximizes Internet
>   >> speed & reliability Eliminates media stream buffering Hands-free
>   >> Internet reset Resets hard-to-reach modem/router Less Internet
>   >> downtime Less daily stress No need to manually reset Reset occurs at
>   >> programmed time Updated information from Internet service provider
>   >> Proper reboot after a power failure Resetting allows equipment to
>   >> auto-correct issues
>   >>
>   >>
>   >
>
> --
> Ken Chase - math at sizone.org
>

From aaron at heyaaron.com  Mon Mar 21 19:44:41 2016
From: aaron at heyaaron.com (Aaron C. de Bruyn)
Date: Mon, 21 Mar 2016 12:44:41 -0700
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CO2PR0801MB677EA3FB1DE213D8BC3E10C9E8F0@CO2PR0801MB677.namprd08.prod.outlook.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CO2PR0801MB677EA3FB1DE213D8BC3E10C9E8F0@CO2PR0801MB677.namprd08.prod.outlook.com>
Message-ID: <CAEE+rGqqtCB0FbCUJcWyF4piRiQhd+wxCOqhXS+uNuz8Pvf_ag@mail.gmail.com>

That's a good reason to use it.  Who would cut it?  ;)

-A

On Mon, Mar 21, 2016 at 8:53 AM, STARNES, CURTIS <
Curtis.Starnes at granburyisd.org> wrote:

> Just to throw it out there but I always try not to use RED cable.
> Normally, RED wire in any building is dedicated as FIRE system cabling.
>
>
> Curtis Starnes
> Senior Network Administrator
> Granbury ISD
> 600 W. Bridge St. Ste. 40
> Granbury, Texas  76048
> (817) 408-4104
> (817) 408-4126 Fax
> curtis.starnes at granburyisd.org
> www.granburyisd.org
>
>
>
> OPEN RECORDS NOTICE: This email and responses may be subject to Texas Open
> Records laws and may be disclosed to the public upon request.
>
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong
> Sent: Sunday, March 13, 2016 7:10 PM
> To: Yardiel Fuentes <yardiel at gmail.com>
> Cc: nanog at nanog.org
> Subject: Re: DataCenter color-coding cabling schema
>
> I don?t know of any universal standards, but I?ve used the following in
> several installatins I was responsible for to good avail:
>
> Twisted Pair:
>
> RED:    Untrusted Network (Internet or possibly DMZ)
> YELLOW: Optional for DMZ networks though I preferred to avoid documented
> in [1] below
> BLUE:   Trusted Network (back-end, internal, etc.)
> GREEN:  RS-232 straight-thru
> PURPLE: RS-232 X-Over (effectively Null Modem) 12345678 <-> 87654321 pin
> map.
> ORANGE: Ethernet X-Over (Best avoided documented in [2] below)
> GREY:   Special purpose cabling not in one of the above categories
>
> Fiber:
> Orange ? Multimode Fiber
> Yellow ? Singlemode Fiber
>
> The absolute most useful thing you can do if you can impose the discipline
> to update the cable map rigorously and/or allocate manpower for periodic
> audits is to apply a unique serial number to each cable. I preferred to
> document not only the cable ID, but also the length. For the installations
> where I have worked, 5 digits was sufficient unique ID, so I used formats
> like IIIII-L[.L] where IIIII was a unique ID and L.L was the length of the
> cable in feet. (e.g. 00123-6.5 is cable number 123 which is 6.5 feet in
> length).
>
> The labels are (ideally) the self-laminating wrap-around types. I prefer
> the Brady labeling system which will automatically print 2-4 (depending on
> font size) instances of the label text on the self-laminating label such
> that it can be read from virtually any side of the cable without requiring
> you to rotate the label into view in most cases.
>
> The Brady labeling system is a bit overpriced compared to the Brother
> P-Touch, but the expanded capabilities and the quality of the label
> adhesives and such is, IMHO, sufficiently superior to justify the cost.
>
> Whatever you do, please do not use Flag labels on cables? I HATE THEM.
> They are a constant source of entanglement and snags. They often get
> knocked off as a result or mangled beyond recognition, rendering them
> useless.
>
> Similarly, I?ve found that circuit-ID and end-point labels on cables are
> often ill-maintained, so if you do use them, please make sure you remove
> them when the cable is moved/removed.
>
> The length is very useful because it gives you a radius within which the
> other end of the cable must be located and you can usually expect it to be
> reasonably close to the outer edge of that radius.
>
> More than a few times I?ve prevented a serious outage by giving the port
> number to the remote hands guy and then insisting that he read me the cable
> ID. ?No, try the other port FE-0/2/4? You?re off by one. It?s
> above/left/right/below you.?
>
> [1] I prefer to avoid Yellow cables because some people have trouble
> understanding that Yellow Fiber and Yellow UTP might have different
> meanings. I also feel that the distinction between UNTRUSTED and DMZ
> networks is usually not all that important in most cabling situations. YMMV.
>
> [2] In this era of Auto-MDI/MDI-X ports and the like, it?s very rare to
> encounter a situation that truly requires a crossover cable with no viable
> alternative. If such is needed, I prefer to document it on the cable tags
> rather than using a special color code. Again, you have the risk of people
> not understanding that orange Fiber might not mean what Orange copper
> means. YMMV
>
> Yes, I know you can now get virtually any type of fiber in virtually any
> color, but the simple fact of the matter remains that when you send skippy
> out to buy emergency jumpers or such, you?re most likely going to either
> get orange multimode or yellow singlemode and that?s just the way it is.
>
> Owen
>
> > On Mar 12, 2016, at 11:11 , Yardiel Fuentes <yardiel at gmail.com> wrote:
> >
> > Hello Nanog-ers,
> >
> > Have any of you had the option or; conversely, do you know of ?best
> > practices" or ?common standards?,  to color code physical cabling for
> > your connections in DataCenters for Base-T and FX connections? If so,
> > Could you share  any ttype of color-coding schema you are aware of ??.
> > Yes, this is actually considering paying for customized color-coded
> > cabling in a Data Center...
> >
> > Mr. Google did not really provide me with relevant answers on the
> > above? beyond the typical (Orange is for MMF, yellow for SMF, etc)?
> >
> > Any reasons for or against it welcome too...
> >
> > --
> > Yardiel Fuentes
>
>

From Curtis.Starnes at granburyisd.org  Mon Mar 21 19:51:49 2016
From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS)
Date: Mon, 21 Mar 2016 19:51:49 +0000
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CAEE+rGqqtCB0FbCUJcWyF4piRiQhd+wxCOqhXS+uNuz8Pvf_ag@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
 <4C670D46-B1E4-44E4-A11A-BA2CF94A8754@delong.com>
 <CO2PR0801MB677EA3FB1DE213D8BC3E10C9E8F0@CO2PR0801MB677.namprd08.prod.outlook.com>
 <CAEE+rGqqtCB0FbCUJcWyF4piRiQhd+wxCOqhXS+uNuz8Pvf_ag@mail.gmail.com>
Message-ID: <CO2PR0801MB677D968A3399908561297AB9E8F0@CO2PR0801MB677.namprd08.prod.outlook.com>

Good point, never looked at it that way, but I have had techs before that would cut anything they thought was data and sometimes even when they knew it was not.
I guess it was Beer:30 time to them :-\

Curtis

From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com]
Sent: Monday, March 21, 2016 2:45 PM
To: STARNES, CURTIS <Curtis.Starnes at granburyisd.org>
Cc: Owen DeLong <owen at delong.com>; Yardiel Fuentes <yardiel at gmail.com>; nanog at nanog.org
Subject: Re: DataCenter color-coding cabling schema

That's a good reason to use it.  Who would cut it?  ;)

-A

On Mon, Mar 21, 2016 at 8:53 AM, STARNES, CURTIS <Curtis.Starnes at granburyisd.org<mailto:Curtis.Starnes at granburyisd.org>> wrote:
Just to throw it out there but I always try not to use RED cable.
Normally, RED wire in any building is dedicated as FIRE system cabling.


Curtis Starnes
Senior Network Administrator
Granbury ISD
600 W. Bridge St. Ste. 40
Granbury, Texas  76048
(817) 408-4104<tel:%28817%29%20408-4104>
(817) 408-4126<tel:%28817%29%20408-4126> Fax
curtis.starnes at granburyisd.org<mailto:curtis.starnes at granburyisd.org>
www.granburyisd.org<http://www.granburyisd.org>



OPEN RECORDS NOTICE: This email and responses may be subject to Texas Open Records laws and may be disclosed to the public upon request.



-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org<mailto:nanog-bounces at nanog.org>] On Behalf Of Owen DeLong
Sent: Sunday, March 13, 2016 7:10 PM
To: Yardiel Fuentes <yardiel at gmail.com<mailto:yardiel at gmail.com>>
Cc: nanog at nanog.org<mailto:nanog at nanog.org>
Subject: Re: DataCenter color-coding cabling schema

I don?t know of any universal standards, but I?ve used the following in several installatins I was responsible for to good avail:

Twisted Pair:

RED:    Untrusted Network (Internet or possibly DMZ)
YELLOW: Optional for DMZ networks though I preferred to avoid documented in [1] below
BLUE:   Trusted Network (back-end, internal, etc.)
GREEN:  RS-232 straight-thru
PURPLE: RS-232 X-Over (effectively Null Modem) 12345678 <-> 87654321 pin map.
ORANGE: Ethernet X-Over (Best avoided documented in [2] below)
GREY:   Special purpose cabling not in one of the above categories

Fiber:
Orange ? Multimode Fiber
Yellow ? Singlemode Fiber

The absolute most useful thing you can do if you can impose the discipline to update the cable map rigorously and/or allocate manpower for periodic audits is to apply a unique serial number to each cable. I preferred to document not only the cable ID, but also the length. For the installations where I have worked, 5 digits was sufficient unique ID, so I used formats like IIIII-L[.L] where IIIII was a unique ID and L.L was the length of the cable in feet. (e.g. 00123-6.5 is cable number 123 which is 6.5 feet in length).

The labels are (ideally) the self-laminating wrap-around types. I prefer the Brady labeling system which will automatically print 2-4 (depending on font size) instances of the label text on the self-laminating label such that it can be read from virtually any side of the cable without requiring you to rotate the label into view in most cases.

The Brady labeling system is a bit overpriced compared to the Brother P-Touch, but the expanded capabilities and the quality of the label adhesives and such is, IMHO, sufficiently superior to justify the cost.

Whatever you do, please do not use Flag labels on cables? I HATE THEM. They are a constant source of entanglement and snags. They often get knocked off as a result or mangled beyond recognition, rendering them useless.

Similarly, I?ve found that circuit-ID and end-point labels on cables are often ill-maintained, so if you do use them, please make sure you remove them when the cable is moved/removed.

The length is very useful because it gives you a radius within which the other end of the cable must be located and you can usually expect it to be reasonably close to the outer edge of that radius.

More than a few times I?ve prevented a serious outage by giving the port number to the remote hands guy and then insisting that he read me the cable ID. ?No, try the other port FE-0/2/4? You?re off by one. It?s above/left/right/below you.?

[1] I prefer to avoid Yellow cables because some people have trouble understanding that Yellow Fiber and Yellow UTP might have different meanings. I also feel that the distinction between UNTRUSTED and DMZ networks is usually not all that important in most cabling situations. YMMV.

[2] In this era of Auto-MDI/MDI-X ports and the like, it?s very rare to encounter a situation that truly requires a crossover cable with no viable alternative. If such is needed, I prefer to document it on the cable tags rather than using a special color code. Again, you have the risk of people not understanding that orange Fiber might not mean what Orange copper means. YMMV

Yes, I know you can now get virtually any type of fiber in virtually any color, but the simple fact of the matter remains that when you send skippy out to buy emergency jumpers or such, you?re most likely going to either get orange multimode or yellow singlemode and that?s just the way it is.

Owen

> On Mar 12, 2016, at 11:11 , Yardiel Fuentes <yardiel at gmail.com<mailto:yardiel at gmail.com>> wrote:
>
> Hello Nanog-ers,
>
> Have any of you had the option or; conversely, do you know of ?best
> practices" or ?common standards?,  to color code physical cabling for
> your connections in DataCenters for Base-T and FX connections? If so,
> Could you share  any ttype of color-coding schema you are aware of ??.
> Yes, this is actually considering paying for customized color-coded
> cabling in a Data Center...
>
> Mr. Google did not really provide me with relevant answers on the
> above? beyond the typical (Orange is for MMF, yellow for SMF, etc)?
>
> Any reasons for or against it welcome too...
>
> --
> Yardiel Fuentes


From larrysheldon at cox.net  Mon Mar 21 21:04:29 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Mon, 21 Mar 2016 16:04:29 -0500
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <033701d18394$07e01720$17a04560$@gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
 <033701d18394$07e01720$17a04560$@gmail.com>
Message-ID: <56F061DD.9030903@cox.net>

On 3/21/2016 12:06, Chuck Church wrote:
> Uggghhh.  I've always hated this 'reboot, see if it fixes it'
> methodology.  If the CPEs can't recover from error conditions
> correctly, they shouldn't be used.  I blame Microsoft for making this
> concept acceptable.  LOL.

Any trouble case that does NOT have the word "replaced", "repaired", or 
"patched", followed with a specific, identifiable device name was not 
"closed".  It is still an open, unsolved case.



-- 
sed quis custodiet ipsos custodes? (Juvenal)

From jra at baylink.com  Tue Mar 22 15:36:49 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 22 Mar 2016 15:36:49 +0000 (UTC)
Subject: DataCenter color-coding cabling schema
In-Reply-To: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
References: <CABtQX6EGR03VG9CQ+Bc6n3QXzQD28GLPh4diD6oxyZrdZ0vhiw@mail.gmail.com>
Message-ID: <439255618.6582.1458661009736.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Yardiel Fuentes" <yardiel at gmail.com>

> Have any of you had the option or; conversely, do you know of ?best
> practices" or ?common standards?,  to color code physical cabling for your
> connections in DataCenters for Base-T and FX connections? If so, Could you
> share  any ttype of color-coding schema you are aware of ??. Yes, this is
> actually considering paying for customized color-coded cabling in a Data
> Center...

EIA/TIA 568/598 talk to fiber color coding.  They have one for copper too,
but I can't find it either, off hand.

google://cable+jacket+color+standards is a pretty good search for this

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 jra at baylink.com  Tue Mar 22 15:44:13 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 22 Mar 2016 15:44:13 +0000 (UTC)
Subject: Why the US Government has so many data centers
In-Reply-To: <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
Message-ID: <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "Lee" <ler762 at gmail.com>

> On 3/13/16, Sean Donelan wrote:

> I doubt anyone really believes that having a server in the room makes
> it a data center.  But if you're the Federal CIO pushing the cloud
> first policy, this seems like a great bureaucratic maneuver to get the
> decision making away from the techies that like redundant servers in
> multiple locations, their managers who's job rating depends on
> providing reliable services and even the agency CIOs.  Check the
> reporting section of the memo where it says "each agency head shall
> annually publish a Data Center Consolidation and Optimization
> Strategic Plan".   I dunno, but I'm guessing agency heads are
> political appointees that aren't going to spend much, if any, time
> listening to techies whine about how important their servers are & why
> they can't be consolidated, virtualized or outsourced.

Fine.

But when some Armenian script kiddie DDoSing Netflix takes down your TSA
terrorist lookup service, and you come to me asking why the plane blew up,
I'm going to tell you "because you fucking ignored my written advice on 
the matter", while I'm packing my desk.

In writing.

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 sean at donelan.com  Tue Mar 22 16:11:11 2016
From: sean at donelan.com (Sean Donelan)
Date: Tue, 22 Mar 2016 12:11:11 -0400 (EDT)
Subject: Why the US Government has so many data centers
In-Reply-To: <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>
Message-ID: <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>

On Tue, 22 Mar 2016, Jay R. Ashworth wrote:
> But when some Armenian script kiddie DDoSing Netflix takes down your TSA
> terrorist lookup service, and you come to me asking why the plane blew up,
> I'm going to tell you "because you fucking ignored my written advice on
> the matter", while I'm packing my desk.

DOCI is about physical data center opimization, not about network or
service availability.

DCOI metrics:
- Energy metering
- Power Usage Effectiveness (PUE)
- Virtualization
- Server Utilization & Automated Monitoring
- Facility Utilization

Why do you have two circuits with only 40% utilization. The auditor says
that's waste, and you only need one circuit at 80% utilization for half
the cost.



From littlefishguy at gmail.com  Tue Mar 22 17:33:31 2016
From: littlefishguy at gmail.com (Scott Fisher)
Date: Tue, 22 Mar 2016 13:33:31 -0400
Subject: Citrix Sales Reps?
Message-ID: <CAHddgMxr1Y3C4eoj8bKvY0kxP_fDz6395sfe6OxyryFO5fJnfg@mail.gmail.com>

I have sent 4 requests to Citrix for pricing questions on XenServer support
options and have gotten not a single call back. (Requested via email, form,
and calls).

Can someone from Citrix please hit me up offlist or can someone direct me
to an actual person I can hit up?

-- 
Scott

From Valdis.Kletnieks at vt.edu  Tue Mar 22 17:59:50 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 22 Mar 2016 13:59:50 -0400
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>
 <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>
Message-ID: <3452.1458669590@turing-police.cc.vt.edu>

On Tue, 22 Mar 2016 12:11:11 -0400, Sean Donelan said:
> Why do you have two circuits with only 40% utilization. The auditor says
> that's waste, and you only need one circuit at 80% utilization for half
> the cost.

And of course, said auditor is probably near impervious to the very real
and valid reasons you have 2 circuits.  Because as Upton Sinclair wrote
around a century ago:

"You cannot make a man understand something when his paycheck depends
on him not understanding it".
-------------- 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/20160322/1f50ebf9/attachment.pgp>

From jason.leblanc at infusionsoft.com  Tue Mar 22 18:15:23 2016
From: jason.leblanc at infusionsoft.com (Jason LeBlanc)
Date: Tue, 22 Mar 2016 18:15:23 +0000
Subject: mrtg alternative
In-Reply-To: <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
Message-ID: <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>

+1 on Observium.  

I know I am late replying but I just installed it a couple weeks ago.  It integrates with Smokeping, Rancid, CollectD, Syslo... Took me 1 day to setup on CentOS.  Fantastic product so far!


//LeBlanc

>We?re using Observium for trend collecting, graphing, and alerting.
>
>-Pete
>

From george.herbert at gmail.com  Tue Mar 22 18:15:29 2016
From: george.herbert at gmail.com (George Herbert)
Date: Tue, 22 Mar 2016 11:15:29 -0700
Subject: Why the US Government has so many data centers
In-Reply-To: <3452.1458669590@turing-police.cc.vt.edu>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>
 <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>
 <3452.1458669590@turing-police.cc.vt.edu>
Message-ID: <C3F1803C-01D7-49DD-9AB2-D7C9A1A14A0C@gmail.com>

Come on, the audit requirements should have diversity/redundancy concerns in them.

That's standard in all the audits I have done or participated in.

If these ones don't I have a marketing opportunity to teach a HA seminar and followon consulting to the IG.

George William Herbert
Sent from my iPhone

> On Mar 22, 2016, at 10:59 AM, Valdis.Kletnieks at vt.edu wrote:
> 
> On Tue, 22 Mar 2016 12:11:11 -0400, Sean Donelan said:
>> Why do you have two circuits with only 40% utilization. The auditor says
>> that's waste, and you only need one circuit at 80% utilization for half
>> the cost.
> 
> And of course, said auditor is probably near impervious to the very real
> and valid reasons you have 2 circuits.  Because as Upton Sinclair wrote
> around a century ago:
> 
> "You cannot make a man understand something when his paycheck depends
> on him not understanding it".

From sean at donelan.com  Tue Mar 22 18:36:58 2016
From: sean at donelan.com (Sean Donelan)
Date: Tue, 22 Mar 2016 14:36:58 -0400 (EDT)
Subject: Why the US Government has so many data centers
In-Reply-To: <C3F1803C-01D7-49DD-9AB2-D7C9A1A14A0C@gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>
 <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>
 <3452.1458669590@turing-police.cc.vt.edu>
 <C3F1803C-01D7-49DD-9AB2-D7C9A1A14A0C@gmail.com>
Message-ID: <alpine.BSF.2.20.1603221427060.42683@cnex.qbaryna.pbz>

On Tue, 22 Mar 2016, George Herbert wrote:
> Come on, the audit requirements should have diversity/redundancy concerns in them.
>
> That's standard in all the audits I have done or participated in.
>
> If these ones don't I have a marketing opportunity to teach a HA seminar and followon consulting to the IG.

Turn on C-SPAN and watch any random congressional oversight hearing.

Reasonable, rational or logical thoughts are rare. You may be making 
assumptions that aren't supported.  Just ask Flint Michigan about saving
money on cheaper water supplies.


From jra at baylink.com  Tue Mar 22 19:42:36 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 22 Mar 2016 19:42:36 +0000 (UTC)
Subject: So Cal Verizon Business FIOS to Frontier cutover
In-Reply-To: <DM3PR0601MB202534EF8F11F32D8456C829E48C0@DM3PR0601MB2025.namprd06.prod.outlook.com>
References: <027a01d17fe3$af9fe350$0edfa9f0$@acm.org>
 <DM3PR0601MB202534EF8F11F32D8456C829E48C0@DM3PR0601MB2025.namprd06.prod.outlook.com>
Message-ID: <255164655.7633.1458675756929.JavaMail.zimbra@baylink.com>

The cost of a support call is $30-70; this does not scale well.

The *actual* problem here is that your website does not answer
the actual questions that actual users have; that's the thing
someone needs to fix, before the $70 phone calls start coming in.

Cheers,
-- jra

----- Original Message -----
> From: "Azinger, Marla" <Marla.Azinger at FTR.com>
> To: "Paul B. Henson" <henson at acm.org>, nanog at nanog.org
> Sent: Friday, March 18, 2016 12:24:45 PM
> Subject: RE: So Cal Verizon Business FIOS to Frontier cutover

> Hi Paul
> 
> I will email you privately to address your concerns.
> 
> Regards
> Marla Azinger
> Supervisor Network ENG
> IP Address Management
> 
> 
> 
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul B. Henson
> Sent: Wednesday, March 16, 2016 5:27 PM
> To: nanog at nanog.org
> Subject: So Cal Verizon Business FIOS to Frontier cutover
> 
> So the transition from Verizon to Frontier is coming up, and I recently got a
> notice from Verizon pointing me to the following website:
> 
> http://meetfrontier.com/
> 
> Evidently one of the things Verizon did not sell to Frontier is their IP address
> space, as it seems customers with static IP addresses are going to have to
> change their allocations :(. I have five statics, and while it is not the end
> of the world, it will certainly be annoying to have to reconfigure not only my
> equipment but also update the configurations of my clients that access it and
> the other service providers I access who restrict based on it <sigh>. I was
> hoping to get some simple additional information regarding this migration, such
> as:
> 
> * How far in advance of the cutover will we be notified?
> * How far in advance of the cutover will we be supplied with the new static IP
> addresses?
> * How big will the cutover window be, and will it be attended or unattended?
> * How will reverse DNS resolution be handled?
> 
> So I called the phone number on the website that was provided for questions or
> additional information. I'm not quite sure why they provided it, as the person
> who answered it had absolutely no information to provide other than that that
> was already on the website, and said they were unable to direct me to anyone
> who could provide any further information; I guess it was for people who needed
> the website read to them?
> 
> Any chance there is a Frontier engineer on the list who might be able to provide
> this information, anonymously if necessary :)? Or someone who has gone through
> a Verizon to Frontier FIOS static IP address transition in another location who
> might describe their experience with the assumption it will be similar in
> California?
> 
> As far as reverse DNS, the only thing I can seem to find is this:
> 
> http://hostmaster.frontier.com/reverse.html
> 
> Which talks about "Business Class DSL and Dedicated Internet" customers, not
> sure if it applies to FIOS? What I'd really like is to get my PTR entries
> delegated to me via CNAMEs so I could control the TTLs and update them whenever
> I wanted to without having to hassle the provider (one of my colleagues has
> this arrangement with charter business cable), Verizon was never willing to do
> that.
> 
> On another note, does anybody have any idea regarding Frontier's position on
> rolling out IPv6 for business FIOS :)? Hopefully they won't be quite as archaic
> and stuck in the mud as Verizon has been on that topic :(.
> 
> Thanks much for any info.
> 
> 
> 
> ________________________________
> 
> This communication is confidential. Frontier only sends and receives email on
> the basis of the terms set out at http://www.frontier.com/email_disclaimer.

-- 
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 jra at baylink.com  Tue Mar 22 19:59:24 2016
From: jra at baylink.com (Jay R. Ashworth)
Date: Tue, 22 Mar 2016 19:59:24 +0000 (UTC)
Subject: Top-shelf resilience (Re: Why the US Government has so many data
 centers)
In-Reply-To: <C56B4D6A-F03B-42CE-9EF9-54563547CB44@gmail.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
 <3B1CC2C8-560A-4D02-8AED-3CE8180EC7FA@n5tech.com>
 <C56B4D6A-F03B-42CE-9EF9-54563547CB44@gmail.com>
Message-ID: <379019868.7687.1458676764070.JavaMail.zimbra@baylink.com>

----- Original Message -----
> From: "George Herbert" <george.herbert at gmail.com>

> There are corner cases where distributed resilience is paramount, including a
> lot of field operations (of all sorts) on ships (and aircraft and spacecraft),
> or places where the net really is unstable.  Any generalizations that wrap
> those legitimate exceptions in are overreaching their valid descriptive range.

This seems like a good time to mention my favorite example of such a thing.

In the Navy, originally, and it ended up in a few other places, there was
invented the concept of a 'battleshort', or 'battleshunt', depending on whom 
you're talking to.

This was something akin to a Big Frankenstein Knife Switch across the main
circuit breaker in a power panel (and maybe a couple branch circuit breakers),
whose job was to make sure those didn't trip on you at an inconvenient time.

Like when you were trying to lay a gun on a Bad Guy.

The engineering decision that was made there was that the minor possiblity of 
a circuit overheating and starting something on fire was less important that
*the ability to shoot at the bad guys*...

Or, in my favorite example, something going wrong when launching Apollo rockets.

If you examine the Firing Room recorder transcripts from the manned Apollo
launches, you will find, somewhere in the terminal count, an instruction to
"engage the battle short", or something like that.

Men were, I have been told, stationed at strategic locations with extinguishers,
in case something which would normally have tripped a breaker was forbidden from
doing so by the shunt...

so that the power wouldn't go out at T-4 seconds.

It's referenced in this article:

  http://www.honeysucklecreek.net/station/ops_areas.html

and a number of other places google will find you.

Unknown whether this protocol was still followed in the Shuttle era, or whether
it will return in the New Manned Space Flight era.

But, like the four star saluting the Medal Of Honor recipient, it's one of
those outliers that's *so far* out, that I love and collect them.

And it's a good category of idea to have in the back of your head when planning.

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 surfer at mauigateway.com  Tue Mar 22 20:26:50 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Tue, 22 Mar 2016 13:26:50 -0700
Subject: Why the US Government has so many data centers
Message-ID: <20160322132650.86BF59A2@m0086238.ppops.net>




I finally looked at the Data Center Optimization 
Initiative (DCOI) at https://datacenters.cio.gov.  

If you're planning to provide feedback I would just 
about assure you that this will not be looked at by 
anyone that will be able to do anything.  Likely,
there'll be containers for expected/wanted responses 
and the rest will goto the bit bucket.  It's a 
pressure release valve.  (Let `em get it off their 
chests and then we'll do what we normally do: create 
confusion and chaos, so no one notices what's actually 
being done)  

The politics of gov't folks will over run everything 
reasonable put forth by non-gov't folks like a 
stampede of bison.

scott

From george.herbert at gmail.com  Tue Mar 22 20:43:52 2016
From: george.herbert at gmail.com (George Herbert)
Date: Tue, 22 Mar 2016 13:43:52 -0700
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603221427060.42683@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>
 <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>
 <3452.1458669590@turing-police.cc.vt.edu>
 <C3F1803C-01D7-49DD-9AB2-D7C9A1A14A0C@gmail.com>
 <alpine.BSF.2.20.1603221427060.42683@cnex.qbaryna.pbz>
Message-ID: <19DD0DE8-35C7-4241-9893-BCB6BF434BAD@gmail.com>


The last time I checked, the US CIO office was understaffed and fighting the bureaucratic hydra and mostly losing, but competent and doing things like providing IGs with relevant ammo.

If not true in this case then the audit should be redone with relevant criteria.

George William Herbert
Sent from my iPhone

> On Mar 22, 2016, at 11:36 AM, Sean Donelan <sean at donelan.com> wrote:
> 
>> On Tue, 22 Mar 2016, George Herbert wrote:
>> Come on, the audit requirements should have diversity/redundancy concerns in them.
>> 
>> That's standard in all the audits I have done or participated in.
>> 
>> If these ones don't I have a marketing opportunity to teach a HA seminar and followon consulting to the IG.
> 
> Turn on C-SPAN and watch any random congressional oversight hearing.
> 
> Reasonable, rational or logical thoughts are rare. You may be making assumptions that aren't supported.  Just ask Flint Michigan about saving
> money on cheaper water supplies.
> 

From faisal at snappytelecom.net  Tue Mar 22 21:04:34 2016
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Tue, 22 Mar 2016 21:04:34 +0000 (GMT)
Subject: Looking for Transport 5g/10g between Miami to Fortaleza, Brazil
Message-ID: <1540029628.2886451.1458680674676.JavaMail.zimbra@snappytelecom.net>

Hello all,

Anyone who can provide this, can you please contact me off list ?

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

From paul at paulstewart.org  Wed Mar 23 08:25:55 2016
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 23 Mar 2016 04:25:55 -0400
Subject: Citrix Sales Reps?
In-Reply-To: <CAHddgMxr1Y3C4eoj8bKvY0kxP_fDz6395sfe6OxyryFO5fJnfg@mail.gmail.com>
References: <CAHddgMxr1Y3C4eoj8bKvY0kxP_fDz6395sfe6OxyryFO5fJnfg@mail.gmail.com>
Message-ID: <084201d184dd$9f08adc0$dd1a0940$@paulstewart.org>

You too ?  I gave up ... after calling their local offices, their toll free number, emails, phone calls, etc..... 

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Fisher
Sent: Tuesday, March 22, 2016 1:34 PM
To: NANOG list <nanog at nanog.org>
Subject: Citrix Sales Reps?

I have sent 4 requests to Citrix for pricing questions on XenServer support options and have gotten not a single call back. (Requested via email, form, and calls).

Can someone from Citrix please hit me up offlist or can someone direct me to an actual person I can hit up?

--
Scott


From jvasseur at cisco.com  Sun Mar 20 17:40:34 2016
From: jvasseur at cisco.com (JP Vasseur (jvasseur))
Date: Sun, 20 Mar 2016 17:40:34 +0000
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <56EEDC3D.4010804@tiedyenetworks.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>,
 <56EEDC3D.4010804@tiedyenetworks.com>
Message-ID: <C9FE7C46-393F-40B2-9F85-5994D0A24FB5@cisco.com>

Sorry I didn't reply ... Sure you can send them out to Nick - thanks Tom

JP Vasseur
Cisco Fellow

On 20 mars 2016, at 09:25, Mike <mike-nanog at tiedyenetworks.com<mailto:mike-nanog at tiedyenetworks.com>> wrote:


This is great, I now have something I can show to my customers to confirm that all this power cycling and such really is an 'accepted problem'...

On 03/19/2016 04:16 PM, Warren Kumari wrote:
Found on Staple's website:
http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686

Fixes all issues, less downtime, less stress...
Improves performance, eliminates buffering...
It slices, it dices in teeny, tiny slices.
It makes mounds of julienne fries in just seconds.
...

Description - copied here for convenience:

All the issues associated with the Internet being down can be solved by
power cycling the modem and router. But that can be hard to do! NetReset
resolves network issues by offering sequential power cycling. This means
that when the modem and router are plugged into the device, they are
powered up at different times. The modem is powered up first, then a minute
later, the router is powered up. This rebooting will occur at initial
setup, every 24 hours and after a power failure. Do you have a modem/router
combo? No problem! NetReset will also power cycle the modem/router combo.


Automatically resets user's Internet every 24 hours
Maximizes Internet speed & reliability
Eliminates media stream buffering
Hands-free Internet reset
Resets hard-to-reach modem/router
Less Internet downtime
Less daily stress
No need to manually reset
Reset occurs at programmed time
Updated information from Internet service provider
Proper reboot after a power failure
Resetting allows equipment to auto-correct issues




From llabas at gmail.com  Sun Mar 20 18:20:19 2016
From: llabas at gmail.com (Larry LaBas)
Date: Sun, 20 Mar 2016 11:20:19 -0700
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <56EEDC3D.4010804@tiedyenetworks.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
Message-ID: <etPan.56eee9e3.176f5745.69c@Larrys-MacBook-Pro.local>

Cheaper on Amazon.

http://www.amazon.com/gp/product/B00HUEU9H8?colid=NY8W2WMIT0JS&coliid=I3F8LOHOKAZ56E&ref_=wl_it_dp_o_pC_nS_ttl

--?
Larry LaBas
Sent with Airmail

On March 20, 2016 at 10:24:43, Mike (mike-nanog at tiedyenetworks.com) wrote:


This is great, I now have something I can show to my customers to  
confirm that all this power cycling and such really is an 'accepted  
problem'...  

On 03/19/2016 04:16 PM, Warren Kumari wrote:  
> Found on Staple's website:  
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686  
>  
> Fixes all issues, less downtime, less stress...  
> Improves performance, eliminates buffering...  
> It slices, it dices in teeny, tiny slices.  
> It makes mounds of julienne fries in just seconds.  
> ...  
>  
> Description - copied here for convenience:  
>  
> All the issues associated with the Internet being down can be solved by  
> power cycling the modem and router. But that can be hard to do! NetReset  
> resolves network issues by offering sequential power cycling. This means  
> that when the modem and router are plugged into the device, they are  
> powered up at different times. The modem is powered up first, then a minute  
> later, the router is powered up. This rebooting will occur at initial  
> setup, every 24 hours and after a power failure. Do you have a modem/router  
> combo? No problem! NetReset will also power cycle the modem/router combo.  
>  
>  
> Automatically resets user's Internet every 24 hours  
> Maximizes Internet speed & reliability  
> Eliminates media stream buffering  
> Hands-free Internet reset  
> Resets hard-to-reach modem/router  
> Less Internet downtime  
> Less daily stress  
> No need to manually reset  
> Reset occurs at programmed time  
> Updated information from Internet service provider  
> Proper reboot after a power failure  
> Resetting allows equipment to auto-correct issues  
>  
>  


From web at typo.org  Mon Mar 21 08:19:15 2016
From: web at typo.org (Wayne Bouchard)
Date: Mon, 21 Mar 2016 01:19:15 -0700
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <56EF71E4.4070501@cox.net>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EF71E4.4070501@cox.net>
Message-ID: <20160321081915.GA47130@spider.typo.org>

On Sun, Mar 20, 2016 at 11:00:36PM -0500, Larry Sheldon wrote:
> On 3/19/2016 18:16, Warren Kumari wrote:
> > Found on Staple's website:
> > http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
> >
> > Fixes all issues, less downtime, less stress...
> 
> etc...
> .......
> ........
> ...and so forth
> ................
> .................
> ..................and so on.
> 
> > Resetting allows equipment to auto-correct issues
> 
> Recalls to mind years ago in the Toll testroom where I work, the 
> evenings equipment man (charged with and assigned to the task of 
> repairing equipment that had been "patched out" by the day shift) would, 
> when he arrived for work each day, retrieve the piece of 2 X 4 from its 
> hiding place and whack each bay of relay-rich equipment as he walked in 
> the area.
> 
> Then, after some coffee and a cigarette, he would go through the 
> trouble-ticket collection, retest the item, mark the ticket "NTF" and 
> proceed to the next item.

I love that!

Just goes to show the vast range of technical issues that can be
readily righted with little more than a good thump with a hammer.

-Wayne

---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/

From mike at sentex.net  Mon Mar 21 18:12:04 2016
From: mike at sentex.net (Mike Tancsa)
Date: Mon, 21 Mar 2016 14:12:04 -0400
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <56F03974.9020902@sentex.net>

On 3/19/2016 7:16 PM, Warren Kumari wrote:
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
> 
> Fixes all issues, less downtime, less stress...
> setup, every 24 hours and after a power failure. Do you have a modem/router
> combo? No problem! NetReset will also power cycle the modem/router combo.
> 
> 
> Automatically resets user's Internet every 24 hours


Excellent!  With any luck, it would be at the exact same time for all
users.  I was just thinking the other day, "You know, my RADIUS servers
just dont get enough spike load..."

	---Mike



-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

From nathan at atlasonnet.com  Mon Mar 21 18:48:56 2016
From: nathan at atlasonnet.com (Nathan Eisenberg)
Date: Mon, 21 Mar 2016 18:48:56 +0000
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C2802B45D79BD@EX-MB-1.corp.atlasnetworks.us>

> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686

My coworker's immediate response was:
"Now we all need to get jobs as Automated Router Power Cycling technicians".

Mine was to check my calendar to see if I'd lost a week and a half, and it was suddenly April 1st.

From danm at prime.gushi.org  Tue Mar 22 01:47:05 2016
From: danm at prime.gushi.org (Dan Mahoney, System Admin)
Date: Mon, 21 Mar 2016 18:47:05 -0700 (PDT)
Subject: Paging someone at SonicWall/Dell
Message-ID: <alpine.BSF.2.00.1603211840280.78341@prime.gushi.org>

All,

If anyone has any contacts at Dell/SonicWall that can assist, their latest 
firewalls have a misfeature that have started blocking F-root (ISC, my 
Day-job) as a possible botnet responder.

You can reach me, 24/7, at 703-338-2497, or at dmahoney at isc.org.

Needless to say, this is seriously bad.  As we ourselves are not 
Sonicwall users, our options here are limited.

I've gotten their usual call center nonsense where they told me "I need to 
contact my system administrator" and wouldn't transfer me further.

I've submitted a "removal" request via the form at 
http://botnet.global.sonicwall.com/change, but that still doesn't help if 
there's a firmware out there doing broken hueristics and mass-DDOSing 
folks.

If for some reason there actually IS some botnet-related traffic going on 
toward the root servers (the root servers get a LOT of garbage, so this 
doesn't surprise me), we'd like to know that too.

-Dan Mahoney

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------


From woody at pch.net  Sun Mar 20 17:38:04 2016
From: woody at pch.net (Bill Woodcock)
Date: Sun, 20 Mar 2016 10:38:04 -0700
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
Message-ID: <6124A1BF-2BE6-4490-B5E8-671509D59B42@pch.net>


> On Mar 19, 2016, at 4:16 PM, Warren Kumari <warren at kumari.net> wrote:
> 
> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686

I got one of these in my effort to make my self a little more redundant to my parental tech-support role, a little more sophisticated, tests up-through-layer-3 in unexplained ways which I haven?t yet bothered to pcap.

http://resetplug.com



                                -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/20160320/8858df8f/attachment.pgp>

From rafael at e2wsolutions.com  Tue Mar 22 16:23:17 2016
From: rafael at e2wsolutions.com (Rafael Possamai)
Date: Tue, 22 Mar 2016 11:23:17 -0500
Subject: Why the US Government has so many data centers
In-Reply-To: <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <56E32329.3020201@spawar.navy.mil>
 <F79AC928-7046-47A2-8153-4E1686F09700@gmail.com>
 <5800583B-80B0-48FC-A3EB-1193D4949E45@arbor.net>
 <alpine.BSF.2.20.1603131711530.71886@cnex.qbaryna.pbz>
 <CAD8GWsuAKZ4XxuYvKceukhHkEh0mpiMqb79c6Cq2JO03Dsub7Q@mail.gmail.com>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <330448747.6604.1458661453203.JavaMail.zimbra@baylink.com>
 <alpine.BSF.2.20.1603221200410.41951@cnex.qbaryna.pbz>
Message-ID: <CAGcPvc8Kqz1+1CeGsEq=+uqQagxJi_ATZUqOGAYrAMSmEz8nZA@mail.gmail.com>

Circuit utilization, capacity and availability shouldn't be calculated
separately in a data center environment. If you look at each separately you
risk making some expensive mistakes.


*Rafael Possamai*
Founder & CEO at E2W Solutions
*office:* (414) 269-6000
*e-mail:* rafael at e2wsolutions.com


On Tue, Mar 22, 2016 at 11:11 AM, Sean Donelan <sean at donelan.com> wrote:

> On Tue, 22 Mar 2016, Jay R. Ashworth wrote:
>
>> But when some Armenian script kiddie DDoSing Netflix takes down your TSA
>> terrorist lookup service, and you come to me asking why the plane blew up,
>> I'm going to tell you "because you fucking ignored my written advice on
>> the matter", while I'm packing my desk.
>>
>
> DOCI is about physical data center opimization, not about network or
> service availability.
>
> DCOI metrics:
> - Energy metering
> - Power Usage Effectiveness (PUE)
> - Virtualization
> - Server Utilization & Automated Monitoring
> - Facility Utilization
>
> Why do you have two circuits with only 40% utilization. The auditor says
> that's waste, and you only need one circuit at 80% utilization for half
> the cost.
>
>
>

From rafael at e2wsolutions.com  Wed Mar 23 12:51:56 2016
From: rafael at e2wsolutions.com (Rafael Possamai)
Date: Wed, 23 Mar 2016 07:51:56 -0500
Subject: Citrix Sales Reps?
In-Reply-To: <084201d184dd$9f08adc0$dd1a0940$@paulstewart.org>
References: <CAHddgMxr1Y3C4eoj8bKvY0kxP_fDz6395sfe6OxyryFO5fJnfg@mail.gmail.com>
 <084201d184dd$9f08adc0$dd1a0940$@paulstewart.org>
Message-ID: <CAGcPvc-0A5Q5kFerT=R=z8FNsZKz2SeP6ey1ALEOy69Agd_C7w@mail.gmail.com>

I wonder if the actual support service will be the same later on.

*Rafael Possamai*
Founder & CEO at E2W Solutions
*office:* (414) 269-6000
*e-mail:* rafael at e2wsolutions.com


On Wed, Mar 23, 2016 at 3:25 AM, Paul Stewart <paul at paulstewart.org> wrote:

> You too ?  I gave up ... after calling their local offices, their toll
> free number, emails, phone calls, etc.....
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Fisher
> Sent: Tuesday, March 22, 2016 1:34 PM
> To: NANOG list <nanog at nanog.org>
> Subject: Citrix Sales Reps?
>
> I have sent 4 requests to Citrix for pricing questions on XenServer
> support options and have gotten not a single call back. (Requested via
> email, form, and calls).
>
> Can someone from Citrix please hit me up offlist or can someone direct me
> to an actual person I can hit up?
>
> --
> Scott
>
>

From davep at imre.com  Wed Mar 23 11:50:54 2016
From: davep at imre.com (Dave Provine)
Date: Wed, 23 Mar 2016 11:50:54 +0000
Subject: Any GoDaddy network engineers on this list?
Message-ID: <D317FB5D.9F23C%davep@imre.com>

I seem to have a routing problem from you to me, and of course neither the
frontline nor the ?advanced? support has any interest in understanding the
issue, which is likely a simple fix for the right engineer.



From uwcableguy at gmail.com  Wed Mar 23 13:32:20 2016
From: uwcableguy at gmail.com (Ben Bartsch)
Date: Wed, 23 Mar 2016 08:32:20 -0500
Subject: mrtg alternative
In-Reply-To: <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
Message-ID: <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>

Consultant here...

We used StatSeeker at a large state government WAN (my last gig before
turning consultant) and I personally loved it for graphs and to point
customers to (you can easily set up user accounts where they can log in via
a web portal and they can see the graphs you assign them).  I have no idea
how much it costs or how easy / difficult the backend server set up is.
>From a network admin point of view, if all you need is graphs you cannot
beat the ease of StatSeeker.  I have nothing bad to say about them - their
support is great (but they are on Australian time).  It's been a couple
years since I've used it though.

We also had OpenNMS and Intermapper, both of which were kind of quirky, but
seemed to get the job done.  We had internal support for OpenNMS, which was
decent (as good as your staff is).  Intermapper support was horrible.

Today we deploy a lot of Cacti and it seems to work well, once it's working.

I see a lot of MRTG at our customer sites too.  I've seen a few SolarWinds
instances as well.  Customers that use these seem happy with their choice.

Zenoss I've only seen at CiscoLive, but I was impressed.  Observium also
looks like a good product, but I've never seen it on a network.

-bb



On Tue, Mar 22, 2016 at 1:15 PM, Jason LeBlanc <
jason.leblanc at infusionsoft.com> wrote:

> +1 on Observium.
>
> I know I am late replying but I just installed it a couple weeks ago.  It
> integrates with Smokeping, Rancid, CollectD, Syslo... Took me 1 day to
> setup on CentOS.  Fantastic product so far!
>
>
> //LeBlanc
>
> >We?re using Observium for trend collecting, graphing, and alerting.
> >
> >-Pete
> >
>

From littlefishguy at gmail.com  Wed Mar 23 15:59:21 2016
From: littlefishguy at gmail.com (Scott Fisher)
Date: Wed, 23 Mar 2016 11:59:21 -0400
Subject: Citrix Sales Reps?
In-Reply-To: <CAGcPvc-0A5Q5kFerT=R=z8FNsZKz2SeP6ey1ALEOy69Agd_C7w@mail.gmail.com>
References: <CAHddgMxr1Y3C4eoj8bKvY0kxP_fDz6395sfe6OxyryFO5fJnfg@mail.gmail.com>
 <084201d184dd$9f08adc0$dd1a0940$@paulstewart.org>
 <CAGcPvc-0A5Q5kFerT=R=z8FNsZKz2SeP6ey1ALEOy69Agd_C7w@mail.gmail.com>
Message-ID: <CAHddgMwOgsOikBehY6Wy9cCber981yC84bXRBXLvgjdW8zgM2Q@mail.gmail.com>

I have gotten hit up by multiple people at Citrix and have a call scheduled
with the correct Rep. Thanks for all the replies.

On Wed, Mar 23, 2016 at 8:51 AM, Rafael Possamai <rafael at e2wsolutions.com>
wrote:

> I wonder if the actual support service will be the same later on.
>
> *Rafael Possamai*
> Founder & CEO at E2W Solutions
> *office:* (414) 269-6000
> *e-mail:* rafael at e2wsolutions.com
>
>
> On Wed, Mar 23, 2016 at 3:25 AM, Paul Stewart <paul at paulstewart.org>
> wrote:
>
>> You too ?  I gave up ... after calling their local offices, their toll
>> free number, emails, phone calls, etc.....
>>
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Fisher
>> Sent: Tuesday, March 22, 2016 1:34 PM
>> To: NANOG list <nanog at nanog.org>
>> Subject: Citrix Sales Reps?
>>
>> I have sent 4 requests to Citrix for pricing questions on XenServer
>> support options and have gotten not a single call back. (Requested via
>> email, form, and calls).
>>
>> Can someone from Citrix please hit me up offlist or can someone direct me
>> to an actual person I can hit up?
>>
>> --
>> Scott
>>
>>
>


-- 
Scott

From jeffg at opennms.org  Wed Mar 23 16:50:40 2016
From: jeffg at opennms.org (Jeff Gehlbach)
Date: Wed, 23 Mar 2016 12:50:40 -0400
Subject: mrtg alternative
In-Reply-To: <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
 <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
Message-ID: <56F2C960.3010809@opennms.org>

"Vendor" here (technologist role, occasionally helping with sales, at
OpenNMS.com)...

On 03/23/2016 09:32 AM, Ben Bartsch wrote:
> We used StatSeeker at a large state government WAN (my last gig
> before turning consultant) and I personally loved it for graphs and
> to point customers to (you can easily set up user accounts where they
> can log in via a web portal and they can see the graphs you assign
> them).  I have no idea how much it costs or how easy / difficult the
> backend server set up is.

We're in the middle of a project with a customer to replace StatSeeker
with OpenNMS. That's a very realistic goal now that Cassandra is an
option for our time-series metric storage.

StatSeeker can definitely get expensive, but I can't speak to ease of
setup or operation.

> We also had OpenNMS and Intermapper, both of which were kind of
> quirky, but seemed to get the job done.

Glad to hear we got the job done. I'm the first to admit that custom
graph configuration in OpenNMS itself is still pretty crap (it amounts
to editing RRDTool graph definitions).

That's a big part of why we now have a Grafana data source plugin:

http://www.opennms.org/wiki/Grafana

> We had internal support for OpenNMS, which was decent (as good as
> your staff is).

I'm the person responsible for making the support experience far above
"decent". I'd love to hear your thoughts on how we can improve; please
contact me off-list if you have the time and inclination.

-jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160323/7cf1d3a4/attachment.pgp>

From A.L.M.Buxey at lboro.ac.uk  Wed Mar 23 17:06:25 2016
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Wed, 23 Mar 2016 17:06:25 +0000
Subject: mrtg alternative
In-Reply-To: <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
 <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
Message-ID: <B8C72973-4CDC-400D-B169-731A7E5AC621@lboro.ac.uk>

+1 for Statseeker. Ease of use etc (price depends on eg site size etc). Can do lots on just one mid server unlike some other bloaty solutions out there.  But we also still use MRTG for some local bespoke measurements 

PS you can get a free Eval of statseeker. Obnote, don't work for them just a fairly happy customer

alan

From jaydesh9 at gmail.com  Tue Mar 22 19:56:49 2016
From: jaydesh9 at gmail.com (=?utf-8?Q? Jayram_A._D=C3=A9shpand=C3=A9 ?=)
Date: Tue, 22 Mar 2016 12:56:49 -0700
Subject: Citrix Sales Reps?
In-Reply-To: <CAHddgMxr1Y3C4eoj8bKvY0kxP_fDz6395sfe6OxyryFO5fJnfg@mail.gmail.com>
References: <CAHddgMxr1Y3C4eoj8bKvY0kxP_fDz6395sfe6OxyryFO5fJnfg@mail.gmail.com>
Message-ID: <B8118C87-8BB0-408B-A2CD-962F2054E131@gmail.com>

Hi Scott ,

I will contact you off the list. 

Cheers,
-Jay


> On Mar 22, 2016, at 10:33 AM, Scott Fisher <littlefishguy at gmail.com> wrote:
> 
> I have sent 4 requests to Citrix for pricing questions on XenServer support
> options and have gotten not a single call back. (Requested via email, form,
> and calls).
> 
> Can someone from Citrix please hit me up offlist or can someone direct me
> to an actual person I can hit up?
> 
> -- 
> Scott


From surfer at mauigateway.com  Wed Mar 23 18:38:00 2016
From: surfer at mauigateway.com (Scott Weeks)
Date: Wed, 23 Mar 2016 11:38:00 -0700
Subject: Citrix Sales Reps?
Message-ID: <20160323113800.8BBF18BB@m0087795.ppops.net>


> On Mar 22, 2016, at 10:33 AM, Scott Fisher <littlefishguy at gmail.com> wrote:
> 
> I have sent 4 requests to Citrix for pricing questions on XenServer support
> options and have gotten not a single call back. (Requested via email, form,
> and calls).


--- jaydesh9 at gmail.com wrote:
From: "Jayram A. D?shpand?" <jaydesh9 at gmail.com>

I will contact you off the list. 
----------------------------------------


If they won't speak to you until you embarrass them 
publically in front of over 10,000 people I would 
suggest that shows the level of service you'll get 
after the sale.


scott

From me at anuragbhatia.com  Wed Mar 23 21:22:23 2016
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 24 Mar 2016 02:52:23 +0530
Subject: mrtg alternative
In-Reply-To: <B8C72973-4CDC-400D-B169-731A7E5AC621@lboro.ac.uk>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
 <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
 <B8C72973-4CDC-400D-B169-731A7E5AC621@lboro.ac.uk>
Message-ID: <CAJ0+aXbbRM=Punaq1xTUnnN+yz2TanTiQ9nHqjrN_YkbzkBXKw@mail.gmail.com>

+1 for Cacti.


I tried zenoss & observium but still Cacti is more cool in terms of
tweaking templates as well as the tree mode for easy quick representation.



Thanks for starting this cool thread. Will help in getting links to some of
other cool projects which we don't hear around.

On Wed, Mar 23, 2016 at 10:36 PM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
wrote:

> +1 for Statseeker. Ease of use etc (price depends on eg site size etc).
> Can do lots on just one mid server unlike some other bloaty solutions out
> there.  But we also still use MRTG for some local bespoke measurements
>
> PS you can get a free Eval of statseeker. Obnote, don't work for them just
> a fairly happy customer
>
> alan
>



-- 


Anurag Bhatia
anuragbhatia.com

From faisal at snappytelecom.net  Wed Mar 23 21:49:17 2016
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Wed, 23 Mar 2016 21:49:17 +0000 (GMT)
Subject: Peer1 Colo Facility ?
Message-ID: <791540396.2900131.1458769757259.JavaMail.zimbra@snappytelecom.net>

Hello,

Anyone with Peer1 Colo Facility (sales) ?
Can you please contact me off list ?

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

From paras at protrafsolutions.com  Wed Mar 23 23:39:55 2016
From: paras at protrafsolutions.com (Paras Jha)
Date: Wed, 23 Mar 2016 19:39:55 -0400
Subject: NTT communications horrible routing, unresponsive NOC
Message-ID: <CAJayEpF3=NYtZoJ0tZ_1D3z_ZGP1tL0fye4-EiRf1AmdDc8nbA@mail.gmail.com>

Hi all,

I've been trying to get this issue resolved for the entire day now, but NTT
has been pretty unreceptive here.

We're announcing a large prefix for a client across our network, and we
discovered some insanely high latency.

After tracking down the issue, we determined it to be something wrong with
NTT at their Seattle location. We anycast this prefix, but no matter where
in the world traffic is originating from, it's going to Seattle and then to
Atlanta. Example: Rotterdam in the Netherlands routes from Europe -> east
coast -> west coast Seattle -> los angeles -> atlanta. The gist of it is
that something is seriously messed up at NTT in Seattle.

We contacted our transit provider to try and carry the issue upstream, and
what they told us was

Sorry for delay, I've asked NTT to clear the more specific for this one as
well.
The problem seems to be a bug on the NTT side which keeps stale routes in
the routing table for more specifics ( at random ).
If you have more routes affected please notify us of the routes and I will
ask them to clear the routing table for these routes.
NTT is working on this with their vendor to get this resolved as soon as
possible.


I had spoken to a sales rep for NTT a few weeks prior, and they assured me
that the NOC was top notch, and that all routes were redundant, and they
guaranteed less than 50ms in the US, and all kinds of marketing. However,
it looks like it's all marketing - for this entire day this router has been
causing tons of issues for our clients.

No-exporting it to NTT does not even solve the problem, as NTT's router in
Seattle apparently just decides to keep random small prefixes in it,
causing traffic to go there.

At a loss as to what to do now, since their NOC isn't receptive. Anyone
have someone I can contact off-list to get this issue resolved? It's
especially frustrating because the problem absolutely cannot be resolved on
our end, even with a no-export since NTT is keeping the routes in their
router.

From morrowc.lists at gmail.com  Thu Mar 24 00:52:25 2016
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 23 Mar 2016 20:52:25 -0400
Subject: NTT communications horrible routing, unresponsive NOC
In-Reply-To: <CAJayEpF3=NYtZoJ0tZ_1D3z_ZGP1tL0fye4-EiRf1AmdDc8nbA@mail.gmail.com>
References: <CAJayEpF3=NYtZoJ0tZ_1D3z_ZGP1tL0fye4-EiRf1AmdDc8nbA@mail.gmail.com>
Message-ID: <CAL9jLaYLCfJ_EbDBdmOawTr0cHxUDOVhZL8uAoQENrJDWV=amg@mail.gmail.com>

which route and did you look at their lookingglass during the period of
time when things were/are bad to see what the LG saw?

https://www.us.ntt.net/support/looking-glass/

shouting into the wind doesn't really help, information though could be
helpful.

On Wed, Mar 23, 2016 at 7:39 PM, Paras Jha <paras at protrafsolutions.com>
wrote:

> Hi all,
>
> I've been trying to get this issue resolved for the entire day now, but NTT
> has been pretty unreceptive here.
>
> We're announcing a large prefix for a client across our network, and we
> discovered some insanely high latency.
>
> After tracking down the issue, we determined it to be something wrong with
> NTT at their Seattle location. We anycast this prefix, but no matter where
> in the world traffic is originating from, it's going to Seattle and then to
> Atlanta. Example: Rotterdam in the Netherlands routes from Europe -> east
> coast -> west coast Seattle -> los angeles -> atlanta. The gist of it is
> that something is seriously messed up at NTT in Seattle.
>
> We contacted our transit provider to try and carry the issue upstream, and
> what they told us was
>
> Sorry for delay, I've asked NTT to clear the more specific for this one as
> well.
> The problem seems to be a bug on the NTT side which keeps stale routes in
> the routing table for more specifics ( at random ).
> If you have more routes affected please notify us of the routes and I will
> ask them to clear the routing table for these routes.
> NTT is working on this with their vendor to get this resolved as soon as
> possible.
>
>
> I had spoken to a sales rep for NTT a few weeks prior, and they assured me
> that the NOC was top notch, and that all routes were redundant, and they
> guaranteed less than 50ms in the US, and all kinds of marketing. However,
> it looks like it's all marketing - for this entire day this router has been
> causing tons of issues for our clients.
>
> No-exporting it to NTT does not even solve the problem, as NTT's router in
> Seattle apparently just decides to keep random small prefixes in it,
> causing traffic to go there.
>
> At a loss as to what to do now, since their NOC isn't receptive. Anyone
> have someone I can contact off-list to get this issue resolved? It's
> especially frustrating because the problem absolutely cannot be resolved on
> our end, even with a no-export since NTT is keeping the routes in their
> router.
>

From tony at swalter.com  Thu Mar 24 01:36:59 2016
From: tony at swalter.com (Tony Patti)
Date: Thu, 24 Mar 2016 01:36:59 +0000
Subject: Top-shelf resilience (Re: Why the US Government has so many data
 centers)
In-Reply-To: <379019868.7687.1458676764070.JavaMail.zimbra@baylink.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
 <3B1CC2C8-560A-4D02-8AED-3CE8180EC7FA@n5tech.com>
 <C56B4D6A-F03B-42CE-9EF9-54563547CB44@gmail.com>
 <379019868.7687.1458676764070.JavaMail.zimbra@baylink.com>
Message-ID: <BY1PR0501MB14774339B86D3A1D57A00D8CD3820@BY1PR0501MB1477.namprd05.prod.outlook.com>

FYI, similar to "battleshort", the term BATTLE OVERRIDE is described [1] on page 45 of G. Gordon Liddy's book _Will_,
and apparently [2] "Battle Override" was to be the original title of Liddy's autobiography, but the publisher wanted a one-word title.  Quotes: 

"On the multidialed wall behind the radar technicians was a prominent switch with a red security cover.  It was marked: BATTLE OVERRIDE", and 

"In the event of a battle emergency, however, the protective warm-up delay could be overridden and full power applied immediately by throwing the 'Battle Override' switch, as everything and everyone became expendable in war."

Tony Patti
CIO

[1] https://books.google.com/books?id=YRty_4HT_8kC&pg=PA45&lpg=PA45&dq=%22battle+override%22+M-33c&source=bl&ots=RYLdUECeHF&sig=hs9i6-W_CVwe5ZcjpxbEGSh9TNE&hl=en&sa=X&ved=0ahUKEwi474vOltjLAhUKcRQKHUHmCW4Q6AEIHjAA#v=onepage&q=%22battle%20override%22%20M-33c&f=false 
[2] http://www.worldwizzy.com/library/G._Gordon_Liddy 

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay R. Ashworth
Sent: Tuesday, March 22, 2016 3:59 PM
To: North American Network Operators' Group
Subject: Top-shelf resilience (Re: Why the US Government has so many data centers)

----- Original Message -----
> From: "George Herbert" <george.herbert at gmail.com>

> There are corner cases where distributed resilience is paramount, 
> including a lot of field operations (of all sorts) on ships (and 
> aircraft and spacecraft), or places where the net really is unstable.  
> Any generalizations that wrap those legitimate exceptions in are overreaching their valid descriptive range.

This seems like a good time to mention my favorite example of such a thing.

In the Navy, originally, and it ended up in a few other places, there was invented the concept of a 'battleshort', or 'battleshunt', depending on whom you're talking to.

This was something akin to a Big Frankenstein Knife Switch across the main circuit breaker in a power panel (and maybe a couple branch circuit breakers), whose job was to make sure those didn't trip on you at an inconvenient time.

Like when you were trying to lay a gun on a Bad Guy.

The engineering decision that was made there was that the minor possiblity of a circuit overheating and starting something on fire was less important that *the ability to shoot at the bad guys*...

Or, in my favorite example, something going wrong when launching Apollo rockets.

If you examine the Firing Room recorder transcripts from the manned Apollo launches, you will find, somewhere in the terminal count, an instruction to "engage the battle short", or something like that.

Men were, I have been told, stationed at strategic locations with extinguishers, in case something which would normally have tripped a breaker was forbidden from doing so by the shunt...

so that the power wouldn't go out at T-4 seconds.

It's referenced in this article:

  http://www.honeysucklecreek.net/station/ops_areas.html

and a number of other places google will find you.

Unknown whether this protocol was still followed in the Shuttle era, or whether it will return in the New Manned Space Flight era.

But, like the four star saluting the Medal Of Honor recipient, it's one of those outliers that's *so far* out, that I love and collect them.

And it's a good category of idea to have in the back of your head when planning.

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 chip at 2bithacker.net  Thu Mar 24 03:51:40 2016
From: chip at 2bithacker.net (Chip Marshall)
Date: Wed, 23 Mar 2016 22:51:40 -0500
Subject: mrtg alternative
In-Reply-To: <CAJ0+aXbbRM=Punaq1xTUnnN+yz2TanTiQ9nHqjrN_YkbzkBXKw@mail.gmail.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
 <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
 <B8C72973-4CDC-400D-B169-731A7E5AC621@lboro.ac.uk>
 <CAJ0+aXbbRM=Punaq1xTUnnN+yz2TanTiQ9nHqjrN_YkbzkBXKw@mail.gmail.com>
Message-ID: <20160324035140.GA48396@2bithacker.net>

May want to check out AKiPS. It's non-free, but we've been using it for
a while now, and it works pretty well. The UI is a little rough, but the
poller is fast, and the graphs render quickly.

https://www.akips.com/

On 2016-03-24, Anurag Bhatia <me at anuragbhatia.com> sent:
> +1 for Cacti.
> 
> I tried zenoss & observium but still Cacti is more cool in
> terms of tweaking templates as well as the tree mode for easy
> quick representation.
> 
> Thanks for starting this cool thread. Will help in
> getting links to some of other cool projects which we
> don't hear around.
> 
> On Wed, Mar 23, 2016 at 10:36 PM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
> wrote:
> 
> > +1 for Statseeker. Ease of use etc (price depends on eg site size etc).
> > Can do lots on just one mid server unlike some other bloaty solutions out
> > there.  But we also still use MRTG for some local bespoke measurements
> >
> > PS you can get a free Eval of statseeker. Obnote, don't work for them just
> > a fairly happy customer
> >
> > alan
> >
> 
> 
> 
> -- 
> 
> 
> Anurag Bhatia
> anuragbhatia.com

-- 
Chip Marshall <chip at 2bithacker.net>
http://2bithacker.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160323/490e26e8/attachment.pgp>

From jwbensley at gmail.com  Thu Mar 24 11:32:29 2016
From: jwbensley at gmail.com (James Bensley)
Date: Thu, 24 Mar 2016 11:32:29 +0000
Subject: NTT communications horrible routing, unresponsive NOC
In-Reply-To: <CAJayEpF3=NYtZoJ0tZ_1D3z_ZGP1tL0fye4-EiRf1AmdDc8nbA@mail.gmail.com>
References: <CAJayEpF3=NYtZoJ0tZ_1D3z_ZGP1tL0fye4-EiRf1AmdDc8nbA@mail.gmail.com>
Message-ID: <CAAWx_pV9h-U2AUWHVpWoUyPq_kH3mWZSKP1i61oAPnk6rp+igA@mail.gmail.com>

On 23 March 2016 at 23:39, Paras Jha <paras at protrafsolutions.com> wrote:
> At a loss as to what to do now, since their NOC isn't receptive. Anyone
> have someone I can contact off-list to get this issue resolved? It's
> especially frustrating because the problem absolutely cannot be resolved on
> our end, even with a no-export since NTT is keeping the routes in their
> router.

It would be helpful to show how you came to these conclusions about
prefix caching and routing issues etc (share the data you gathered).

If you are an NTT customer (it's sounds a bit like you're a customer
of an NTT customer, it's not clear) then this should be account
management 101, you should have an escalations process/matrix, kick
off that process now.

There are NTT dudes on this list so probably they will reach out to
you off list, if not post back requesting an NTT contact.

James.

From jared at puck.nether.net  Thu Mar 24 12:12:10 2016
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 24 Mar 2016 08:12:10 -0400
Subject: NTT communications horrible routing, unresponsive NOC
In-Reply-To: <CAJayEpF3=NYtZoJ0tZ_1D3z_ZGP1tL0fye4-EiRf1AmdDc8nbA@mail.gmail.com>
References: <CAJayEpF3=NYtZoJ0tZ_1D3z_ZGP1tL0fye4-EiRf1AmdDc8nbA@mail.gmail.com>
Message-ID: <7DCCA989-3C37-4A35-83E4-671E01ADDE9D@puck.nether.net>

Hello,

Could you send me some more details in private about who you spoke with including email addresses and ticket numbers with our NOC if any?

I'd like to understand what happened here as this is an uncharacteristic outcome. I know there was planned work in Seattle last night for a software upgrade combined with hardware work, but an operational issue like this should have been resolved. 

I'd like to understand the timeline and what broke down if anything. 

Thanks,

Jared Mauch

> On Mar 23, 2016, at 7:39 PM, Paras Jha <paras at protrafsolutions.com> wrote:
> 
> Hi all,
> 
> I've been trying to get this issue resolved for the entire day now, but NTT
> has been pretty unreceptive here.
> 
> We're announcing a large prefix for a client across our network, and we
> discovered some insanely high latency.
> 
> After tracking down the issue, we determined it to be something wrong with
> NTT at their Seattle location. We anycast this prefix, but no matter where
> in the world traffic is originating from, it's going to Seattle and then to
> Atlanta. Example: Rotterdam in the Netherlands routes from Europe -> east
> coast -> west coast Seattle -> los angeles -> atlanta. The gist of it is
> that something is seriously messed up at NTT in Seattle.
> 
> We contacted our transit provider to try and carry the issue upstream, and
> what they told us was
> 
> Sorry for delay, I've asked NTT to clear the more specific for this one as
> well.
> The problem seems to be a bug on the NTT side which keeps stale routes in
> the routing table for more specifics ( at random ).
> If you have more routes affected please notify us of the routes and I will
> ask them to clear the routing table for these routes.
> NTT is working on this with their vendor to get this resolved as soon as
> possible.
> 
> 
> I had spoken to a sales rep for NTT a few weeks prior, and they assured me
> that the NOC was top notch, and that all routes were redundant, and they
> guaranteed less than 50ms in the US, and all kinds of marketing. However,
> it looks like it's all marketing - for this entire day this router has been
> causing tons of issues for our clients.
> 
> No-exporting it to NTT does not even solve the problem, as NTT's router in
> Seattle apparently just decides to keep random small prefixes in it,
> causing traffic to go there.
> 
> At a loss as to what to do now, since their NOC isn't receptive. Anyone
> have someone I can contact off-list to get this issue resolved? It's
> especially frustrating because the problem absolutely cannot be resolved on
> our end, even with a no-export since NTT is keeping the routes in their
> router.


From crussell at kanren.net  Thu Mar 24 13:08:03 2016
From: crussell at kanren.net (Casey Russell)
Date: Thu, 24 Mar 2016 08:08:03 -0500
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <20160321081915.GA47130@spider.typo.org>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EF71E4.4070501@cox.net> <20160321081915.GA47130@spider.typo.org>
Message-ID: <CAGLsBOiCDs7qDW2S8EEp-upMXZnouDY3ZoJTyGhHZV_944E9=A@mail.gmail.com>

>>Just goes to show the vast range of technical issues that can be
>>readily righted with little more than a good thump with a hammer.

We always referred to that as "percussive maintenance"

Casey Russell
Network Engineer
Kansas Research and Education Network

2029 Becker Drive, Suite 282

Lawrence, KS  66047
(785)856-9820  ext 9809
crussell at kanren.net

On Mon, Mar 21, 2016 at 3:19 AM, Wayne Bouchard <web at typo.org> wrote:

> On Sun, Mar 20, 2016 at 11:00:36PM -0500, Larry Sheldon wrote:
> > On 3/19/2016 18:16, Warren Kumari wrote:
> > > Found on Staple's website:
> > >
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
> > >
> > > Fixes all issues, less downtime, less stress...
> >
> > etc...
> > .......
> > ........
> > ...and so forth
> > ................
> > .................
> > ..................and so on.
> >
> > > Resetting allows equipment to auto-correct issues
> >
> > Recalls to mind years ago in the Toll testroom where I work, the
> > evenings equipment man (charged with and assigned to the task of
> > repairing equipment that had been "patched out" by the day shift) would,
> > when he arrived for work each day, retrieve the piece of 2 X 4 from its
> > hiding place and whack each bay of relay-rich equipment as he walked in
> > the area.
> >
> > Then, after some coffee and a cigarette, he would go through the
> > trouble-ticket collection, retest the item, mark the ticket "NTF" and
> > proceed to the next item.
>
> I love that!
>
> Just goes to show the vast range of technical issues that can be
> readily righted with little more than a good thump with a hammer.
>
> -Wayne
>
> ---
> Wayne Bouchard
> web at typo.org
> Network Dude
> http://www.typo.org/~web/
>

From Vinny_Abello at Dell.com  Thu Mar 24 13:55:09 2016
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Thu, 24 Mar 2016 13:55:09 +0000
Subject: Paging someone at SonicWall/Dell
In-Reply-To: <alpine.BSF.2.00.1603211840280.78341@prime.gushi.org>
References: <alpine.BSF.2.00.1603211840280.78341@prime.gushi.org>
Message-ID: <FD9B2CB2B33E394FAE3B7466954760575B29F979@DFWX10HMPTC01.AMER.DELL.COM>

Hi Dan,

Did you manage to get in touch with anyone? If not, I can attempt to broadcast to the Dell Networking group internally. There should be Sonicwall people on there that can help.

-Vinny

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dan Mahoney, System Admin
Sent: Monday, March 21, 2016 9:47 PM
To: nanog at nanog.org
Subject: Paging someone at SonicWall/Dell

All,

If anyone has any contacts at Dell/SonicWall that can assist, their latest firewalls have a misfeature that have started blocking F-root (ISC, my
Day-job) as a possible botnet responder.

You can reach me, 24/7, at 703-338-2497, or at dmahoney at isc.org.

Needless to say, this is seriously bad. As we ourselves are not Sonicwall users, our options here are limited.

I've gotten their usual call center nonsense where they told me "I need to contact my system administrator" and wouldn't transfer me further.

I've submitted a "removal" request via the form at http://botnet.global.sonicwall.com/change, but that still doesn't help if there's a firmware out there doing broken hueristics and mass-DDOSing folks.

If for some reason there actually IS some botnet-related traffic going on toward the root servers (the root servers get a LOT of garbage, so this doesn't surprise me), we'd like to know that too.

-Dan Mahoney

--

--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------

From owen at delong.com  Thu Mar 24 18:09:37 2016
From: owen at delong.com (Owen DeLong)
Date: Thu, 24 Mar 2016 11:09:37 -0700
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAGLsBOiCDs7qDW2S8EEp-upMXZnouDY3ZoJTyGhHZV_944E9=A@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EF71E4.4070501@cox.net> <20160321081915.GA47130@spider.typo.org>
 <CAGLsBOiCDs7qDW2S8EEp-upMXZnouDY3ZoJTyGhHZV_944E9=A@mail.gmail.com>
Message-ID: <687E5FA1-575F-4723-95FE-639CECC7582B@delong.com>


> On Mar 24, 2016, at 06:08 , Casey Russell <crussell at kanren.net> wrote:
> 
>>> Just goes to show the vast range of technical issues that can be
>>> readily righted with little more than a good thump with a hammer.
> 
> We always referred to that as "percussive maintenance?

If such a need presents itself and one lacks the requisite hammer, one can also resort to ?brogan maintenance? in many cases.

Owen


From nanog at ics-il.net  Thu Mar 24 20:55:05 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Thu, 24 Mar 2016 15:55:05 -0500 (CDT)
Subject: PitIX or pair.com
In-Reply-To: <1398113933.8704.1458852814869.JavaMail.mhammett@ThunderFuck>
Message-ID: <724425330.8714.1458852902829.JavaMail.mhammett@ThunderFuck>

Do any of you have any information on PitIX? It looks like it was another IX started by a datacenter that didn't pan out. Therefore, anyone have a contact at pair.com? An inquiry sent to their web site (well, whatever contact information they have on it) has gone unanswered. 




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



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



From larrysheldon at cox.net  Fri Mar 25 01:10:52 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Thu, 24 Mar 2016 20:10:52 -0500
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <CAGLsBOiCDs7qDW2S8EEp-upMXZnouDY3ZoJTyGhHZV_944E9=A@mail.gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EF71E4.4070501@cox.net> <20160321081915.GA47130@spider.typo.org>
 <CAGLsBOiCDs7qDW2S8EEp-upMXZnouDY3ZoJTyGhHZV_944E9=A@mail.gmail.com>
Message-ID: <56F4901C.6070502@cox.net>

On 3/24/2016 08:08, Casey Russell wrote:
>  >>Just goes to show the vast range of technical issues that can be
>  >>readily righted with little more than a good thump with a hammer.
>
> We always referred to that as "percussive maintenance"
>
> Casey Russell
> Network Engineer
> Kansas Research and Education Network
>
> 2029 Becker Drive, Suite 282
>
> Lawrence, KS  66047
>
> (785)856-9820  ext 9809
> crussell at kanren.net <mailto:crussell at kanren.net>
>
> On Mon, Mar 21, 2016 at 3:19 AM, Wayne Bouchard <web at typo.org
> <mailto:web at typo.org>> wrote:
>
>     On Sun, Mar 20, 2016 at 11:00:36PM -0500, Larry Sheldon wrote:
>     > On 3/19/2016 18:16, Warren Kumari wrote:
>     > > Found on Staple's website:
>     > >http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686
>     > >
>     > > Fixes all issues, less downtime, less stress...
>     >
>     > etc...
>     > .......
>     > ........
>     > ...and so forth
>     > ................
>     > .................
>     > ..................and so on.
>     >
>     > > Resetting allows equipment to auto-correct issues
>     >
>     > Recalls to mind years ago in the Toll testroom where I worked, the
>     > evenings equipment man (charged with and assigned to the task of
>     > repairing equipment that had been "patched out" by the day shift) would,
>     > when he arrived for work each day, retrieve the piece of 2 X 4 from its
>     > hiding place and whack each bay of relay-rich equipment as he walked in
>     > the area.
>     >
>     > Then, after some coffee and a cigarette, he would go through the
>     > trouble-ticket collection, retest the item, mark the ticket "NTF" and
>     > proceed to the next item.
>
>     I love that!
>
>     Just goes to show the vast range of technical issues that can be
>     readily righted with little more than a good thump with a hammer.

In a later live, I worked in a computer center housing A computer (1110, 
1100/80, 1100/90).  The UNIVAC CEs had in their kit an tool for locating 
"shock-sensitive" boards--looked like and worked like an "automatic 
centerpunch" with a blunt point.

-- 
sed quis custodiet ipsos custodes? (Juvenal)

From cscora at apnic.net  Fri Mar 25 18:10:29 2016
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 26 Mar 2016 04:10:29 +1000 (AEST)
Subject: Weekly Routing Table Report
Message-ID: <201603251810.u2PIATxY023536@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,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-stats at lists.apnic.net

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

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

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

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

Analysis Summary
----------------

BGP routing table entries examined:                              587515
    Prefixes after maximum aggregation (per Origin AS):          216203
    Deaggregation factor:                                          2.72
    Unique aggregates announced (without unneeded subnets):      287784
Total ASes present in the Internet Routing Table:                 53221
    Prefixes per ASN:                                             11.04
Origin-only ASes present in the Internet Routing Table:           36607
Origin ASes announcing only one prefix:                           15753
Transit ASes present in the Internet Routing Table:                6412
Transit-only ASes present in the Internet Routing Table:            170
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      37
    Max AS path prepend of ASN ( 40285)                              34
Prefixes from unregistered ASNs in the Routing Table:               958
    Unregistered ASNs in the Routing Table:                         354
Number of 32-bit ASNs allocated by the RIRs:                      13208
Number of 32-bit ASNs visible in the Routing Table:               10202
Prefixes from 32-bit ASNs in the Routing Table:                   39714
Number of bogon 32-bit ASNs visible in the Routing Table:            14
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            363
Number of addresses announced to Internet:                   2807921668
    Equivalent to 167 /8s, 93 /16s and 124 /24s
    Percentage of available address space announced:               75.8
    Percentage of allocated address space announced:               75.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               98.1
Total number of prefixes smaller than registry allocations:      191954

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                   150519
    Total APNIC prefixes after maximum aggregation:               41895
    APNIC Deaggregation factor:                                    3.59
Prefixes being announced from the APNIC address blocks:          160568
    Unique aggregates announced from the APNIC address blocks:    65534
APNIC Region origin ASes present in the Internet Routing Table:    5145
    APNIC Prefixes per ASN:                                       31.21
APNIC Region origin ASes announcing only one prefix:               1180
APNIC Region transit ASes present in the Internet Routing Table:    909
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         35
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1945
Number of APNIC addresses announced to Internet:              752726596
    Equivalent to 44 /8s, 221 /16s and 178 /24s
    Percentage of available APNIC address space announced:         88.0

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:                    179920
    Total ARIN prefixes after maximum aggregation:                88981
    ARIN Deaggregation factor:                                     2.02
Prefixes being announced from the ARIN address blocks:           184947
    Unique aggregates announced from the ARIN address blocks:     87842
ARIN Region origin ASes present in the Internet Routing Table:    16404
    ARIN Prefixes per ASN:                                        11.27
ARIN Region origin ASes announcing only one prefix:                5887
ARIN Region transit ASes present in the Internet Routing Table:    1716
Average ARIN Region AS path length visible:                         3.8
    Max ARIN Region AS path length visible:                          37
Number of ARIN region 32-bit ASNs visible in the Routing Table:    1089
Number of ARIN addresses announced to Internet:              1101648192
    Equivalent to 65 /8s, 169 /16s and 209 /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:                    141408
    Total RIPE prefixes after maximum aggregation:                69947
    RIPE Deaggregation factor:                                     2.02
Prefixes being announced from the RIPE address blocks:           149984
    Unique aggregates announced from the RIPE address blocks:     92642
RIPE Region origin ASes present in the Internet Routing Table:    18070
    RIPE Prefixes per ASN:                                         8.30
RIPE Region origin ASes announcing only one prefix:                7924
RIPE Region transit ASes present in the Internet Routing Table:    2990
Average RIPE Region AS path length visible:                         4.3
    Max RIPE Region AS path length visible:                          27
Number of RIPE region 32-bit ASNs visible in the Routing Table:    4592
Number of RIPE addresses announced to Internet:               704189824
    Equivalent to 41 /8s, 249 /16s and 21 /24s
    Percentage of available RIPE address space announced:         102.4

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:                   61729
    Total LACNIC prefixes after maximum aggregation:              12154
    LACNIC Deaggregation factor:                                   5.08
Prefixes being announced from the LACNIC address blocks:          75724
    Unique aggregates announced from the LACNIC address blocks:   35785
LACNIC Region origin ASes present in the Internet Routing Table:   2472
    LACNIC Prefixes per ASN:                                      30.63
LACNIC Region origin ASes announcing only one prefix:               582
LACNIC Region transit ASes present in the Internet Routing Table:   555
Average LACNIC Region AS path length visible:                       4.7
    Max LACNIC Region AS path length visible:                        22
Number of LACNIC region 32-bit ASNs visible in the Routing Table:  2382
Number of LACNIC addresses announced to Internet:             171034112
    Equivalent to 10 /8s, 49 /16s and 198 /24s
    Percentage of available LACNIC address space announced:       101.9

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:                  14146
    Total AfriNIC prefixes after maximum aggregation:              3185
    AfriNIC Deaggregation factor:                                  4.44
Prefixes being announced from the AfriNIC address blocks:         15929
    Unique aggregates announced from the AfriNIC address blocks:   5656
AfriNIC Region origin ASes present in the Internet Routing Table:   732
    AfriNIC Prefixes per ASN:                                     21.76
AfriNIC Region origin ASes announcing only one prefix:              180
AfriNIC Region transit ASes present in the Internet Routing Table:  166
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       18
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:  194
Number of AfriNIC addresses announced to Internet:             77962752
    Equivalent to 4 /8s, 165 /16s and 158 /24s
    Percentage of available AfriNIC address space announced:       77.4

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4538     5594       4192          76   China Education and Research 
 7545     3211        352         187   TPG Telecom Limited
 4766     3146      11142        1117   Korea Telecom
17974     2917        914          96   PT Telekomunikasi Indonesia
 9829     2395       1448         427   National Internet Backbone
 4755     2099        432         245   TATA Communications formerly 
 9808     1858       8717          30   Guangdong Mobile Communicatio
 4808     1641       2288         524   CNCGROUP IP network China169 
 4788     1527        645          62   TM Net, Internet Service Prov
 9583     1519        121         564   Sify Limited

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     3347       2948         145   Cox Communications Inc.
 6389     2357       3687          42   BellSouth.net Inc.
18566     2209        394         275   MegaPath Corporation
20115     1921       1931         400   Charter Communications
30036     1723        341         282   Mediacom Communications Corp
 6983     1689        849         231   EarthLink, Inc.
 4323     1573       1004         386   tw telecom holdings, inc.
  209     1549       4635        1232   Qwest Communications Company,
  701     1387      11446         663   MCI Communications Services, 
11492     1277        236         589   CABLE ONE, INC.

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     2515        135           9   SaudiNet, Saudi Telecom Compa
20940     2395        919        1741   Akamai International B.V.
34984     1960        323         414   TELLCOM ILETISIM HIZMETLERI A
 8551     1260        376          54   Bezeq International-Ltd
 6849     1158        355          21   JSC "Ukrtelecom"
12479     1147        980          86   France Telecom Espana SA
 8402     1131        544          15   OJSC "Vimpelcom"
13188     1077         98          78   TOV "Bank-Inform"
31148     1040         47          41   Freenet Ltd.
 9198      921        352          25   JSC Kazakhtelecom

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     3439        540         160   Telmex Colombia S.A.
 8151     2211       3418         541   Uninet S.A. de C.V.
 7303     1522        940         245   Telecom Argentina S.A.
11830     1441        366          25   Instituto Costarricense de El
 6503     1432        453          56   Axtel, S.A.B. de C.V.
 6147     1041        377          27   Telefonica del Peru S.A.A.
26615      995       2325          34   Tim Celular S.A.
 3816      994        478         185   COLOMBIA TELECOMUNICACIONES S
 7738      992       1882          41   Telemar Norte Leste S.A.
28573      892       2171         158   NET Servi?os de Comunica??o S

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     1240        403          36   Link Egypt (Link.NET)
 8452      668       1472          15   TE-AS
37611      646         48           2   Afrihost-Brevis Computer Serv
36903      584        294         104   Office National des Postes et
36992      506       1357          25   ETISALAT MISR
37492      380        233          65   Orange Tunisie
24835      339        146          12   Vodafone Data
29571      278         37          12   Cote d'Ivoire Telecom
 2018      250        327          74   TENET (The UNINET Project)
36947      232        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
 4538     5594       4192          76   China Education and Research 
10620     3439        540         160   Telmex Colombia S.A.
22773     3347       2948         145   Cox Communications Inc.
 7545     3211        352         187   TPG Telecom Limited
 4766     3146      11142        1117   Korea Telecom
17974     2917        914          96   PT Telekomunikasi Indonesia
39891     2515        135           9   SaudiNet, Saudi Telecom Compa
 9829     2395       1448         427   National Internet Backbone
20940     2395        919        1741   Akamai International B.V.
 6389     2357       3687          42   BellSouth.net Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
10620      3439        3279      Telmex Colombia S.A.
22773      3347        3202      Cox Communications Inc.
 7545      3211        3024      TPG Telecom Limited
17974      2917        2821      PT Telekomunikasi Indonesia
39891      2515        2506      SaudiNet, Saudi Telecom Compa
 6389      2357        2315      BellSouth.net Inc.
 4766      3146        2029      Korea Telecom
 9829      2395        1968      National Internet Backbone
18566      2209        1934      MegaPath Corporation
 4755      2099        1854      TATA Communications formerly 

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
46467   UNALLOCATED  8.19.192.0/24        46887       Lightower Fiber Netw
16589   UNALLOCATED  8.20.247.0/24        35838       CCANET Limited
16589   UNALLOCATED  8.26.56.0/24         35838       CCANET Limited
46473   UNALLOCATED  8.27.122.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.124.0/24         3356       Level 3 Communicatio
27205   UNALLOCATED  8.38.16.0/21          3356       Level 3 Communicatio
15347   UNALLOCATED  8.224.147.0/24       12064       Cox Communications I
33628   UNALLOCATED  12.0.239.0/24         1239       Sprint

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
23.226.112.0/20      62788     >>UNKNOWN<<
23.249.144.0/20      40430     colo4jax, LLC
27.100.7.0/24        56096     >>UNKNOWN<<
37.46.10.0/23        36351     SoftLayer Technologies Inc.
37.46.14.0/24        36351     SoftLayer Technologies Inc.
37.46.15.0/24        36351     SoftLayer Technologies Inc.
41.73.1.0/24         37004     >>UNKNOWN<<
41.73.2.0/24         37004     >>UNKNOWN<<
41.73.3.0/24         37004     >>UNKNOWN<<
41.73.4.0/24         37004     >>UNKNOWN<<

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:16       /9:13      /10:36      /11:101     /12:267     
/13:513     /14:1032    /15:1768    /16:12975   /17:7578    /18:12696   
/19:25816   /20:38153   /21:40031   /22:64976   /23:56380   /24:323558  
/25:543     /26:593     /27:398     /28:20      /29:17      /30:11      
/31:0       /32:24      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
22773     2526          3347      Cox Communications Inc.
39891     2472          2515      SaudiNet, Saudi Telecom Compa
18566     2111          2209      MegaPath Corporation
30036     1537          1723      Mediacom Communications Corp
 6389     1499          2357      BellSouth.net Inc.
 6983     1338          1689      EarthLink, Inc.
10620     1332          3439      Telmex Colombia S.A.
34984     1245          1960      TELLCOM ILETISIM HIZMETLERI A
11492     1183          1277      CABLE ONE, INC.
 6849      976          1158      JSC "Ukrtelecom"

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:1645      2:738       4:20        5:2052      6:27        8:927    
  12:1776     13:38       14:1649     15:45       16:2        17:74     
  18:20       20:49       23:1429     24:1775     27:2273     31:1761   
  32:54       33:2        34:2        35:5        36:256      37:2242   
  38:1179     39:27       40:87       41:2773     42:387      43:1691   
  44:41       45:1761     46:2468     47:73       49:1131     50:839    
  51:8        52:142      54:198      55:3        56:6        57:45     
  58:1528     59:859      60:570      61:1819     62:1483     63:1908   
  64:4471     65:2165     66:4188     67:2131     68:1101     69:3264   
  70:1046     71:469      72:1977     74:2550     75:339      76:414    
  77:1336     78:1304     79:849      80:1331     81:1363     82:939    
  83:685      84:805      85:1591     86:468      87:1022     88:561    
  89:1949     90:168      91:6050     92:850      93:2302     94:2353   
  95:2275     96:462      97:355      98:955      99:45      100:70     
 101:1025    103:10098   104:2331    105:152     106:400     107:1071   
 108:672     109:2133    110:1267    111:1641    112:955     113:1136   
 114:1040    115:1693    116:1541    117:1419    118:2153    119:1572   
 120:515     121:1174    122:2220    123:2004    124:1618    125:1753   
 128:722     129:380     130:411     131:1302    132:619     133:177    
 134:448     135:122     136:353     137:332     138:1726    139:213    
 140:251     141:470     142:636     143:862     144:601     145:161    
 146:843     147:645     148:1471    149:479     150:652     151:826    
 152:606     153:272     154:545     155:946     156:489     157:447    
 158:346     159:1100    160:437     161:737     162:2303    163:548    
 164:749     165:1039    166:313     167:1089    168:1635    169:626    
 170:1577    171:271     172:525     173:1676    174:720     175:919    
 176:1533    177:3998    178:2241    179:1109    180:2049    181:1703   
 182:1950    183:680     184:793     185:6044    186:3059    187:2090   
 188:2149    189:1747    190:7667    191:1201    192:8930    193:5724   
 194:4369    195:3774    196:1695    197:1070    198:5518    199:5645   
 200:6956    201:3704    202:10149   203:9629    204:4648    205:2713   
 206:2980    207:3064    208:4053    209:3795    210:3951    211:2039   
 212:2635    213:2182    214:832     215:72      216:5738    217:1920   
 218:761     219:568     220:1674    221:855     222:662     223:950    


End of report

From mansaxel at besserwisser.org  Fri Mar 25 19:54:48 2016
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Fri, 25 Mar 2016 20:54:48 +0100
Subject: Top-shelf resilience (Re: Why the US Government has so many data
 centers)
In-Reply-To: <379019868.7687.1458676764070.JavaMail.zimbra@baylink.com>
References: <alpine.BSF.2.20.1603111156590.46772@cnex.qbaryna.pbz>
 <alpine.BSF.2.20.1603132111330.72475@cnex.qbaryna.pbz>
 <CAD8GWsu3Rh-XiOaZugWmKNiMzRH0gex=eMTfRYGuPRQhWVFZmQ@mail.gmail.com>
 <alpine.BSF.2.20.1603141112290.75392@cnex.qbaryna.pbz>
 <CAD8GWssg3gGf6JzZJ=mmSdC6tAm7rJ34BDCnn=PT9oJAL=fTHQ@mail.gmail.com>
 <CANjVB-hX3sGfDO+hq0YamjmJVCPHFf6zbkDk5acBJgO_oNvBJg@mail.gmail.com>
 <3B1CC2C8-560A-4D02-8AED-3CE8180EC7FA@n5tech.com>
 <C56B4D6A-F03B-42CE-9EF9-54563547CB44@gmail.com>
 <379019868.7687.1458676764070.JavaMail.zimbra@baylink.com>
Message-ID: <20160325195448.GC4287@besserwisser.org>

Subject: Top-shelf resilience (Re: Why the US Government has so many data centers) Date: Tue, Mar 22, 2016 at 07:59:24PM +0000 Quoting Jay R. Ashworth (jra at baylink.com):
> 
> This seems like a good time to mention my favorite example of such a thing.
> 
> In the Navy, originally, and it ended up in a few other places, there was
> invented the concept of a 'battleshort', or 'battleshunt', depending on whom 
> you're talking to.

I've built one, sort of. In an outdoor broadcasting vehicle. See, in
order to get a working grounding scheme, the PDU in the bus gets to serve
as power source for a lot of things that might find themselves outside,
in climate. 200VDC feeds in triaxial cables to cameras, for instance.
(this was before cameras were connected with singlemode fiber, but
after the era of the multicore "shower handle" connectors) All this
was of course built for some exposure to the elements but not for
drenching. During setup, it was decided to protect people with a GFCI
breaker on the main three-phase bus in the bus[0][1], but once setup,
people were not really supposed to gefingerpoken the thingamaboobs, so
in the interest of reliability a bypass was created for the GFCI breaker.
This had to be built in-house, since no electrical contractor even wanted
to contemplate it. So we did.

/M?ns, ex-builder of analog broadcast facilities. 
-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
First, I'm going to give you all the ANSWERS to today's test ...  So
just plug in your SONY WALKMANS and relax!!

[0] Pun not intended but carefully kept once discovered. 

[1] This is (continental) Europe, where we are not afraid of 405VAC
    three-phase mains. Tesla was European. Edison was born to American 
    parents. 
-------------- 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/20160325/3033dffa/attachment.pgp>

From mel at beckman.org  Sat Mar 26 04:43:02 2016
From: mel at beckman.org (Mel Beckman)
Date: Sat, 26 Mar 2016 04:43:02 +0000
Subject: ARIN down?
Message-ID: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>

I haven?t been able to connect to http://arin.net for several hours, but was able to open a ticket this morning. I?ve tried from several different networks, all roads seem to lead to the same place, with packets dropping at the NTT interface 129.250.196.154. e.g.:

$ traceroute arin.net<http://arin.net>
traceroute: Warning: arin.net<http://arin.net> has multiple addresses; using 199.43.0.44
traceroute to arin.net<http://arin.net> (199.43.0.44), 64 hops max, 52 byte packets
 1  l100.lsanca-vfttp-106.verizon-gni.net<http://l100.lsanca-vfttp-106.verizon-gni.net> (98.112.74.1)  5.992 ms  4.865 ms  4.943 ms
 2  172.102.106.24 (172.102.106.24)  9.962 ms  9.723 ms  12.242 ms
 3  ae2-0.lax01-bb-rtr2.verizon-gni.net<http://ae2-0.lax01-bb-rtr2.verizon-gni.net> (130.81.22.238)  29.982 ms *
    so-4-1-0-0.lax01-bb-rtr2.verizon-gni.net<http://so-4-1-0-0.lax01-bb-rtr2.verizon-gni.net> (130.81.151.248)  9.428 ms
 4  0.ae6.br1.lax15.alter.net<http://ae6.br1.lax15.alter.net> (140.222.225.137)  9.806 ms * *
 5  ae-7.r01.lsanca20.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.8.85)  10.409 ms
    0.ae6.br1.lax15.alter.net<http://ae6.br1.lax15.alter.net> (140.222.225.137)  19.783 ms  9.757 ms
 6  ae-7.r01.lsanca20.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.8.85)  10.292 ms  9.357 ms  12.291 ms
 7  ae-17.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.4.207)  22.541 ms
    ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  72.412 ms
    ae-17.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.4.207)  22.167 ms
 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  72.510 ms  74.590 ms  72.258 ms
 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net<http://us.ce.gin.ntt.net> (129.250.196.154)  69.960 ms *  70.930 ms
10  * * *
11  * * *

$ traceroute www.arin.net<http://www.arin.net>
traceroute: Warning: www.arin.net<http://www.arin.net> has multiple addresses; using 199.43.0.43
traceroute to www.arin.net<http://www.arin.net> (199.43.0.43), 64 hops max, 40 byte packets
 1  router1.sb.becknet.com<http://router1.sb.becknet.com> (206.83.0.1)  1.010 ms  0.420 ms  0.536 ms
 2  206-190-77-9.static.twtelecom.net<http://206-190-77-9.static.twtelecom.net> (206.190.77.9)  3.983 ms  0.732 ms  0.686 ms
 3  64-129-238-182.static.twtelecom.net<http://64-129-238-182.static.twtelecom.net> (64.129.238.182)  2.760 ms lax2-pr2-xe-1-3-0-0.us.twtelecom.net<http://lax2-pr2-xe-1-3-0-0.us.twtelecom.net> (66.192.241.218)  2.816 ms 64-129-238-186.static.twtelecom.net<http://64-129-238-186.static.twtelecom.net> (64.129.238.186)  18.203 ms
 4  4.68.71.137 (4.68.71.137)  3.245 ms  2.877 ms  2.889 ms
 5  * * *
 6  ae-28.r00.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.9.93)  3.731 ms  3.483 ms  3.850 ms
 7  ae-3.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.5.29)  3.517 ms  3.433 ms  3.458 ms
 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  69.503 ms  68.021 ms  68.072 ms
 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net<http://us.ce.gin.ntt.net> (129.250.196.154)  67.075 ms  67.102 ms  67.122 ms
10  * * *
11  * * *

I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?

 -mel

From luca at digitalocean.com  Wed Mar 23 22:28:49 2016
From: luca at digitalocean.com (Luca Salvatore)
Date: Wed, 23 Mar 2016 18:28:49 -0400
Subject: mrtg alternative
In-Reply-To: <CAJ0+aXbbRM=Punaq1xTUnnN+yz2TanTiQ9nHqjrN_YkbzkBXKw@mail.gmail.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
 <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
 <B8C72973-4CDC-400D-B169-731A7E5AC621@lboro.ac.uk>
 <CAJ0+aXbbRM=Punaq1xTUnnN+yz2TanTiQ9nHqjrN_YkbzkBXKw@mail.gmail.com>
Message-ID: <CANjEN-Es0karKQ-1SnmuTHX0MXo9jbFfDOiZewZf_YRKEodF0Q@mail.gmail.com>

Look into AKiPS.. Some of the guys from Statseeker made it better :-)

On Wed, Mar 23, 2016 at 5:22 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> +1 for Cacti.
>
>
> I tried zenoss & observium but still Cacti is more cool in terms of
> tweaking templates as well as the tree mode for easy quick representation.
>
>
>
> Thanks for starting this cool thread. Will help in getting links to some of
> other cool projects which we don't hear around.
>
> On Wed, Mar 23, 2016 at 10:36 PM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
> wrote:
>
> > +1 for Statseeker. Ease of use etc (price depends on eg site size etc).
> > Can do lots on just one mid server unlike some other bloaty solutions out
> > there.  But we also still use MRTG for some local bespoke measurements
> >
> > PS you can get a free Eval of statseeker. Obnote, don't work for them
> just
> > a fairly happy customer
> >
> > alan
> >
>
>
>
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>



-- 
Luca Salvatore
Manager, Network Team | DigitalOcean
Phone: +1 (929) 214-7242

From Brandon.Vincent at asu.edu  Thu Mar 24 08:20:54 2016
From: Brandon.Vincent at asu.edu (Brandon Vincent)
Date: Thu, 24 Mar 2016 01:20:54 -0700
Subject: Cogent Communications
Message-ID: <CAJm4239Qr0PBgeQuH+k2bxz18jLW9KAsxFJO001qVaeT0cpH3A@mail.gmail.com>

Does anyone have a NOC/SOC contact for Cogent? I found a improperly
secured router on the Internet and I'd like to report it.

Thank you,
Brandon Vincent

From Bryan.Bradsby at capnet.state.tx.us  Fri Mar 25 14:39:07 2016
From: Bryan.Bradsby at capnet.state.tx.us (Bryan Bradsby)
Date: Fri, 25 Mar 2016 09:39:07 -0500
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <033701d18394$07e01720$17a04560$@gmail.com>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
 <033701d18394$07e01720$17a04560$@gmail.com>
Message-ID: <1458916747.2444.57.camel@capnet.state.tx.us>

> Uggghhh.  I've always hated this 'reboot, see if it fixes it' 
> methodology.  If the CPEs can't recover from error conditions 
> correctly, they shouldn't be used.  I blame Microsoft for making this 
> concept acceptable.  
> 
> Chuck

I was getting 20% TCP packet loss between two of my unix boxes on the
TWC route from my house to work, so I called support. 

I used lft - like tcptraceroute - both directions, to identify a TWC
backbone router in Dallas as the problem. I then used the TWC looking
glass to show the same result. 

I was told i needed to reboot my router to troubleshoot. I offered to
reboot my router, after he rebooted his router in Dallas  ;)

-bryan

From drc at virtualized.org  Sat Mar 26 04:46:20 2016
From: drc at virtualized.org (David Conrad)
Date: Fri, 25 Mar 2016 21:46:20 -0700
Subject: ARIN down?
In-Reply-To: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
Message-ID: <E51484B9-2708-4D8E-94CD-B86D2E3BC7A6@virtualized.org>

Yep, they're under another DDoS attack:

> Begin forwarded message:
> 
> From: ARIN <info at arin.net>
> Subject: [arin-announce] ARIN DDoS Attack
> Date: March 25, 2016 at 1:31:34 PM PDT
> To: arin-announce at arin.net
> 
> Starting at 3:55 PM EDT on Friday, 25 March, a DDoS attack began against ARIN. This was and continues to be a sustained attack against our provisioning services, email, and website. We initiated our DDoS mitigation plan and are in the process of mitigating various types of attack traffic patterns. All our other public-facing services (Whois, Whois-RWS, RDAP, DNS, IRR, and RPKI repository services) are not affected by this attack and are operating normally.
> 
> We will announce an all clear 24 hours after the attacks have stopped.
> 
> Regards,
> 
> Mark Kosters
> Chief Technology Officer
> American Registry for Internet Numbers (ARIN)
> _______________________________________________


Regards,
-drc

> On Mar 25, 2016, at 9:43 PM, Mel Beckman <mel at beckman.org> wrote:
> 
> I haven?t been able to connect to http://arin.net for several hours, but was able to open a ticket this morning. I?ve tried from several different networks, all roads seem to lead to the same place, with packets dropping at the NTT interface 129.250.196.154. e.g.:
> 
> $ traceroute arin.net<http://arin.net>
> traceroute: Warning: arin.net<http://arin.net> has multiple addresses; using 199.43.0.44
> traceroute to arin.net<http://arin.net> (199.43.0.44), 64 hops max, 52 byte packets
> 1  l100.lsanca-vfttp-106.verizon-gni.net<http://l100.lsanca-vfttp-106.verizon-gni.net> (98.112.74.1)  5.992 ms  4.865 ms  4.943 ms
> 2  172.102.106.24 (172.102.106.24)  9.962 ms  9.723 ms  12.242 ms
> 3  ae2-0.lax01-bb-rtr2.verizon-gni.net<http://ae2-0.lax01-bb-rtr2.verizon-gni.net> (130.81.22.238)  29.982 ms *
>    so-4-1-0-0.lax01-bb-rtr2.verizon-gni.net<http://so-4-1-0-0.lax01-bb-rtr2.verizon-gni.net> (130.81.151.248)  9.428 ms
> 4  0.ae6.br1.lax15.alter.net<http://ae6.br1.lax15.alter.net> (140.222.225.137)  9.806 ms * *
> 5  ae-7.r01.lsanca20.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.8.85)  10.409 ms
>    0.ae6.br1.lax15.alter.net<http://ae6.br1.lax15.alter.net> (140.222.225.137)  19.783 ms  9.757 ms
> 6  ae-7.r01.lsanca20.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.8.85)  10.292 ms  9.357 ms  12.291 ms
> 7  ae-17.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.4.207)  22.541 ms
>    ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  72.412 ms
>    ae-17.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.4.207)  22.167 ms
> 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  72.510 ms  74.590 ms  72.258 ms
> 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net<http://us.ce.gin.ntt.net> (129.250.196.154)  69.960 ms *  70.930 ms
> 10  * * *
> 11  * * *
> 
> $ traceroute www.arin.net<http://www.arin.net>
> traceroute: Warning: www.arin.net<http://www.arin.net> has multiple addresses; using 199.43.0.43
> traceroute to www.arin.net<http://www.arin.net> (199.43.0.43), 64 hops max, 40 byte packets
> 1  router1.sb.becknet.com<http://router1.sb.becknet.com> (206.83.0.1)  1.010 ms  0.420 ms  0.536 ms
> 2  206-190-77-9.static.twtelecom.net<http://206-190-77-9.static.twtelecom.net> (206.190.77.9)  3.983 ms  0.732 ms  0.686 ms
> 3  64-129-238-182.static.twtelecom.net<http://64-129-238-182.static.twtelecom.net> (64.129.238.182)  2.760 ms lax2-pr2-xe-1-3-0-0.us.twtelecom.net<http://lax2-pr2-xe-1-3-0-0.us.twtelecom.net> (66.192.241.218)  2.816 ms 64-129-238-186.static.twtelecom.net<http://64-129-238-186.static.twtelecom.net> (64.129.238.186)  18.203 ms
> 4  4.68.71.137 (4.68.71.137)  3.245 ms  2.877 ms  2.889 ms
> 5  * * *
> 6  ae-28.r00.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.9.93)  3.731 ms  3.483 ms  3.850 ms
> 7  ae-3.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.5.29)  3.517 ms  3.433 ms  3.458 ms
> 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  69.503 ms  68.021 ms  68.072 ms
> 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net<http://us.ce.gin.ntt.net> (129.250.196.154)  67.075 ms  67.102 ms  67.122 ms
> 10  * * *
> 11  * * *
> 
> I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?
> 
> -mel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160325/702d60f7/attachment.pgp>

From mel at beckman.org  Sat Mar 26 04:51:36 2016
From: mel at beckman.org (Mel Beckman)
Date: Sat, 26 Mar 2016 04:51:36 +0000
Subject: ARIN down?
In-Reply-To: <E51484B9-2708-4D8E-94CD-B86D2E3BC7A6@virtualized.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <E51484B9-2708-4D8E-94CD-B86D2E3BC7A6@virtualized.org>
Message-ID: <FD23A5C5-53C1-4C05-88B6-1BFA876CBE00@beckman.org>

You?d think with all the money they collect, they?d have permanent DDOS mitigation in place. Time for them to call BlackLotus :)

 -mel

> On Mar 25, 2016, at 9:46 PM, David Conrad <drc at virtualized.org> wrote:
> 
> Yep, they're under another DDoS attack:
> 
>> Begin forwarded message:
>> 
>> From: ARIN <info at arin.net>
>> Subject: [arin-announce] ARIN DDoS Attack
>> Date: March 25, 2016 at 1:31:34 PM PDT
>> To: arin-announce at arin.net
>> 
>> Starting at 3:55 PM EDT on Friday, 25 March, a DDoS attack began against ARIN. This was and continues to be a sustained attack against our provisioning services, email, and website. We initiated our DDoS mitigation plan and are in the process of mitigating various types of attack traffic patterns. All our other public-facing services (Whois, Whois-RWS, RDAP, DNS, IRR, and RPKI repository services) are not affected by this attack and are operating normally.
>> 
>> We will announce an all clear 24 hours after the attacks have stopped.
>> 
>> Regards,
>> 
>> Mark Kosters
>> Chief Technology Officer
>> American Registry for Internet Numbers (ARIN)
>> _______________________________________________
> 
> 
> Regards,
> -drc
> 
>> On Mar 25, 2016, at 9:43 PM, Mel Beckman <mel at beckman.org> wrote:
>> 
>> I haven?t been able to connect to http://arin.net for several hours, but was able to open a ticket this morning. I?ve tried from several different networks, all roads seem to lead to the same place, with packets dropping at the NTT interface 129.250.196.154. e.g.:
>> 
>> $ traceroute arin.net<http://arin.net>
>> traceroute: Warning: arin.net<http://arin.net> has multiple addresses; using 199.43.0.44
>> traceroute to arin.net<http://arin.net> (199.43.0.44), 64 hops max, 52 byte packets
>> 1  l100.lsanca-vfttp-106.verizon-gni.net<http://l100.lsanca-vfttp-106.verizon-gni.net> (98.112.74.1)  5.992 ms  4.865 ms  4.943 ms
>> 2  172.102.106.24 (172.102.106.24)  9.962 ms  9.723 ms  12.242 ms
>> 3  ae2-0.lax01-bb-rtr2.verizon-gni.net<http://ae2-0.lax01-bb-rtr2.verizon-gni.net> (130.81.22.238)  29.982 ms *
>>   so-4-1-0-0.lax01-bb-rtr2.verizon-gni.net<http://so-4-1-0-0.lax01-bb-rtr2.verizon-gni.net> (130.81.151.248)  9.428 ms
>> 4  0.ae6.br1.lax15.alter.net<http://ae6.br1.lax15.alter.net> (140.222.225.137)  9.806 ms * *
>> 5  ae-7.r01.lsanca20.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.8.85)  10.409 ms
>>   0.ae6.br1.lax15.alter.net<http://ae6.br1.lax15.alter.net> (140.222.225.137)  19.783 ms  9.757 ms
>> 6  ae-7.r01.lsanca20.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.8.85)  10.292 ms  9.357 ms  12.291 ms
>> 7  ae-17.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.4.207)  22.541 ms
>>   ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  72.412 ms
>>   ae-17.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.4.207)  22.167 ms
>> 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  72.510 ms  74.590 ms  72.258 ms
>> 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net<http://us.ce.gin.ntt.net> (129.250.196.154)  69.960 ms *  70.930 ms
>> 10  * * *
>> 11  * * *
>> 
>> $ traceroute www.arin.net<http://www.arin.net>
>> traceroute: Warning: www.arin.net<http://www.arin.net> has multiple addresses; using 199.43.0.43
>> traceroute to www.arin.net<http://www.arin.net> (199.43.0.43), 64 hops max, 40 byte packets
>> 1  router1.sb.becknet.com<http://router1.sb.becknet.com> (206.83.0.1)  1.010 ms  0.420 ms  0.536 ms
>> 2  206-190-77-9.static.twtelecom.net<http://206-190-77-9.static.twtelecom.net> (206.190.77.9)  3.983 ms  0.732 ms  0.686 ms
>> 3  64-129-238-182.static.twtelecom.net<http://64-129-238-182.static.twtelecom.net> (64.129.238.182)  2.760 ms lax2-pr2-xe-1-3-0-0.us.twtelecom.net<http://lax2-pr2-xe-1-3-0-0.us.twtelecom.net> (66.192.241.218)  2.816 ms 64-129-238-186.static.twtelecom.net<http://64-129-238-186.static.twtelecom.net> (64.129.238.186)  18.203 ms
>> 4  4.68.71.137 (4.68.71.137)  3.245 ms  2.877 ms  2.889 ms
>> 5  * * *
>> 6  ae-28.r00.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.9.93)  3.731 ms  3.483 ms  3.850 ms
>> 7  ae-3.r01.lsanca07.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.5.29)  3.517 ms  3.433 ms  3.458 ms
>> 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net<http://us.bb.gin.ntt.net> (129.250.196.153)  69.503 ms  68.021 ms  68.072 ms
>> 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net<http://us.ce.gin.ntt.net> (129.250.196.154)  67.075 ms  67.102 ms  67.122 ms
>> 10  * * *
>> 11  * * *
>> 
>> I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?
>> 
>> -mel
> 


From jason at unlimitednet.us  Sat Mar 26 04:51:39 2016
From: jason at unlimitednet.us (Jason Canady)
Date: Sat, 26 Mar 2016 00:51:39 -0400
Subject: Cogent Communications
In-Reply-To: <CAJm4239Qr0PBgeQuH+k2bxz18jLW9KAsxFJO001qVaeT0cpH3A@mail.gmail.com>
References: <CAJm4239Qr0PBgeQuH+k2bxz18jLW9KAsxFJO001qVaeT0cpH3A@mail.gmail.com>
Message-ID: <56F6155B.8060202@unlimitednet.us>

As a Cogent customer, I'm sure I can get you in touch with someone. Have 
you tried emailing support at cogentco.com ?  If not, email me off list and 
I'll find someone you can speak to.

- Jason

On 3/24/16 4:20 AM, Brandon Vincent wrote:
> Does anyone have a NOC/SOC contact for Cogent? I found a improperly
> secured router on the Internet and I'd like to report it.
>
> Thank you,
> Brandon Vincent


From dcorbe at hammerfiber.com  Sat Mar 26 04:51:42 2016
From: dcorbe at hammerfiber.com (Daniel Corbe)
Date: Sat, 26 Mar 2016 00:51:42 -0400
Subject: ARIN down?
In-Reply-To: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
Message-ID: <437EFD13-5D62-475E-A323-A4655C68A1CF@hammerfiber.com>


> On Mar 26, 2016, at 12:43 AM, Mel Beckman <mel at beckman.org> wrote:
> 
> I haven?t been able to connect to http://arin.net for several hours, but was able to open a ticket this morning. I?ve tried from several different networks, all roads seem to lead to the same place, with packets dropping at the NTT interface 129.250.196.154. e.g.:
> 
> ...
> 
> I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?
> 
> -mel

An announcement went out on arin-announce yesterday (but you might not be able to follow the link if you can?t reach list.arin.net):

http://lists.arin.net/pipermail/arin-announce/2016-March/001963.html

tl;dr: Massive DDoS.  Usual affair.  Welcome to the Internet.


From mel at beckman.org  Sat Mar 26 04:55:07 2016
From: mel at beckman.org (Mel Beckman)
Date: Sat, 26 Mar 2016 04:55:07 +0000
Subject: mrtg alternative
In-Reply-To: <CANjEN-Es0karKQ-1SnmuTHX0MXo9jbFfDOiZewZf_YRKEodF0Q@mail.gmail.com>
References: <CAPkb-7BoUh=Lt7=om-WavuwpEGktkabDX+m=g+M-DK2tO-aGew@mail.gmail.com>
 <CAD4ZOMwMuJgnYDzshSi0_KdPmWLu4gjG6ZyLOH2YS2ibc4FBNA@mail.gmail.com>
 <EDF9CEDA-D241-48ED-ABD8-9A76878D56D1@standingwave.org>
 <E3B481FC-0750-4825-B2E0-723AAEA1B9DD@infusionsoft.com>
 <CAOvEG7M7jK8+n_JCq1cNih7AanimXfRYpDfR40QDsMCAkkV2Mg@mail.gmail.com>
 <B8C72973-4CDC-400D-B169-731A7E5AC621@lboro.ac.uk>
 <CAJ0+aXbbRM=Punaq1xTUnnN+yz2TanTiQ9nHqjrN_YkbzkBXKw@mail.gmail.com>
 <CANjEN-Es0karKQ-1SnmuTHX0MXo9jbFfDOiZewZf_YRKEodF0Q@mail.gmail.com>
Message-ID: <054485C3-3A07-4CA6-931D-4747D3B36E2A@beckman.org>

"AKIPS continues to lead the market as the only network monitoring system to monitor SNMP, Ping, Syslog, Traps and Netflow, all at one low subscription price, independent of the size of your network ?

At $5K/year subscription starting price, I think my definition of ?low? differs from AKiPS :)

 -mel

On Mar 23, 2016, at 3:28 PM, Luca Salvatore via NANOG <nanog at nanog.org<mailto:nanog at nanog.org>> wrote:

Look into AKiPS.. Some of the guys from Statseeker made it better :-)

On Wed, Mar 23, 2016 at 5:22 PM, Anurag Bhatia <me at anuragbhatia.com<mailto:me at anuragbhatia.com>> wrote:

+1 for Cacti.


I tried zenoss & observium but still Cacti is more cool in terms of
tweaking templates as well as the tree mode for easy quick representation.



Thanks for starting this cool thread. Will help in getting links to some of
other cool projects which we don't hear around.

On Wed, Mar 23, 2016 at 10:36 PM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk<mailto:A.L.M.Buxey at lboro.ac.uk>>
wrote:

+1 for Statseeker. Ease of use etc (price depends on eg site size etc).
Can do lots on just one mid server unlike some other bloaty solutions out
there.  But we also still use MRTG for some local bespoke measurements

PS you can get a free Eval of statseeker. Obnote, don't work for them
just
a fairly happy customer

alan




--


Anurag Bhatia
anuragbhatia.com<http://anuragbhatia.com>




--
Luca Salvatore
Manager, Network Team | DigitalOcean
Phone: +1 (929) 214-7242


From woody at pch.net  Sat Mar 26 04:57:00 2016
From: woody at pch.net (Bill Woodcock)
Date: Fri, 25 Mar 2016 21:57:00 -0700
Subject: ARIN down?
In-Reply-To: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
Message-ID: <4D182AB6-DF9F-4732-A343-673E4A62DE6A@pch.net>


> On Mar 25, 2016, at 9:43 PM, Mel Beckman <mel at beckman.org> wrote:
> 
> I haven?t been able to connect to http://arin.net for several hours
> I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?

Yes, it is.  I attach Mark?s notice about it from this afternoon.

                                -Bill



> Begin forwarded message:
> 
> From: ARIN <info at arin.net>
> Subject: [arin-announce] ARIN DDoS Attack
> Date: March 25, 2016 at 1:31:34 PM PDT
> To: arin-announce at arin.net
> 
> Starting at 3:55 PM EDT on Friday, 25 March, a DDoS attack began against ARIN. This was and continues to be a sustained attack against our provisioning services, email, and website. We initiated our DDoS mitigation plan and are in the process of mitigating various types of attack traffic patterns. All our other public-facing services (Whois, Whois-RWS, RDAP, DNS, IRR, and RPKI repository services) are not affected by this attack and are operating normally.
> 
> We will announce an all clear 24 hours after the attacks have stopped.
> 
> Regards,
> 
> Mark Kosters
> Chief Technology Officer
> American Registry for Internet Numbers (ARIN)
-------------- 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/20160325/14607f3c/attachment.pgp>

From mel at beckman.org  Sat Mar 26 04:58:59 2016
From: mel at beckman.org (Mel Beckman)
Date: Sat, 26 Mar 2016 04:58:59 +0000
Subject: ARIN down?
In-Reply-To: <437EFD13-5D62-475E-A323-A4655C68A1CF@hammerfiber.com>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <437EFD13-5D62-475E-A323-A4655C68A1CF@hammerfiber.com>
Message-ID: <5858F6BF-CC1D-413F-ACE5-5E9A16D26AC3@beckman.org>

Yeah, lists.arin.net<http://lists.arin.net> is down too, despite being hosted elsewhere. The netvermin apparently are being thorough. Still, there are many ways to broadly distribute static content like mailing lists.

 -mel

On Mar 25, 2016, at 9:51 PM, Daniel Corbe <dcorbe at hammerfiber.com<mailto:dcorbe at hammerfiber.com>> wrote:


On Mar 26, 2016, at 12:43 AM, Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>> wrote:

I haven?t been able to connect to http://arin.net for several hours, but was able to open a ticket this morning. I?ve tried from several different networks, all roads seem to lead to the same place, with packets dropping at the NTT interface 129.250.196.154. e.g.:

...

I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?

-mel

An announcement went out on arin-announce yesterday (but you might not be able to follow the link if you can?t reach list.arin.net<http://list.arin.net/>):

http://lists.arin.net/pipermail/arin-announce/2016-March/001963.html

tl;dr: Massive DDoS.  Usual affair.  Welcome to the Internet.


From mel at beckman.org  Sat Mar 26 05:08:07 2016
From: mel at beckman.org (Mel Beckman)
Date: Sat, 26 Mar 2016 05:08:07 +0000
Subject: ARIN down?
In-Reply-To: <4D182AB6-DF9F-4732-A343-673E4A62DE6A@pch.net>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <4D182AB6-DF9F-4732-A343-673E4A62DE6A@pch.net>
Message-ID: <358F1FD3-4B48-4136-BD19-C9066395B70A@beckman.org>

I?m sure we all sympathize with the workload a DDOS attack imposes, as most of us have been there. But I can?t understand why there is so little broadcast communication of the attack through multiple channels. lists.arin.net<http://lists.arin.net> is rather esoteric. Facebook and Twitter are obvious alternative channels that are hard to attack, yet both are silent on the subject:

https://www.facebook.com/TeamARIN/
https://twitter.com/teamarin

Google shows only four hits for ?arin dos attack march 25 2016?, and those are only fragments of the lists.arin.net<http://lists.arin.net> announcement, all of which dead end at arin.net<http://arin.net> right now.

It?s creepy that a major chunk of Internet infrastructure can be down for so long with so little public notice.

 -mel

On Mar 25, 2016, at 9:57 PM, Bill Woodcock <woody at pch.net<mailto:woody at pch.net>> wrote:


On Mar 25, 2016, at 9:43 PM, Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>> wrote:

I haven?t been able to connect to http://arin.net for several hours
I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?

Yes, it is.  I attach Mark?s notice about it from this afternoon.

                               -Bill



Begin forwarded message:

From: ARIN <info at arin.net<mailto:info at arin.net>>
Subject: [arin-announce] ARIN DDoS Attack
Date: March 25, 2016 at 1:31:34 PM PDT
To: arin-announce at arin.net<mailto:arin-announce at arin.net>

Starting at 3:55 PM EDT on Friday, 25 March, a DDoS attack began against ARIN. This was and continues to be a sustained attack against our provisioning services, email, and website. We initiated our DDoS mitigation plan and are in the process of mitigating various types of attack traffic patterns. All our other public-facing services (Whois, Whois-RWS, RDAP, DNS, IRR, and RPKI repository services) are not affected by this attack and are operating normally.

We will announce an all clear 24 hours after the attacks have stopped.

Regards,

Mark Kosters
Chief Technology Officer
American Registry for Internet Numbers (ARIN)


From bill at herrin.us  Sat Mar 26 05:09:15 2016
From: bill at herrin.us (William Herrin)
Date: Sat, 26 Mar 2016 01:09:15 -0400
Subject: ARIN down?
In-Reply-To: <FD23A5C5-53C1-4C05-88B6-1BFA876CBE00@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <E51484B9-2708-4D8E-94CD-B86D2E3BC7A6@virtualized.org>
 <FD23A5C5-53C1-4C05-88B6-1BFA876CBE00@beckman.org>
Message-ID: <CAP-guGUZcnbC3yO6-R8XKC8M6qHW0ZtMV3XoiREFVFeLuTmTDQ@mail.gmail.com>

On Sat, Mar 26, 2016 at 12:51 AM, Mel Beckman <mel at beckman.org> wrote:
> You?d think with all the money they collect, they?d have permanent DDOS mitigation in place. Time for them to call BlackLotus :)

Hi Mel,

They do. www.arin.net is accessible for me and most of the rest of the
Internet. Your traceroute didn't work because the UDP to random ports
that traceroute generates is likely among the packets the DDOS
mitigator filters out.

If you can't get to the web page with a browser, some things to consider:

1. Are you behind a NAT with anybody else? Anybody who might, say, be
unknowingly participating in a botnet?

2. How good a job does your ISP do scrubbing spoofed source addresses
originated by its clients?

Regards,
Bill Herrin

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

From woody at pch.net  Sat Mar 26 05:11:16 2016
From: woody at pch.net (Bill Woodcock)
Date: Fri, 25 Mar 2016 22:11:16 -0700
Subject: ARIN down?
In-Reply-To: <FD23A5C5-53C1-4C05-88B6-1BFA876CBE00@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <E51484B9-2708-4D8E-94CD-B86D2E3BC7A6@virtualized.org>
 <FD23A5C5-53C1-4C05-88B6-1BFA876CBE00@beckman.org>
Message-ID: <0F85503A-58CC-449E-AA44-7F79ECB19F1A@pch.net>


> On Mar 25, 2016, at 9:51 PM, Mel Beckman <mel at beckman.org> wrote:
> 
> You?d think with all the money they collect, they?d have permanent DDOS mitigation in place.

They do, and they?re using it.

                                -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/20160325/7caf7304/attachment.pgp>

From bill at herrin.us  Sat Mar 26 05:21:42 2016
From: bill at herrin.us (William Herrin)
Date: Sat, 26 Mar 2016 01:21:42 -0400
Subject: ARIN down?
In-Reply-To: <358F1FD3-4B48-4136-BD19-C9066395B70A@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <4D182AB6-DF9F-4732-A343-673E4A62DE6A@pch.net>
 <358F1FD3-4B48-4136-BD19-C9066395B70A@beckman.org>
Message-ID: <CAP-guGUEiON_4avC=iWdw6i-8fPuPyKcQt3LACDHccdcpBGnAg@mail.gmail.com>

On Sat, Mar 26, 2016 at 1:08 AM, Mel Beckman <mel at beckman.org> wrote:
> I?m sure we all sympathize with the workload a DDOS attack imposes,
> as most of us have been there. But I can?t understand why there is so
> little broadcast communication of the attack through multiple channels.

http://www.downforeveryoneorjustme.com/www.arin.net



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

From mel at beckman.org  Sat Mar 26 05:26:11 2016
From: mel at beckman.org (Mel Beckman)
Date: Sat, 26 Mar 2016 05:26:11 +0000
Subject: ARIN down?
In-Reply-To: <358F1FD3-4B48-4136-BD19-C9066395B70A@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <4D182AB6-DF9F-4732-A343-673E4A62DE6A@pch.net>
 <358F1FD3-4B48-4136-BD19-C9066395B70A@beckman.org>
Message-ID: <B84A117D-BD8B-4686-BA70-3E45B6C9B3D2@beckman.org>

William,

How did you determine that ARIN is accessible for ?most of the rest of the Internet??

I?ve tried accessing the web site from nine different networks: Cox, Comcast, Level3, Verizon, AT&T, CenturyLink, Frontier, Sprint and Cogent. None of them can reach it. I?ve used non-firewalled network monitors, as well as NAT?d devices. The DDoS attack seems to be blocking access from a large subset of U.S. ISPs. I am an ISP and we follow standard anti-IP spoofing practices, so at least my networks aren?t DDOS spoof sources.

 -mel

> On Mar 25, 2016, at 10:09 PM, William Herrin <bill at herrin.us> wrote:
> 
> On Sat, Mar 26, 2016 at 12:51 AM, Mel Beckman <mel at beckman.org> wrote:
>> You?d think with all the money they collect, they?d have permanent DDOS mitigation in place. Time for them to call BlackLotus :)
> 
> Hi Mel,
> 
> They do. www.arin.net is accessible for me and most of the rest of the
> Internet. Your traceroute didn't work because the UDP to random ports
> that traceroute generates is likely among the packets the DDOS
> mitigator filters out.
> 
> If you can't get to the web page with a browser, some things to consider:
> 
> 1. Are you behind a NAT with anybody else? Anybody who might, say, be
> unknowingly participating in a botnet?
> 
> 2. How good a job does your ISP do scrubbing spoofed source addresses
> originated by its clients?
> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>




> On Mar 25, 2016, at 10:08 PM, Mel Beckman <mel at beckman.org> wrote:
> 
> I?m sure we all sympathize with the workload a DDOS attack imposes, as most of us have been there. But I can?t understand why there is so little broadcast communication of the attack through multiple channels. lists.arin.net<http://lists.arin.net> is rather esoteric. Facebook and Twitter are obvious alternative channels that are hard to attack, yet both are silent on the subject:
> 
> https://www.facebook.com/TeamARIN/
> https://twitter.com/teamarin
> 
> Google shows only four hits for ?arin dos attack march 25 2016?, and those are only fragments of the lists.arin.net<http://lists.arin.net> announcement, all of which dead end at arin.net<http://arin.net> right now.
> 
> It?s creepy that a major chunk of Internet infrastructure can be down for so long with so little public notice.
> 
> -mel
> 
> On Mar 25, 2016, at 9:57 PM, Bill Woodcock <woody at pch.net<mailto:woody at pch.net>> wrote:
> 
> 
> On Mar 25, 2016, at 9:43 PM, Mel Beckman <mel at beckman.org<mailto:mel at beckman.org>> wrote:
> 
> I haven?t been able to connect to http://arin.net for several hours
> I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this is a recurrence?
> 
> Yes, it is.  I attach Mark?s notice about it from this afternoon.
> 
>                               -Bill
> 
> 
> 
> Begin forwarded message:
> 
> From: ARIN <info at arin.net<mailto:info at arin.net>>
> Subject: [arin-announce] ARIN DDoS Attack
> Date: March 25, 2016 at 1:31:34 PM PDT
> To: arin-announce at arin.net<mailto:arin-announce at arin.net>
> 
> Starting at 3:55 PM EDT on Friday, 25 March, a DDoS attack began against ARIN. This was and continues to be a sustained attack against our provisioning services, email, and website. We initiated our DDoS mitigation plan and are in the process of mitigating various types of attack traffic patterns. All our other public-facing services (Whois, Whois-RWS, RDAP, DNS, IRR, and RPKI repository services) are not affected by this attack and are operating normally.
> 
> We will announce an all clear 24 hours after the attacks have stopped.
> 
> Regards,
> 
> Mark Kosters
> Chief Technology Officer
> American Registry for Internet Numbers (ARIN)
> 


From woody at pch.net  Sat Mar 26 05:30:23 2016
From: woody at pch.net (Bill Woodcock)
Date: Fri, 25 Mar 2016 22:30:23 -0700
Subject: ARIN down?
In-Reply-To: <B84A117D-BD8B-4686-BA70-3E45B6C9B3D2@beckman.org>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <4D182AB6-DF9F-4732-A343-673E4A62DE6A@pch.net>
 <358F1FD3-4B48-4136-BD19-C9066395B70A@beckman.org>
 <B84A117D-BD8B-4686-BA70-3E45B6C9B3D2@beckman.org>
Message-ID: <A76C10B4-8E8B-436C-9FC0-ACC509BEA5CD@pch.net>


> On Mar 25, 2016, at 10:26 PM, Mel Beckman <mel at beckman.org> wrote:
> I?ve tried accessing the web site from nine different networks: Cox, Comcast, Level3, Verizon, AT&T, CenturyLink, Frontier, Sprint and Cogent. None of them can reach it.

I can reach it just fine via Level3 and NTT right now.

                                -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/20160325/dbcd01b6/attachment.pgp>

From mel at beckman.org  Sat Mar 26 05:41:52 2016
From: mel at beckman.org (Mel Beckman)
Date: Sat, 26 Mar 2016 05:41:52 +0000
Subject: ARIN down?
In-Reply-To: <A76C10B4-8E8B-436C-9FC0-ACC509BEA5CD@pch.net>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <4D182AB6-DF9F-4732-A343-673E4A62DE6A@pch.net>
 <358F1FD3-4B48-4136-BD19-C9066395B70A@beckman.org>
 <B84A117D-BD8B-4686-BA70-3E45B6C9B3D2@beckman.org>
 <A76C10B4-8E8B-436C-9FC0-ACC509BEA5CD@pch.net>
Message-ID: <22BD1F96-DADB-4583-AC2A-859F8C69FF2D@beckman.org>

Since they?re hosted at NTT, that you can reach it from their seems reasonable. But I?ve just tried again from my Level 3 rack in the Santa Barbara hub, and no access. So it?s intermittent at best. 

Hopefully they?ll get clear soon. We had a turn-up today that got waylaid by the outage.

 -mel

> On Mar 25, 2016, at 10:30 PM, Bill Woodcock <woody at pch.net> wrote:
> 
> 
>> On Mar 25, 2016, at 10:26 PM, Mel Beckman <mel at beckman.org> wrote:
>> I?ve tried accessing the web site from nine different networks: Cox, Comcast, Level3, Verizon, AT&T, CenturyLink, Frontier, Sprint and Cogent. None of them can reach it.
> 
> I can reach it just fine via Level3 and NTT right now.
> 
>                                -Bill
> 
> 
> 
> 


From larrysheldon at cox.net  Sat Mar 26 06:15:03 2016
From: larrysheldon at cox.net (Larry Sheldon)
Date: Sat, 26 Mar 2016 01:15:03 -0500
Subject: Oh dear, we've all been made redundant...
In-Reply-To: <1458916747.2444.57.camel@capnet.state.tx.us>
References: <CAHw9_i+N+SkvD11ppmVof-V6CjS2JSMtJXqkkJZTBxYqJ0Ub_g@mail.gmail.com>
 <56EEDC3D.4010804@tiedyenetworks.com>
 <033701d18394$07e01720$17a04560$@gmail.com>
 <1458916747.2444.57.camel@capnet.state.tx.us>
Message-ID: <56F628E7.4040706@cox.net>

On 3/25/2016 09:39, Bryan Bradsby wrote:
>> Uggghhh.  I've always hated this 'reboot, see if it fixes it'
>> methodology.  If the CPEs can't recover from error conditions
>> correctly, they shouldn't be used.  I blame Microsoft for making this
>> concept acceptable.
>>
>> Chuck
>
> I was getting 20% TCP packet loss between two of my unix boxes on the
> TWC route from my house to work, so I called support.
>
> I used lft - like tcptraceroute - both directions, to identify a TWC
> backbone router in Dallas as the problem. I then used the TWC looking
> glass to show the same result.
>
> I was told i needed to reboot my router to troubleshoot. I offered to
> reboot my router, after he rebooted his router in Dallas  ;)

Conversation with one of my daughters earlier about a problem in her 
office today (short summary as I recall it):  Changes made to their VOIP 
system the night before,  stuff broken the next day.

She tried to get "support" to look at the changes made, "support" would 
not do anything until she had rebooted everything including the 
microwave, I guess.

Back in the day--my main trouble shooting strategy was to identify all 
the things that had changed since it last worked the way it was supposed 
to.  The big trouble with that approach is that everybody and their pet 
spider will decide which changes are "important".


-- 
sed quis custodiet ipsos custodes? (Juvenal)

From todd.crane at n5tech.com  Sat Mar 26 06:15:25 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Fri, 25 Mar 2016 23:15:25 -0700
Subject: Cogent Communications
In-Reply-To: <56F6155B.8060202@unlimitednet.us>
References: <CAJm4239Qr0PBgeQuH+k2bxz18jLW9KAsxFJO001qVaeT0cpH3A@mail.gmail.com>
 <56F6155B.8060202@unlimitednet.us>
Message-ID: <961D902B-3B4C-49C7-AAA4-2DFB2ECDEF8C@n5tech.com>

As a Cogent customer, I say ?good luck?

Last time I called them on a Friday night, it was because they announcing (not originating but bad nevertheless) the IPv6 default route. The NOC ?engineer? I spoke with adamantly insisted that there was nothing wrong with this. After about a half hour I gave up. The next morning, another tech, wanted an error message or a route as an example. It wasn?t until Monday morning that they blocked the route.

All I know is that when our contract is up, I can assure you, we won?t make the same mistake twice.


> On Mar 25, 2016, at 9:51 PM, Jason Canady <jason at unlimitednet.us> wrote:
> 
> As a Cogent customer, I'm sure I can get you in touch with someone. Have you tried emailing support at cogentco.com ?  If not, email me off list and I'll find someone you can speak to.
> 
> - Jason
> 
> On 3/24/16 4:20 AM, Brandon Vincent wrote:
>> Does anyone have a NOC/SOC contact for Cogent? I found a improperly
>> secured router on the Internet and I'd like to report it.
>> 
>> Thank you,
>> Brandon Vincent
> 

-------------- 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/20160325/d0ca4e10/attachment.pgp>

From jlewis at lewis.org  Sat Mar 26 20:08:46 2016
From: jlewis at lewis.org (Jon Lewis)
Date: Sat, 26 Mar 2016 16:08:46 -0400 (EDT)
Subject: ARIN down?
In-Reply-To: <437EFD13-5D62-475E-A323-A4655C68A1CF@hammerfiber.com>
References: <FDC44491-1A52-411C-8EE9-1BC8010640E8@beckman.org>
 <437EFD13-5D62-475E-A323-A4655C68A1CF@hammerfiber.com>
Message-ID: <Pine.LNX.4.61.1603261604210.6833@soloth.lewis.org>

On Sat, 26 Mar 2016, Daniel Corbe wrote:

> An announcement went out on arin-announce yesterday (but you might not be able to follow the link if you can??t reach list.arin.net):
>
> http://lists.arin.net/pipermail/arin-announce/2016-March/001963.html
>
> tl;dr: Massive DDoS.  Usual affair.  Welcome to the Internet.

Anyone know how big really?  One org's "Massive DDoS" is another's "oh, is 
someone sending us some extra DNS traffic again?"

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

From Valdis.Kletnieks at vt.edu  Sat Mar 26 20:14:51 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 26 Mar 2016 16:14:51 -0400
Subject: Cogent Communications
In-Reply-To: <961D902B-3B4C-49C7-AAA4-2DFB2ECDEF8C@n5tech.com>
References: <CAJm4239Qr0PBgeQuH+k2bxz18jLW9KAsxFJO001qVaeT0cpH3A@mail.gmail.com>
 <56F6155B.8060202@unlimitednet.us>
 <961D902B-3B4C-49C7-AAA4-2DFB2ECDEF8C@n5tech.com>
Message-ID: <73934.1459023291@turing-police.cc.vt.edu>

On Fri, 25 Mar 2016 23:15:25 -0700, Todd Crane said:

> Last time I called them on a Friday night, it was because they announcing
> (not originating but bad nevertheless) the IPv6 default route.

I'm tempted to say that forwarding it is even worse than originating it,
because it proves they weren't sanity checking what somebody else gave them...
-------------- 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/20160326/92f3b885/attachment.pgp>

From nanog at ics-il.net  Sun Mar 27 14:58:58 2016
From: nanog at ics-il.net (Mike Hammett)
Date: Sun, 27 Mar 2016 09:58:58 -0500 (CDT)
Subject: AWS Contact
In-Reply-To: <818550268.10582.1459090632362.JavaMail.mhammett@ThunderFuck>
Message-ID: <600672962.10587.1459090736242.JavaMail.mhammett@ThunderFuck>

Could anyone with AWS Direct Connect or AWS Partner Network reach out to me? I filled out the form on the web site almost a month ago that promised a five day turn around. I also had someone else in here at Amazon poking the Direct Connect people, but no response there either. :-\ 




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



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



From rdrake at direcpath.com  Tue Mar 29 00:14:08 2016
From: rdrake at direcpath.com (Robert Drake)
Date: Mon, 28 Mar 2016 20:14:08 -0400
Subject: tel script
Message-ID: <ef300bd7-90fa-43ca-a5fa-c2ce32d9d66d@direcpath.com>

This is a program for logging into devices.  You can find it here:

https://github.com/rfdrake/tel

I don't like to self promote things, but I'm interested in feedback.  
I'm also interested in alternatives if someone wrote something better.

I started it a long time ago as a lighter clogin which didn't hang as 
much.  Moving from expect to perl cut and bunch of the cruft out because 
of how verbose the TCL language is.   My script is now larger than 
clogin and no longer consists of a single file.  It's also arguably much 
cruftier in places, but it's gained some features I think people may like:

Color syntax highlighting for "show interface" and some other commands
An attempt to make backspace work on platforms with differing opinions 
of ^H vs ^?
Run multiple script files and multiple devices in the same command (tel 
-x script1.txt -x script2.txt router router2 router3)
Unified logout command: ctrl-d
send slow (tel -s .5 -x script1.txt router) for sending scripts to 
devices with buffering issues
send slow interactively (tel -S .5 router) for cut and paste to devices 
with buffering issues  (some terminal emulators will do this if it's the 
only thing you need)
change your device profile after login (tel -A zhone oob-test-lab:2004) 
helpful if you login through an out of band console which is made by one 
vendor into a device made by another vendor
Support for KeePass, Pass, PWSafe3, and Gnome/KDE/MacOS Keyring, as well 
as a combination of these for storing passwords in encrypted files

The entire thing is very customizeable for people who know perl or 
scripting languages.  It's designed for NOC use on bounce servers where 
the administrator might setup the global profile in /etc/telrc, then the 
individual users would make their own profiles in their home directories 
to override individual settings.

Limitations:

I'm pretty sure I tried to build this on Cygwin once and it failed for 
reasons that probably can never be fixed.  I've also never tested on MacOSX.

I've run it successfully on various Linux as well as FreeBSD and OpenBSD.

From jfmezei_nanog at vaxination.ca  Thu Mar 31 06:51:00 2016
From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei)
Date: Thu, 31 Mar 2016 02:51:00 -0400
Subject: Capacity planning , transit vs last mile
Message-ID: <56FCC8D4.1040806@vaxination.ca>


Canada is to hold a 3 week long hearing on discussing whether the
internet is important and whether the farcical 5/1 speed promoted by the
government is adequate.

In this day and age, it would be easy to just set FTTP as target
technology and be done with it, but too many want to have a policy that
is technologically neutral.

To this end, I will not only be proposing that subsidized deployments
not only meet advertised service speed standards, but also a capacity
per end user metric for the last mile technology  as well as for the
backhaul/transit.

(One of the often subsidized companies deploys fixed wireless which
delivers the advertised speed for the first week, but routinely gets
oversubscribed after a while and customers feel like on dialup.)


I know that for sufficiently large ISPs, they currently provision just
over 1mbps of transit capacity per end user (so 800-1000 customers per
1gbps of transit). The number rises by over 30% a year as usage grows.
(The CRTC can get exact figure from telecom operators and generate
aggregate industry-wide growth in traffic to do yearly standard adjustment).

QUESTION:

Say the policy is 1mbps per customer if 1000 customer or more.  Is there
some formula (approx or precise) to calculate how that 1mbps changes for
smaller samples ? (like 500 customers, 200 ? )



And on the last mile portion where one has typically few users on each
shared capacity segment (fixed wireless, FTTP, cable), are there fairly
standard oversubscription ratios based on average service speed that is
sold in that neighbourhood ? (for instance if I have 100 customers with
average subscibed speed of 15mbps, how much capacity should the antenna
serving those customers have ?


I realise that each ISP guards its oversubscription ratios as very
proprietary, but aren't there generic industry-wide recommendations ? My
goal is to have some basic standards that prevent gross over
subscription that result in unusable service.

As well, I want that a company pitching a broadband deployment be able
to demonstrate that the technology being deployed will last X years
because it has sufficient capacity to handle the number  of customers as
well as the predicted growth in usage each year.


Any help ? comments on whether this is crazy ? sanity check ?






From marcel.duregards at yahoo.fr  Thu Mar 31 08:02:05 2016
From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr)
Date: Thu, 31 Mar 2016 10:02:05 +0200
Subject: how to deal with port scan and brute force attack from AS 8075 ?
Message-ID: <56FCD97D.8050201@yahoo.fr>

Dear Nanog'er,

We are facing a lot of port scan and brute force attack on port 22 (but
not limited to) from Microsoft AS 8075 range toward our own infra, or
toward our customers.
We have sent email to abuse at microsoft.com, but no answer.

source ip are:
NetRange:       40.74.0.0 - 40.125.127.255
CIDR:           40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16,
40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12, 40.120.0.0/14
NetName:        MSFT



We consider port scan and brute force on ssh port as an attack, and even
as a pre-DDOS phase (could be use to install botnet, detect unpatched
host, and so one).

It's one thing to propose services and make money over an infra, it's an
other thing to take care that you clients do not use this infra to make
illegal stuffs.


How do you deal with such massive amount of 'illegal' traffic ?

Thank,
Best Regards
Marcel





He are some examples (we have more than 3000 such packets per day just
from them, probably Azure), and source ip is always differents of course:


Flow Filtering Expression
  src AS 8075 and dst port 22 and packets=1
Limit Flows
  40000
Sorting
  By Date

Date_first_seen          Duration Proto     _IP_Addr:Port
Dst_IP_Addr:Port   Flags Packets
2016-02-29 14:55:20.108     0.000 6    104.45.210.69:1160  ->
x.x.231:22    ......      1
2016-02-29 14:55:20.611     0.000 6    104.45.210.69:1161  ->
x.x.231:22    ......      1
2016-02-29 14:56:41.004     0.000 6     40.76.55.204:1090  ->
x.x..14:22    ......      1
2016-02-29 14:56:41.324     0.000 6     40.76.55.204:1091  ->
x.x..14:22    ......      1
2016-02-29 15:00:05.670     0.000 6     40.76.55.204:1088  ->
x.x.125:22    ......      1
2016-02-29 15:00:06.003     0.000 6     40.76.55.204:1089  ->
x.x.125:22    ......      1
2016-02-29 15:01:17.358     0.000 6      40.76.70.58:1168  ->
x.x..80:22    ......      1
2016-02-29 15:01:17.676     0.000 6      40.76.70.58:1169  ->
x.x..80:22    ......      1
2016-02-29 15:02:42.637     0.000 6     40.76.55.204:1176  ->
x.x.193:22    ......      1
2016-02-29 15:02:42.878     0.000 6     40.76.55.204:1177  ->
x.x.193:22    ......      1
2016-02-29 15:02:48.067     0.000 6    104.45.210.69:1160  ->
x.x.173:22    ......      1
2016-02-29 15:02:48.394     0.000 6    104.45.210.69:1161  ->
x.x.173:22    ......      1
2016-02-29 15:03:18.854     0.000 6    40.121.53.153:1041  ->
x.x..88:22    ......      1
2016-02-29 15:03:19.172     0.000 6    40.121.53.153:1042  ->
x.x..88:22    ......      1
2016-02-29 15:06:36.248     0.000 6     40.76.55.204:1056  ->
x.x..45:22    ......      1
2016-02-29 15:07:31.882     0.000 6      40.76.80.17:44895 ->
x.x..75:22    ......      1
2016-02-29 15:07:32.245     0.000 6      40.76.80.17:44896 ->
x.x..75:22    ......      1
2016-02-29 15:09:08.433     0.000 6      40.76.70.58:1168  ->
x.x..31:22    ......      1
2016-02-29 15:09:08.744     0.000 6      40.76.70.58:1169  ->
x.x..31:22    ......      1
2016-02-29 15:11:45.668     0.000 6      40.76.80.17:47993 ->
x.x.157:22    ......      1
2016-02-29 15:11:45.987     0.000 6      40.76.80.17:47994 ->
x.x.157:22    ......      1
2016-02-29 15:12:09.543     0.000 6      40.76.70.58:1168  ->
x.x..24:22    ......      1
2016-02-29 15:12:09.925     0.000 6      40.76.70.58:1169  ->
x.x..24:22    ......      1
2016-02-29 15:17:05.920     0.000 6      40.76.70.58:1168  ->
x.x.243:22    ......      1
2016-02-29 15:17:06.241     0.000 6      40.76.70.58:1169  ->
x.x.243:22    ......      1
2016-02-29 15:19:21.364     0.000 6    40.83.121.211:62936 ->
x.x..81:22    ......      1
2016-02-29 15:19:21.704     0.000 6    40.83.121.211:62937 ->
x.x..81:22    ......      1
2016-02-29 15:19:45.891     0.000 6      40.76.70.58:1168  ->
x.x..39:22    ......      1
2016-02-29 15:19:46.273     0.000 6      40.76.70.58:1169  ->
x.x..39:22    ......      1
2016-02-29 15:21:52.030     0.000 6      40.76.70.58:1168  ->
x.x.120:22    ......      1
2016-02-29 15:21:52.349     0.000 6      40.76.70.58:1169  ->
x.x.120:22    ......      1
2016-02-29 15:24:07.614     0.000 6     40.76.55.204:1048  ->
x.x.237:22    ......      1
2016-02-29 15:24:07.933     0.000 6     40.76.55.204:1128  ->
x.x.237:22    ......      1
2016-02-29 15:27:31.289     0.000 6    40.121.53.153:1041  ->
x.x.133:22    ......      1
2016-02-29 15:27:31.544     0.000 6    40.121.53.153:1042  ->
x.x.133:22    ......      1
2016-02-29 15:27:59.120     0.000 6      40.76.70.58:1168  ->
x.x.9.3:22    ......      1
2016-02-29 15:27:59.440     0.000 6      40.76.70.58:1169  ->
x.x.9.3:22    ......      1
2016-02-29 15:29:30.933     0.000 6      40.76.70.58:1168  ->
x.x.211:22    ......      1
2016-02-29 15:29:31.031     0.000 6      40.76.70.58:1169  ->
x.x.211:22    ......      1
2016-02-29 15:29:33.729     0.000 6     40.76.55.204:1142  ->
x.x.166:22    ......      1
2016-02-29 15:29:34.032     0.000 6     40.76.55.204:1143  ->
x.x.166:22    ......      1
2016-02-29 15:31:41.947     0.000 6      40.76.70.58:1168  ->
x.x.137:22    ......      1
2016-02-29 15:31:42.266     0.000 6      40.76.70.58:1169  ->
x.x.137:22    ......      1
2016-02-29 15:32:10.044     0.000 6    40.121.53.153:1041  ->
x.x..71:22    ......      1
2016-02-29 15:32:10.348     0.000 6    40.121.53.153:1042  ->
x.x..71:22    ......      1
2016-02-29 15:32:10.442     0.000 6    104.45.210.69:1161  ->
x.x.246:22    ......      1
2016-02-29 15:32:10.475     0.000 6    104.45.210.69:1160  ->
x.x.246:22    ......      1
2016-02-29 15:32:29.165     0.000 6   40.121.143.132:1040  ->
x.x..62:22    ......      1
2016-02-29 15:32:29.466     0.000 6   40.121.143.132:1041  ->
x.x..62:22    ......      1
2016-02-29 15:37:07.616     0.000 6      40.76.80.17:56902 ->
x.x..51:22    ......      1
2016-02-29 15:37:07.925     0.000 6      40.76.80.17:56903 ->
x.x..51:22    ......      1
2016-02-29 15:40:04.546     0.000 6    40.121.53.153:1041  ->
x.x.186:22    ......      1
2016-02-29 15:40:04.866     0.000 6    40.121.53.153:1042  ->
x.x.186:22    ......      1
2016-02-29 15:40:28.870     0.000 6      40.76.70.58:1168  ->
x.x.171:22    ......      1
2016-02-29 15:40:29.125     0.000 6      40.76.70.58:1169  ->
x.x.171:22    ......      1
2016-02-29 15:41:57.034     0.000 6     40.76.55.204:1128  ->
x.x.181:22    ......      1
2016-02-29 15:41:57.354     0.000 6     40.76.55.204:1176  ->
x.x.181:22    ......      1


2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
x.x.163:22    ......      1
2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
x.x.176:22    ......      1
2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
x.x.206:22    ......      1
2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
x.x.158:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.185:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.251:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.255:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.141:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.136:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.235:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.242:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.240:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.100:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.244:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x.217:22    ......      1
2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
x.x..72:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.221:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.5.4:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.150:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.145:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.119:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x..52:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x..75:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.127:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x..22:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x..77:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.246:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x.137:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x..85:22    ......      1
2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
x.x..35:22    ......      1





From robert at ripe.net  Thu Mar 31 08:06:51 2016
From: robert at ripe.net (Robert Kisteleki)
Date: Thu, 31 Mar 2016 10:06:51 +0200
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <56FCD97D.8050201@yahoo.fr>
References: <56FCD97D.8050201@yahoo.fr>
Message-ID: <56FCDA9B.7020803@ripe.net>


> How do you deal with such massive amount of 'illegal' traffic ?

Move SSH to a different port. Better yet, use IPv6 only :-)

Robert

From todd.crane at n5tech.com  Thu Mar 31 08:15:05 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Thu, 31 Mar 2016 01:15:05 -0700
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <56FCD97D.8050201@yahoo.fr>
References: <56FCD97D.8050201@yahoo.fr>
Message-ID: <E141D8F9-B375-4DE7-A6F8-E2EF552D30B0@n5tech.com>

Marcel

Depending on what is on those machines, I would just recommend using fail2ban. The default is that if an ip address fails ssh auth 3 times in 5 minutes, their ip gets blocked via iptables for 5 minutes. This is enough to thwart most scripted attacks, especially those from a certain government in Asia. This is configurable to various applications, timing schemes, and blocking/jailing mechanisms.

-Todd
> On Mar 31, 2016, at 1:02 AM, marcel.duregards--- via NANOG <nanog at nanog.org> wrote:
> 
> Dear Nanog'er,
> 
> We are facing a lot of port scan and brute force attack on port 22 (but
> not limited to) from Microsoft AS 8075 range toward our own infra, or
> toward our customers.
> We have sent email to abuse at microsoft.com, but no answer.
> 
> source ip are:
> NetRange:       40.74.0.0 - 40.125.127.255
> CIDR:           40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16,
> 40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12, 40.120.0.0/14
> NetName:        MSFT
> 
> 
> 
> We consider port scan and brute force on ssh port as an attack, and even
> as a pre-DDOS phase (could be use to install botnet, detect unpatched
> host, and so one).
> 
> It's one thing to propose services and make money over an infra, it's an
> other thing to take care that you clients do not use this infra to make
> illegal stuffs.
> 
> 
> How do you deal with such massive amount of 'illegal' traffic ?
> 
> Thank,
> Best Regards
> Marcel
> 
> 
> 
> 
> 
> He are some examples (we have more than 3000 such packets per day just
> from them, probably Azure), and source ip is always differents of course:
> 
> 
> Flow Filtering Expression
>  src AS 8075 and dst port 22 and packets=1
> Limit Flows
>  40000
> Sorting
>  By Date
> 
> Date_first_seen          Duration Proto     _IP_Addr:Port
> Dst_IP_Addr:Port   Flags Packets
> 2016-02-29 14:55:20.108     0.000 6    104.45.210.69:1160  ->
> x.x.231:22    ......      1
> 2016-02-29 14:55:20.611     0.000 6    104.45.210.69:1161  ->
> x.x.231:22    ......      1
> 2016-02-29 14:56:41.004     0.000 6     40.76.55.204:1090  ->
> x.x..14:22    ......      1
> 2016-02-29 14:56:41.324     0.000 6     40.76.55.204:1091  ->
> x.x..14:22    ......      1
> 2016-02-29 15:00:05.670     0.000 6     40.76.55.204:1088  ->
> x.x.125:22    ......      1
> 2016-02-29 15:00:06.003     0.000 6     40.76.55.204:1089  ->
> x.x.125:22    ......      1
> 2016-02-29 15:01:17.358     0.000 6      40.76.70.58:1168  ->
> x.x..80:22    ......      1
> 2016-02-29 15:01:17.676     0.000 6      40.76.70.58:1169  ->
> x.x..80:22    ......      1
> 2016-02-29 15:02:42.637     0.000 6     40.76.55.204:1176  ->
> x.x.193:22    ......      1
> 2016-02-29 15:02:42.878     0.000 6     40.76.55.204:1177  ->
> x.x.193:22    ......      1
> 2016-02-29 15:02:48.067     0.000 6    104.45.210.69:1160  ->
> x.x.173:22    ......      1
> 2016-02-29 15:02:48.394     0.000 6    104.45.210.69:1161  ->
> x.x.173:22    ......      1
> 2016-02-29 15:03:18.854     0.000 6    40.121.53.153:1041  ->
> x.x..88:22    ......      1
> 2016-02-29 15:03:19.172     0.000 6    40.121.53.153:1042  ->
> x.x..88:22    ......      1
> 2016-02-29 15:06:36.248     0.000 6     40.76.55.204:1056  ->
> x.x..45:22    ......      1
> 2016-02-29 15:07:31.882     0.000 6      40.76.80.17:44895 ->
> x.x..75:22    ......      1
> 2016-02-29 15:07:32.245     0.000 6      40.76.80.17:44896 ->
> x.x..75:22    ......      1
> 2016-02-29 15:09:08.433     0.000 6      40.76.70.58:1168  ->
> x.x..31:22    ......      1
> 2016-02-29 15:09:08.744     0.000 6      40.76.70.58:1169  ->
> x.x..31:22    ......      1
> 2016-02-29 15:11:45.668     0.000 6      40.76.80.17:47993 ->
> x.x.157:22    ......      1
> 2016-02-29 15:11:45.987     0.000 6      40.76.80.17:47994 ->
> x.x.157:22    ......      1
> 2016-02-29 15:12:09.543     0.000 6      40.76.70.58:1168  ->
> x.x..24:22    ......      1
> 2016-02-29 15:12:09.925     0.000 6      40.76.70.58:1169  ->
> x.x..24:22    ......      1
> 2016-02-29 15:17:05.920     0.000 6      40.76.70.58:1168  ->
> x.x.243:22    ......      1
> 2016-02-29 15:17:06.241     0.000 6      40.76.70.58:1169  ->
> x.x.243:22    ......      1
> 2016-02-29 15:19:21.364     0.000 6    40.83.121.211:62936 ->
> x.x..81:22    ......      1
> 2016-02-29 15:19:21.704     0.000 6    40.83.121.211:62937 ->
> x.x..81:22    ......      1
> 2016-02-29 15:19:45.891     0.000 6      40.76.70.58:1168  ->
> x.x..39:22    ......      1
> 2016-02-29 15:19:46.273     0.000 6      40.76.70.58:1169  ->
> x.x..39:22    ......      1
> 2016-02-29 15:21:52.030     0.000 6      40.76.70.58:1168  ->
> x.x.120:22    ......      1
> 2016-02-29 15:21:52.349     0.000 6      40.76.70.58:1169  ->
> x.x.120:22    ......      1
> 2016-02-29 15:24:07.614     0.000 6     40.76.55.204:1048  ->
> x.x.237:22    ......      1
> 2016-02-29 15:24:07.933     0.000 6     40.76.55.204:1128  ->
> x.x.237:22    ......      1
> 2016-02-29 15:27:31.289     0.000 6    40.121.53.153:1041  ->
> x.x.133:22    ......      1
> 2016-02-29 15:27:31.544     0.000 6    40.121.53.153:1042  ->
> x.x.133:22    ......      1
> 2016-02-29 15:27:59.120     0.000 6      40.76.70.58:1168  ->
> x.x.9.3:22    ......      1
> 2016-02-29 15:27:59.440     0.000 6      40.76.70.58:1169  ->
> x.x.9.3:22    ......      1
> 2016-02-29 15:29:30.933     0.000 6      40.76.70.58:1168  ->
> x.x.211:22    ......      1
> 2016-02-29 15:29:31.031     0.000 6      40.76.70.58:1169  ->
> x.x.211:22    ......      1
> 2016-02-29 15:29:33.729     0.000 6     40.76.55.204:1142  ->
> x.x.166:22    ......      1
> 2016-02-29 15:29:34.032     0.000 6     40.76.55.204:1143  ->
> x.x.166:22    ......      1
> 2016-02-29 15:31:41.947     0.000 6      40.76.70.58:1168  ->
> x.x.137:22    ......      1
> 2016-02-29 15:31:42.266     0.000 6      40.76.70.58:1169  ->
> x.x.137:22    ......      1
> 2016-02-29 15:32:10.044     0.000 6    40.121.53.153:1041  ->
> x.x..71:22    ......      1
> 2016-02-29 15:32:10.348     0.000 6    40.121.53.153:1042  ->
> x.x..71:22    ......      1
> 2016-02-29 15:32:10.442     0.000 6    104.45.210.69:1161  ->
> x.x.246:22    ......      1
> 2016-02-29 15:32:10.475     0.000 6    104.45.210.69:1160  ->
> x.x.246:22    ......      1
> 2016-02-29 15:32:29.165     0.000 6   40.121.143.132:1040  ->
> x.x..62:22    ......      1
> 2016-02-29 15:32:29.466     0.000 6   40.121.143.132:1041  ->
> x.x..62:22    ......      1
> 2016-02-29 15:37:07.616     0.000 6      40.76.80.17:56902 ->
> x.x..51:22    ......      1
> 2016-02-29 15:37:07.925     0.000 6      40.76.80.17:56903 ->
> x.x..51:22    ......      1
> 2016-02-29 15:40:04.546     0.000 6    40.121.53.153:1041  ->
> x.x.186:22    ......      1
> 2016-02-29 15:40:04.866     0.000 6    40.121.53.153:1042  ->
> x.x.186:22    ......      1
> 2016-02-29 15:40:28.870     0.000 6      40.76.70.58:1168  ->
> x.x.171:22    ......      1
> 2016-02-29 15:40:29.125     0.000 6      40.76.70.58:1169  ->
> x.x.171:22    ......      1
> 2016-02-29 15:41:57.034     0.000 6     40.76.55.204:1128  ->
> x.x.181:22    ......      1
> 2016-02-29 15:41:57.354     0.000 6     40.76.55.204:1176  ->
> x.x.181:22    ......      1
> 
> 
> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> x.x.163:22    ......      1
> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> x.x.176:22    ......      1
> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> x.x.206:22    ......      1
> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> x.x.158:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.185:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.251:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.255:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.141:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.136:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.235:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.242:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.240:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.100:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.244:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x.217:22    ......      1
> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> x.x..72:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.221:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.5.4:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.150:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.145:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.119:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x..52:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x..75:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.127:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x..22:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x..77:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.246:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x.137:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x..85:22    ......      1
> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> x.x..35:22    ......      1
> 
> 
> 
> 

-------------- 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/20160331/56e1f8ee/attachment.pgp>

From todd.crane at n5tech.com  Thu Mar 31 08:18:47 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Thu, 31 Mar 2016 01:18:47 -0700
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <E141D8F9-B375-4DE7-A6F8-E2EF552D30B0@n5tech.com>
References: <56FCD97D.8050201@yahoo.fr>
 <E141D8F9-B375-4DE7-A6F8-E2EF552D30B0@n5tech.com>
Message-ID: <D0DF71A6-EFA7-4C19-A06F-7AC79F67A37A@n5tech.com>

Oh and,

I?m assuming you contacted Microsoft?s abuse? If not, it?s not cool, not to mention unprofessional, to publicly call them out on such a public forum without giving them an opportunity to correct it first.

> On Mar 31, 2016, at 1:15 AM, Todd Crane <todd.crane at n5tech.com> wrote:
> 
> Marcel
> 
> Depending on what is on those machines, I would just recommend using fail2ban. The default is that if an ip address fails ssh auth 3 times in 5 minutes, their ip gets blocked via iptables for 5 minutes. This is enough to thwart most scripted attacks, especially those from a certain government in Asia. This is configurable to various applications, timing schemes, and blocking/jailing mechanisms.
> 
> -Todd
>> On Mar 31, 2016, at 1:02 AM, marcel.duregards--- via NANOG <nanog at nanog.org> wrote:
>> 
>> Dear Nanog'er,
>> 
>> We are facing a lot of port scan and brute force attack on port 22 (but
>> not limited to) from Microsoft AS 8075 range toward our own infra, or
>> toward our customers.
>> We have sent email to abuse at microsoft.com, but no answer.
>> 
>> source ip are:
>> NetRange:       40.74.0.0 - 40.125.127.255
>> CIDR:           40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16,
>> 40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12, 40.120.0.0/14
>> NetName:        MSFT
>> 
>> 
>> 
>> We consider port scan and brute force on ssh port as an attack, and even
>> as a pre-DDOS phase (could be use to install botnet, detect unpatched
>> host, and so one).
>> 
>> It's one thing to propose services and make money over an infra, it's an
>> other thing to take care that you clients do not use this infra to make
>> illegal stuffs.
>> 
>> 
>> How do you deal with such massive amount of 'illegal' traffic ?
>> 
>> Thank,
>> Best Regards
>> Marcel
>> 
>> 
>> 
>> 
>> 
>> He are some examples (we have more than 3000 such packets per day just
>> from them, probably Azure), and source ip is always differents of course:
>> 
>> 
>> Flow Filtering Expression
>> src AS 8075 and dst port 22 and packets=1
>> Limit Flows
>> 40000
>> Sorting
>> By Date
>> 
>> Date_first_seen          Duration Proto     _IP_Addr:Port
>> Dst_IP_Addr:Port   Flags Packets
>> 2016-02-29 14:55:20.108     0.000 6    104.45.210.69:1160  ->
>> x.x.231:22    ......      1
>> 2016-02-29 14:55:20.611     0.000 6    104.45.210.69:1161  ->
>> x.x.231:22    ......      1
>> 2016-02-29 14:56:41.004     0.000 6     40.76.55.204:1090  ->
>> x.x..14:22    ......      1
>> 2016-02-29 14:56:41.324     0.000 6     40.76.55.204:1091  ->
>> x.x..14:22    ......      1
>> 2016-02-29 15:00:05.670     0.000 6     40.76.55.204:1088  ->
>> x.x.125:22    ......      1
>> 2016-02-29 15:00:06.003     0.000 6     40.76.55.204:1089  ->
>> x.x.125:22    ......      1
>> 2016-02-29 15:01:17.358     0.000 6      40.76.70.58:1168  ->
>> x.x..80:22    ......      1
>> 2016-02-29 15:01:17.676     0.000 6      40.76.70.58:1169  ->
>> x.x..80:22    ......      1
>> 2016-02-29 15:02:42.637     0.000 6     40.76.55.204:1176  ->
>> x.x.193:22    ......      1
>> 2016-02-29 15:02:42.878     0.000 6     40.76.55.204:1177  ->
>> x.x.193:22    ......      1
>> 2016-02-29 15:02:48.067     0.000 6    104.45.210.69:1160  ->
>> x.x.173:22    ......      1
>> 2016-02-29 15:02:48.394     0.000 6    104.45.210.69:1161  ->
>> x.x.173:22    ......      1
>> 2016-02-29 15:03:18.854     0.000 6    40.121.53.153:1041  ->
>> x.x..88:22    ......      1
>> 2016-02-29 15:03:19.172     0.000 6    40.121.53.153:1042  ->
>> x.x..88:22    ......      1
>> 2016-02-29 15:06:36.248     0.000 6     40.76.55.204:1056  ->
>> x.x..45:22    ......      1
>> 2016-02-29 15:07:31.882     0.000 6      40.76.80.17:44895 ->
>> x.x..75:22    ......      1
>> 2016-02-29 15:07:32.245     0.000 6      40.76.80.17:44896 ->
>> x.x..75:22    ......      1
>> 2016-02-29 15:09:08.433     0.000 6      40.76.70.58:1168  ->
>> x.x..31:22    ......      1
>> 2016-02-29 15:09:08.744     0.000 6      40.76.70.58:1169  ->
>> x.x..31:22    ......      1
>> 2016-02-29 15:11:45.668     0.000 6      40.76.80.17:47993 ->
>> x.x.157:22    ......      1
>> 2016-02-29 15:11:45.987     0.000 6      40.76.80.17:47994 ->
>> x.x.157:22    ......      1
>> 2016-02-29 15:12:09.543     0.000 6      40.76.70.58:1168  ->
>> x.x..24:22    ......      1
>> 2016-02-29 15:12:09.925     0.000 6      40.76.70.58:1169  ->
>> x.x..24:22    ......      1
>> 2016-02-29 15:17:05.920     0.000 6      40.76.70.58:1168  ->
>> x.x.243:22    ......      1
>> 2016-02-29 15:17:06.241     0.000 6      40.76.70.58:1169  ->
>> x.x.243:22    ......      1
>> 2016-02-29 15:19:21.364     0.000 6    40.83.121.211:62936 ->
>> x.x..81:22    ......      1
>> 2016-02-29 15:19:21.704     0.000 6    40.83.121.211:62937 ->
>> x.x..81:22    ......      1
>> 2016-02-29 15:19:45.891     0.000 6      40.76.70.58:1168  ->
>> x.x..39:22    ......      1
>> 2016-02-29 15:19:46.273     0.000 6      40.76.70.58:1169  ->
>> x.x..39:22    ......      1
>> 2016-02-29 15:21:52.030     0.000 6      40.76.70.58:1168  ->
>> x.x.120:22    ......      1
>> 2016-02-29 15:21:52.349     0.000 6      40.76.70.58:1169  ->
>> x.x.120:22    ......      1
>> 2016-02-29 15:24:07.614     0.000 6     40.76.55.204:1048  ->
>> x.x.237:22    ......      1
>> 2016-02-29 15:24:07.933     0.000 6     40.76.55.204:1128  ->
>> x.x.237:22    ......      1
>> 2016-02-29 15:27:31.289     0.000 6    40.121.53.153:1041  ->
>> x.x.133:22    ......      1
>> 2016-02-29 15:27:31.544     0.000 6    40.121.53.153:1042  ->
>> x.x.133:22    ......      1
>> 2016-02-29 15:27:59.120     0.000 6      40.76.70.58:1168  ->
>> x.x.9.3:22    ......      1
>> 2016-02-29 15:27:59.440     0.000 6      40.76.70.58:1169  ->
>> x.x.9.3:22    ......      1
>> 2016-02-29 15:29:30.933     0.000 6      40.76.70.58:1168  ->
>> x.x.211:22    ......      1
>> 2016-02-29 15:29:31.031     0.000 6      40.76.70.58:1169  ->
>> x.x.211:22    ......      1
>> 2016-02-29 15:29:33.729     0.000 6     40.76.55.204:1142  ->
>> x.x.166:22    ......      1
>> 2016-02-29 15:29:34.032     0.000 6     40.76.55.204:1143  ->
>> x.x.166:22    ......      1
>> 2016-02-29 15:31:41.947     0.000 6      40.76.70.58:1168  ->
>> x.x.137:22    ......      1
>> 2016-02-29 15:31:42.266     0.000 6      40.76.70.58:1169  ->
>> x.x.137:22    ......      1
>> 2016-02-29 15:32:10.044     0.000 6    40.121.53.153:1041  ->
>> x.x..71:22    ......      1
>> 2016-02-29 15:32:10.348     0.000 6    40.121.53.153:1042  ->
>> x.x..71:22    ......      1
>> 2016-02-29 15:32:10.442     0.000 6    104.45.210.69:1161  ->
>> x.x.246:22    ......      1
>> 2016-02-29 15:32:10.475     0.000 6    104.45.210.69:1160  ->
>> x.x.246:22    ......      1
>> 2016-02-29 15:32:29.165     0.000 6   40.121.143.132:1040  ->
>> x.x..62:22    ......      1
>> 2016-02-29 15:32:29.466     0.000 6   40.121.143.132:1041  ->
>> x.x..62:22    ......      1
>> 2016-02-29 15:37:07.616     0.000 6      40.76.80.17:56902 ->
>> x.x..51:22    ......      1
>> 2016-02-29 15:37:07.925     0.000 6      40.76.80.17:56903 ->
>> x.x..51:22    ......      1
>> 2016-02-29 15:40:04.546     0.000 6    40.121.53.153:1041  ->
>> x.x.186:22    ......      1
>> 2016-02-29 15:40:04.866     0.000 6    40.121.53.153:1042  ->
>> x.x.186:22    ......      1
>> 2016-02-29 15:40:28.870     0.000 6      40.76.70.58:1168  ->
>> x.x.171:22    ......      1
>> 2016-02-29 15:40:29.125     0.000 6      40.76.70.58:1169  ->
>> x.x.171:22    ......      1
>> 2016-02-29 15:41:57.034     0.000 6     40.76.55.204:1128  ->
>> x.x.181:22    ......      1
>> 2016-02-29 15:41:57.354     0.000 6     40.76.55.204:1176  ->
>> x.x.181:22    ......      1
>> 
>> 
>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>> x.x.163:22    ......      1
>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>> x.x.176:22    ......      1
>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>> x.x.206:22    ......      1
>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>> x.x.158:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.185:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.251:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.255:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.141:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.136:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.235:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.242:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.240:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.100:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.244:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x.217:22    ......      1
>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>> x.x..72:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.221:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.5.4:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.150:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.145:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.119:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x..52:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x..75:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.127:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x..22:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x..77:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.246:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x.137:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x..85:22    ......      1
>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>> x.x..35:22    ......      1
>> 
>> 
>> 
>> 
> 

-------------- 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/20160331/9604ccba/attachment.pgp>

From todd.crane at n5tech.com  Thu Mar 31 09:04:40 2016
From: todd.crane at n5tech.com (Todd Crane)
Date: Thu, 31 Mar 2016 02:04:40 -0700
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <Pine.LNX.4.64.1603310201030.11131@yuri.anime.net>
References: <56FCD97D.8050201@yahoo.fr>
 <E141D8F9-B375-4DE7-A6F8-E2EF552D30B0@n5tech.com>
 <D0DF71A6-EFA7-4C19-A06F-7AC79F67A37A@n5tech.com>
 <Pine.LNX.4.64.1603310201030.11131@yuri.anime.net>
Message-ID: <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com>

I must have missed that? my bad.


> On Mar 31, 2016, at 2:01 AM, Dan Hollis <goemon at sasami.anime.net> wrote:
> 
> It's right there in his email:
> 
> "We have sent email to abuse at microsoft.com, but no answer."
> 
> -Dan
> 
> On Thu, 31 Mar 2016, Todd Crane wrote:
> 
>> Oh and,
>> 
>> I?m assuming you contacted Microsoft?s abuse? If not, it?s not cool, not to mention unprofessional, to publicly call them out on such a public forum without giving them an opportunity to correct it first.
>> 
>>> On Mar 31, 2016, at 1:15 AM, Todd Crane <todd.crane at n5tech.com> wrote:
>>> 
>>> Marcel
>>> 
>>> Depending on what is on those machines, I would just recommend using fail2ban. The default is that if an ip address fails ssh auth 3 times in 5 minutes, their ip gets blocked via iptables for 5 minutes. This is enough to thwart most scripted attacks, especially those from a certain government in Asia. This is configurable to various applications, timing schemes, and blocking/jailing mechanisms.
>>> 
>>> -Todd
>>>> On Mar 31, 2016, at 1:02 AM, marcel.duregards--- via NANOG <nanog at nanog.org> wrote:
>>>> 
>>>> Dear Nanog'er,
>>>> 
>>>> We are facing a lot of port scan and brute force attack on port 22 (but
>>>> not limited to) from Microsoft AS 8075 range toward our own infra, or
>>>> toward our customers.
>>>> We have sent email to abuse at microsoft.com, but no answer.
>>>> 
>>>> source ip are:
>>>> NetRange:       40.74.0.0 - 40.125.127.255
>>>> CIDR:           40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16,
>>>> 40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12, 40.120.0.0/14
>>>> NetName:        MSFT
>>>> 
>>>> 
>>>> 
>>>> We consider port scan and brute force on ssh port as an attack, and even
>>>> as a pre-DDOS phase (could be use to install botnet, detect unpatched
>>>> host, and so one).
>>>> 
>>>> It's one thing to propose services and make money over an infra, it's an
>>>> other thing to take care that you clients do not use this infra to make
>>>> illegal stuffs.
>>>> 
>>>> 
>>>> How do you deal with such massive amount of 'illegal' traffic ?
>>>> 
>>>> Thank,
>>>> Best Regards
>>>> Marcel
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> He are some examples (we have more than 3000 such packets per day just
>>>> from them, probably Azure), and source ip is always differents of course:
>>>> 
>>>> 
>>>> Flow Filtering Expression
>>>> src AS 8075 and dst port 22 and packets=1
>>>> Limit Flows
>>>> 40000
>>>> Sorting
>>>> By Date
>>>> 
>>>> Date_first_seen          Duration Proto     _IP_Addr:Port
>>>> Dst_IP_Addr:Port   Flags Packets
>>>> 2016-02-29 14:55:20.108     0.000 6    104.45.210.69:1160  ->
>>>> x.x.231:22    ......      1
>>>> 2016-02-29 14:55:20.611     0.000 6    104.45.210.69:1161  ->
>>>> x.x.231:22    ......      1
>>>> 2016-02-29 14:56:41.004     0.000 6     40.76.55.204:1090  ->
>>>> x.x..14:22    ......      1
>>>> 2016-02-29 14:56:41.324     0.000 6     40.76.55.204:1091  ->
>>>> x.x..14:22    ......      1
>>>> 2016-02-29 15:00:05.670     0.000 6     40.76.55.204:1088  ->
>>>> x.x.125:22    ......      1
>>>> 2016-02-29 15:00:06.003     0.000 6     40.76.55.204:1089  ->
>>>> x.x.125:22    ......      1
>>>> 2016-02-29 15:01:17.358     0.000 6      40.76.70.58:1168  ->
>>>> x.x..80:22    ......      1
>>>> 2016-02-29 15:01:17.676     0.000 6      40.76.70.58:1169  ->
>>>> x.x..80:22    ......      1
>>>> 2016-02-29 15:02:42.637     0.000 6     40.76.55.204:1176  ->
>>>> x.x.193:22    ......      1
>>>> 2016-02-29 15:02:42.878     0.000 6     40.76.55.204:1177  ->
>>>> x.x.193:22    ......      1
>>>> 2016-02-29 15:02:48.067     0.000 6    104.45.210.69:1160  ->
>>>> x.x.173:22    ......      1
>>>> 2016-02-29 15:02:48.394     0.000 6    104.45.210.69:1161  ->
>>>> x.x.173:22    ......      1
>>>> 2016-02-29 15:03:18.854     0.000 6    40.121.53.153:1041  ->
>>>> x.x..88:22    ......      1
>>>> 2016-02-29 15:03:19.172     0.000 6    40.121.53.153:1042  ->
>>>> x.x..88:22    ......      1
>>>> 2016-02-29 15:06:36.248     0.000 6     40.76.55.204:1056  ->
>>>> x.x..45:22    ......      1
>>>> 2016-02-29 15:07:31.882     0.000 6      40.76.80.17:44895 ->
>>>> x.x..75:22    ......      1
>>>> 2016-02-29 15:07:32.245     0.000 6      40.76.80.17:44896 ->
>>>> x.x..75:22    ......      1
>>>> 2016-02-29 15:09:08.433     0.000 6      40.76.70.58:1168  ->
>>>> x.x..31:22    ......      1
>>>> 2016-02-29 15:09:08.744     0.000 6      40.76.70.58:1169  ->
>>>> x.x..31:22    ......      1
>>>> 2016-02-29 15:11:45.668     0.000 6      40.76.80.17:47993 ->
>>>> x.x.157:22    ......      1
>>>> 2016-02-29 15:11:45.987     0.000 6      40.76.80.17:47994 ->
>>>> x.x.157:22    ......      1
>>>> 2016-02-29 15:12:09.543     0.000 6      40.76.70.58:1168  ->
>>>> x.x..24:22    ......      1
>>>> 2016-02-29 15:12:09.925     0.000 6      40.76.70.58:1169  ->
>>>> x.x..24:22    ......      1
>>>> 2016-02-29 15:17:05.920     0.000 6      40.76.70.58:1168  ->
>>>> x.x.243:22    ......      1
>>>> 2016-02-29 15:17:06.241     0.000 6      40.76.70.58:1169  ->
>>>> x.x.243:22    ......      1
>>>> 2016-02-29 15:19:21.364     0.000 6    40.83.121.211:62936 ->
>>>> x.x..81:22    ......      1
>>>> 2016-02-29 15:19:21.704     0.000 6    40.83.121.211:62937 ->
>>>> x.x..81:22    ......      1
>>>> 2016-02-29 15:19:45.891     0.000 6      40.76.70.58:1168  ->
>>>> x.x..39:22    ......      1
>>>> 2016-02-29 15:19:46.273     0.000 6      40.76.70.58:1169  ->
>>>> x.x..39:22    ......      1
>>>> 2016-02-29 15:21:52.030     0.000 6      40.76.70.58:1168  ->
>>>> x.x.120:22    ......      1
>>>> 2016-02-29 15:21:52.349     0.000 6      40.76.70.58:1169  ->
>>>> x.x.120:22    ......      1
>>>> 2016-02-29 15:24:07.614     0.000 6     40.76.55.204:1048  ->
>>>> x.x.237:22    ......      1
>>>> 2016-02-29 15:24:07.933     0.000 6     40.76.55.204:1128  ->
>>>> x.x.237:22    ......      1
>>>> 2016-02-29 15:27:31.289     0.000 6    40.121.53.153:1041  ->
>>>> x.x.133:22    ......      1
>>>> 2016-02-29 15:27:31.544     0.000 6    40.121.53.153:1042  ->
>>>> x.x.133:22    ......      1
>>>> 2016-02-29 15:27:59.120     0.000 6      40.76.70.58:1168  ->
>>>> x.x.9.3:22    ......      1
>>>> 2016-02-29 15:27:59.440     0.000 6      40.76.70.58:1169  ->
>>>> x.x.9.3:22    ......      1
>>>> 2016-02-29 15:29:30.933     0.000 6      40.76.70.58:1168  ->
>>>> x.x.211:22    ......      1
>>>> 2016-02-29 15:29:31.031     0.000 6      40.76.70.58:1169  ->
>>>> x.x.211:22    ......      1
>>>> 2016-02-29 15:29:33.729     0.000 6     40.76.55.204:1142  ->
>>>> x.x.166:22    ......      1
>>>> 2016-02-29 15:29:34.032     0.000 6     40.76.55.204:1143  ->
>>>> x.x.166:22    ......      1
>>>> 2016-02-29 15:31:41.947     0.000 6      40.76.70.58:1168  ->
>>>> x.x.137:22    ......      1
>>>> 2016-02-29 15:31:42.266     0.000 6      40.76.70.58:1169  ->
>>>> x.x.137:22    ......      1
>>>> 2016-02-29 15:32:10.044     0.000 6    40.121.53.153:1041  ->
>>>> x.x..71:22    ......      1
>>>> 2016-02-29 15:32:10.348     0.000 6    40.121.53.153:1042  ->
>>>> x.x..71:22    ......      1
>>>> 2016-02-29 15:32:10.442     0.000 6    104.45.210.69:1161  ->
>>>> x.x.246:22    ......      1
>>>> 2016-02-29 15:32:10.475     0.000 6    104.45.210.69:1160  ->
>>>> x.x.246:22    ......      1
>>>> 2016-02-29 15:32:29.165     0.000 6   40.121.143.132:1040  ->
>>>> x.x..62:22    ......      1
>>>> 2016-02-29 15:32:29.466     0.000 6   40.121.143.132:1041  ->
>>>> x.x..62:22    ......      1
>>>> 2016-02-29 15:37:07.616     0.000 6      40.76.80.17:56902 ->
>>>> x.x..51:22    ......      1
>>>> 2016-02-29 15:37:07.925     0.000 6      40.76.80.17:56903 ->
>>>> x.x..51:22    ......      1
>>>> 2016-02-29 15:40:04.546     0.000 6    40.121.53.153:1041  ->
>>>> x.x.186:22    ......      1
>>>> 2016-02-29 15:40:04.866     0.000 6    40.121.53.153:1042  ->
>>>> x.x.186:22    ......      1
>>>> 2016-02-29 15:40:28.870     0.000 6      40.76.70.58:1168  ->
>>>> x.x.171:22    ......      1
>>>> 2016-02-29 15:40:29.125     0.000 6      40.76.70.58:1169  ->
>>>> x.x.171:22    ......      1
>>>> 2016-02-29 15:41:57.034     0.000 6     40.76.55.204:1128  ->
>>>> x.x.181:22    ......      1
>>>> 2016-02-29 15:41:57.354     0.000 6     40.76.55.204:1176  ->
>>>> x.x.181:22    ......      1
>>>> 
>>>> 
>>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>>>> x.x.163:22    ......      1
>>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>>>> x.x.176:22    ......      1
>>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>>>> x.x.206:22    ......      1
>>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
>>>> x.x.158:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.185:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.251:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.255:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.141:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.136:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.235:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.242:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.240:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.100:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.244:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x.217:22    ......      1
>>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
>>>> x.x..72:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.221:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.5.4:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.150:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.145:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.119:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x..52:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x..75:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.127:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x..22:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x..77:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.246:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x.137:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x..85:22    ......      1
>>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
>>>> x.x..35:22    ......      1
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 

-------------- 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/20160331/9bbbbf72/attachment.pgp>

From baconzombie at gmail.com  Thu Mar 31 09:36:51 2016
From: baconzombie at gmail.com (Bacon Zombie)
Date: Thu, 31 Mar 2016 11:36:51 +0200
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com>
References: <56FCD97D.8050201@yahoo.fr>
 <E141D8F9-B375-4DE7-A6F8-E2EF552D30B0@n5tech.com>
 <D0DF71A6-EFA7-4C19-A06F-7AC79F67A37A@n5tech.com>
 <Pine.LNX.4.64.1603310201030.11131@yuri.anime.net>
 <3B53B9D6-BAA3-48C9-82A7-049CC9049269@n5tech.com>
Message-ID: <CAPz7E50poGYZx0hh5EVVzjvbuNe77=qSqL82Yt7Ff8EQ2z4cmQ@mail.gmail.com>

I would ignore the portscans since there is nothing wrong with portscanning
the Internet.

Install fail2ban {don't forgot to whitelist your management static IPs}.

You may want to increase the default bantime and findtime {how far back to
search logs}.

On 31 Mar 2016 11:06, "Todd Crane" <todd.crane at n5tech.com> wrote:

> I must have missed that? my bad.
>
>
> > On Mar 31, 2016, at 2:01 AM, Dan Hollis <goemon at sasami.anime.net> wrote:
> >
> > It's right there in his email:
> >
> > "We have sent email to abuse at microsoft.com, but no answer."
> >
> > -Dan
> >
> > On Thu, 31 Mar 2016, Todd Crane wrote:
> >
> >> Oh and,
> >>
> >> I?m assuming you contacted Microsoft?s abuse? If not, it?s not cool,
> not to mention unprofessional, to publicly call them out on such a public
> forum without giving them an opportunity to correct it first.
> >>
> >>> On Mar 31, 2016, at 1:15 AM, Todd Crane <todd.crane at n5tech.com> wrote:
> >>>
> >>> Marcel
> >>>
> >>> Depending on what is on those machines, I would just recommend using
> fail2ban. The default is that if an ip address fails ssh auth 3 times in 5
> minutes, their ip gets blocked via iptables for 5 minutes. This is enough
> to thwart most scripted attacks, especially those from a certain government
> in Asia. This is configurable to various applications, timing schemes, and
> blocking/jailing mechanisms.
> >>>
> >>> -Todd
> >>>> On Mar 31, 2016, at 1:02 AM, marcel.duregards--- via NANOG <
> nanog at nanog.org> wrote:
> >>>>
> >>>> Dear Nanog'er,
> >>>>
> >>>> We are facing a lot of port scan and brute force attack on port 22
> (but
> >>>> not limited to) from Microsoft AS 8075 range toward our own infra, or
> >>>> toward our customers.
> >>>> We have sent email to abuse at microsoft.com, but no answer.
> >>>>
> >>>> source ip are:
> >>>> NetRange:       40.74.0.0 - 40.125.127.255
> >>>> CIDR:           40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16,
> >>>> 40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12,
> 40.120.0.0/14
> >>>> NetName:        MSFT
> >>>>
> >>>>
> >>>>
> >>>> We consider port scan and brute force on ssh port as an attack, and
> even
> >>>> as a pre-DDOS phase (could be use to install botnet, detect unpatched
> >>>> host, and so one).
> >>>>
> >>>> It's one thing to propose services and make money over an infra, it's
> an
> >>>> other thing to take care that you clients do not use this infra to
> make
> >>>> illegal stuffs.
> >>>>
> >>>>
> >>>> How do you deal with such massive amount of 'illegal' traffic ?
> >>>>
> >>>> Thank,
> >>>> Best Regards
> >>>> Marcel
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> He are some examples (we have more than 3000 such packets per day just
> >>>> from them, probably Azure), and source ip is always differents of
> course:
> >>>>
> >>>>
> >>>> Flow Filtering Expression
> >>>> src AS 8075 and dst port 22 and packets=1
> >>>> Limit Flows
> >>>> 40000
> >>>> Sorting
> >>>> By Date
> >>>>
> >>>> Date_first_seen          Duration Proto     _IP_Addr:Port
> >>>> Dst_IP_Addr:Port   Flags Packets
> >>>> 2016-02-29 14:55:20.108     0.000 6    104.45.210.69:1160  ->
> >>>> x.x.231:22    ......      1
> >>>> 2016-02-29 14:55:20.611     0.000 6    104.45.210.69:1161  ->
> >>>> x.x.231:22    ......      1
> >>>> 2016-02-29 14:56:41.004     0.000 6     40.76.55.204:1090  ->
> >>>> x.x..14:22    ......      1
> >>>> 2016-02-29 14:56:41.324     0.000 6     40.76.55.204:1091  ->
> >>>> x.x..14:22    ......      1
> >>>> 2016-02-29 15:00:05.670     0.000 6     40.76.55.204:1088  ->
> >>>> x.x.125:22    ......      1
> >>>> 2016-02-29 15:00:06.003     0.000 6     40.76.55.204:1089  ->
> >>>> x.x.125:22    ......      1
> >>>> 2016-02-29 15:01:17.358     0.000 6      40.76.70.58:1168  ->
> >>>> x.x..80:22    ......      1
> >>>> 2016-02-29 15:01:17.676     0.000 6      40.76.70.58:1169  ->
> >>>> x.x..80:22    ......      1
> >>>> 2016-02-29 15:02:42.637     0.000 6     40.76.55.204:1176  ->
> >>>> x.x.193:22    ......      1
> >>>> 2016-02-29 15:02:42.878     0.000 6     40.76.55.204:1177  ->
> >>>> x.x.193:22    ......      1
> >>>> 2016-02-29 15:02:48.067     0.000 6    104.45.210.69:1160  ->
> >>>> x.x.173:22    ......      1
> >>>> 2016-02-29 15:02:48.394     0.000 6    104.45.210.69:1161  ->
> >>>> x.x.173:22    ......      1
> >>>> 2016-02-29 15:03:18.854     0.000 6    40.121.53.153:1041  ->
> >>>> x.x..88:22    ......      1
> >>>> 2016-02-29 15:03:19.172     0.000 6    40.121.53.153:1042  ->
> >>>> x.x..88:22    ......      1
> >>>> 2016-02-29 15:06:36.248     0.000 6     40.76.55.204:1056  ->
> >>>> x.x..45:22    ......      1
> >>>> 2016-02-29 15:07:31.882     0.000 6      40.76.80.17:44895 ->
> >>>> x.x..75:22    ......      1
> >>>> 2016-02-29 15:07:32.245     0.000 6      40.76.80.17:44896 ->
> >>>> x.x..75:22    ......      1
> >>>> 2016-02-29 15:09:08.433     0.000 6      40.76.70.58:1168  ->
> >>>> x.x..31:22    ......      1
> >>>> 2016-02-29 15:09:08.744     0.000 6      40.76.70.58:1169  ->
> >>>> x.x..31:22    ......      1
> >>>> 2016-02-29 15:11:45.668     0.000 6      40.76.80.17:47993 ->
> >>>> x.x.157:22    ......      1
> >>>> 2016-02-29 15:11:45.987     0.000 6      40.76.80.17:47994 ->
> >>>> x.x.157:22    ......      1
> >>>> 2016-02-29 15:12:09.543     0.000 6      40.76.70.58:1168  ->
> >>>> x.x..24:22    ......      1
> >>>> 2016-02-29 15:12:09.925     0.000 6      40.76.70.58:1169  ->
> >>>> x.x..24:22    ......      1
> >>>> 2016-02-29 15:17:05.920     0.000 6      40.76.70.58:1168  ->
> >>>> x.x.243:22    ......      1
> >>>> 2016-02-29 15:17:06.241     0.000 6      40.76.70.58:1169  ->
> >>>> x.x.243:22    ......      1
> >>>> 2016-02-29 15:19:21.364     0.000 6    40.83.121.211:62936 ->
> >>>> x.x..81:22    ......      1
> >>>> 2016-02-29 15:19:21.704     0.000 6    40.83.121.211:62937 ->
> >>>> x.x..81:22    ......      1
> >>>> 2016-02-29 15:19:45.891     0.000 6      40.76.70.58:1168  ->
> >>>> x.x..39:22    ......      1
> >>>> 2016-02-29 15:19:46.273     0.000 6      40.76.70.58:1169  ->
> >>>> x.x..39:22    ......      1
> >>>> 2016-02-29 15:21:52.030     0.000 6      40.76.70.58:1168  ->
> >>>> x.x.120:22    ......      1
> >>>> 2016-02-29 15:21:52.349     0.000 6      40.76.70.58:1169  ->
> >>>> x.x.120:22    ......      1
> >>>> 2016-02-29 15:24:07.614     0.000 6     40.76.55.204:1048  ->
> >>>> x.x.237:22    ......      1
> >>>> 2016-02-29 15:24:07.933     0.000 6     40.76.55.204:1128  ->
> >>>> x.x.237:22    ......      1
> >>>> 2016-02-29 15:27:31.289     0.000 6    40.121.53.153:1041  ->
> >>>> x.x.133:22    ......      1
> >>>> 2016-02-29 15:27:31.544     0.000 6    40.121.53.153:1042  ->
> >>>> x.x.133:22    ......      1
> >>>> 2016-02-29 15:27:59.120     0.000 6      40.76.70.58:1168  ->
> >>>> x.x.9.3:22    ......      1
> >>>> 2016-02-29 15:27:59.440     0.000 6      40.76.70.58:1169  ->
> >>>> x.x.9.3:22    ......      1
> >>>> 2016-02-29 15:29:30.933     0.000 6      40.76.70.58:1168  ->
> >>>> x.x.211:22    ......      1
> >>>> 2016-02-29 15:29:31.031     0.000 6      40.76.70.58:1169  ->
> >>>> x.x.211:22    ......      1
> >>>> 2016-02-29 15:29:33.729     0.000 6     40.76.55.204:1142  ->
> >>>> x.x.166:22    ......      1
> >>>> 2016-02-29 15:29:34.032     0.000 6     40.76.55.204:1143  ->
> >>>> x.x.166:22    ......      1
> >>>> 2016-02-29 15:31:41.947     0.000 6      40.76.70.58:1168  ->
> >>>> x.x.137:22    ......      1
> >>>> 2016-02-29 15:31:42.266     0.000 6      40.76.70.58:1169  ->
> >>>> x.x.137:22    ......      1
> >>>> 2016-02-29 15:32:10.044     0.000 6    40.121.53.153:1041  ->
> >>>> x.x..71:22    ......      1
> >>>> 2016-02-29 15:32:10.348     0.000 6    40.121.53.153:1042  ->
> >>>> x.x..71:22    ......      1
> >>>> 2016-02-29 15:32:10.442     0.000 6    104.45.210.69:1161  ->
> >>>> x.x.246:22    ......      1
> >>>> 2016-02-29 15:32:10.475     0.000 6    104.45.210.69:1160  ->
> >>>> x.x.246:22    ......      1
> >>>> 2016-02-29 15:32:29.165     0.000 6   40.121.143.132:1040  ->
> >>>> x.x..62:22    ......      1
> >>>> 2016-02-29 15:32:29.466     0.000 6   40.121.143.132:1041  ->
> >>>> x.x..62:22    ......      1
> >>>> 2016-02-29 15:37:07.616     0.000 6      40.76.80.17:56902 ->
> >>>> x.x..51:22    ......      1
> >>>> 2016-02-29 15:37:07.925     0.000 6      40.76.80.17:56903 ->
> >>>> x.x..51:22    ......      1
> >>>> 2016-02-29 15:40:04.546     0.000 6    40.121.53.153:1041  ->
> >>>> x.x.186:22    ......      1
> >>>> 2016-02-29 15:40:04.866     0.000 6    40.121.53.153:1042  ->
> >>>> x.x.186:22    ......      1
> >>>> 2016-02-29 15:40:28.870     0.000 6      40.76.70.58:1168  ->
> >>>> x.x.171:22    ......      1
> >>>> 2016-02-29 15:40:29.125     0.000 6      40.76.70.58:1169  ->
> >>>> x.x.171:22    ......      1
> >>>> 2016-02-29 15:41:57.034     0.000 6     40.76.55.204:1128  ->
> >>>> x.x.181:22    ......      1
> >>>> 2016-02-29 15:41:57.354     0.000 6     40.76.55.204:1176  ->
> >>>> x.x.181:22    ......      1
> >>>>
> >>>>
> >>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.163:22    ......      1
> >>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.176:22    ......      1
> >>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.206:22    ......      1
> >>>> 2016-02-29 16:55:49.183     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.158:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.185:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.251:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.255:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.141:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.136:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.235:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.242:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.240:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.100:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.244:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.217:22    ......      1
> >>>> 2016-02-29 16:55:49.186     0.000 6    40.117.96.192:1120  ->
> >>>> x.x..72:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.221:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.5.4:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.150:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.145:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.119:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x..52:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x..75:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.127:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x..22:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x..77:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.246:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x.137:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x..85:22    ......      1
> >>>> 2016-02-29 16:55:49.187     0.000 6    40.117.96.192:1120  ->
> >>>> x.x..35:22    ......      1
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
>
>

From marcel.duregards at yahoo.fr  Thu Mar 31 09:50:47 2016
From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr)
Date: Thu, 31 Mar 2016 11:50:47 +0200
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <D0DF71A6-EFA7-4C19-A06F-7AC79F67A37A@n5tech.com>
References: <56FCD97D.8050201@yahoo.fr>
 <E141D8F9-B375-4DE7-A6F8-E2EF552D30B0@n5tech.com>
 <D0DF71A6-EFA7-4C19-A06F-7AC79F67A37A@n5tech.com>
Message-ID: <56FCF2F7.9060709@yahoo.fr>

I can not blame them to not answer to all of the thousands emails
destined to their abuse mailbox. And the goal of my email was not to
call them on public forum, but rather to know how others ops deal with
it, and also if MS (and competitors) have automatic detection of such
'illegal' traffic, and if not why ?....





On 31.03.2016 10:18, Todd Crane wrote:
> Oh and,
> 
> I?m assuming you contacted Microsoft?s abuse? If not, it?s not cool, not to mention unprofessional, to publicly call them out on such a public forum without giving them an opportunity to correct it first.
> 
>> On Mar 31, 2016, at 1:15 AM, Todd Crane <todd.crane at n5tech.com> wrote:
>>
>> Marcel
>>
>> Depending on what is on those machines, I would just recommend using fail2ban. The default is that if an ip address fails ssh auth 3 times in 5 minutes, their ip gets blocked via iptables for 5 minutes. This is enough to thwart most scripted attacks, especially those from a certain government in Asia. This is configurable to various applications, timing schemes, and blocking/jailing mechanisms.
>>
>> -Todd
>>> On Mar 31, 2016, at 1:02 AM, marcel.duregards--- via NANOG <nanog at nanog.org> wrote:
>>>
>>> Dear Nanog'er,
>>>
>>> We are facing a lot of port scan and brute force attack on port 22 (but
>>> not limited to) from Microsoft AS 8075 range toward our own infra, or
>>> toward our customers.
>>> We have sent email to abuse at microsoft.com, but no answer.
>>>
>>> source ip are:
>>> NetRange:       40.74.0.0 - 40.125.127.255
>>> CIDR:           40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16,
>>> 40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12, 40.120.0.0/14
>>> NetName:        MSFT
>>>
>>>
>>>
>>> We consider port scan and brute force on ssh port as an attack, and even
>>> as a pre-DDOS phase (could be use to install botnet, detect unpatched
>>> host, and so one).
>>>
>>> It's one thing to propose services and make money over an infra, it's an
>>> other thing to take care that you clients do not use this infra to make
>>> illegal stuffs.
>>>
>>>
>>> How do you deal with such massive amount of 'illegal' traffic ?
>>>
>>> Thank,
>>> Best Regards
>>> Marcel
>>>
>>>
>>>
>>>
>>>
>>> He are some examples (we have more than 3000 such packets per day just
>>> from them, probably Azure), and source ip is always differents of course:
>>>
>>>
>>> Flow Filtering Expression
>>> src AS 8075 and dst port 22 and packets=1
>>> Limit Flows
>>> 40000
>>> Sorting
>>> By Date
>>>

>>
> 

From jsklein at gmail.com  Thu Mar 31 12:27:55 2016
From: jsklein at gmail.com (Joe Klein)
Date: Thu, 31 Mar 2016 08:27:55 -0400
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <56FCDA9B.7020803@ripe.net>
References: <56FCD97D.8050201@yahoo.fr> <56FCDA9B.7020803@ripe.net>
Message-ID: <CAP032TtFfDCWe9ebOhjwtaDMJHY491R8kPM-Z6E7AWq_yNw27g@mail.gmail.com>

Use IPv6, bind a second address to the device. Enable on a random port, on
this new address. Remove ssh from the other IP address.

Joe Klein
"Inveniam viam aut faciam"

PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8

On Thu, Mar 31, 2016 at 4:06 AM, Robert Kisteleki <robert at ripe.net> wrote:

>
> > How do you deal with such massive amount of 'illegal' traffic ?
>
> Move SSH to a different port. Better yet, use IPv6 only :-)
>
> Robert
>

From Valdis.Kletnieks at vt.edu  Thu Mar 31 14:20:03 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 31 Mar 2016 10:20:03 -0400
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <56FCD97D.8050201@yahoo.fr>
References: <56FCD97D.8050201@yahoo.fr>
Message-ID: <5370.1459434003@turing-police.cc.vt.edu>

On Thu, 31 Mar 2016 10:02:05 +0200, "marcel.duregards--- via NANOG" said:

> We consider port scan and brute force on ssh port as an attack, and even

So explain to me why you don't have ACLs that silently drop inbound SYN
packets on port 22 from outside your allocated address space?  (And if
you can't do it at your border because you sub-allocate address space
to customers, figure out how to use iptables or similar to block it on
the target hosts, or only apply the ACL for your own subnets).

If you have a *legitimate* business case for needing to SSH in from outside,
there are fine products such as OpenVPN (and not-so-fine like the one we
have in production - although it's mostly usable too, and achieves the goal
of presenting you as being inside our corporate address space)

Also, move your SSH service to some port other than 22, and consider
putting 'Password Authentication no/PubKeyAuthentication yes' in your
sshd_config.

I admit never understanding why people run their systems in a low-hanging
fruit configuration, and then are surprised that miscreants go looking for
low hanging fruit.

(For the record, our border routers drop inbound SYN on port 22 on *both*
ipv4 and ipv6 address spaces.  It's amazing how few brute force
attempts we see on our servers... :)
-------------- 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/20160331/2436058b/attachment.pgp>

From nanogml at Mail.DDoS-Mitigator.net  Thu Mar 31 15:14:17 2016
From: nanogml at Mail.DDoS-Mitigator.net (alvin nanog)
Date: Thu, 31 Mar 2016 08:14:17 -0700
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <5370.1459434003@turing-police.cc.vt.edu>
References: <56FCD97D.8050201@yahoo.fr>
 <5370.1459434003@turing-police.cc.vt.edu>
Message-ID: <20160331151416.GA5804@Mail.DDoS-Mitigator.net>


hi nanog'ers

On 03/31/16 at 10:20am, Valdis.Kletnieks at vt.edu wrote:
> On Thu, 31 Mar 2016 10:02:05 +0200, "marcel.duregards--- via NANOG" said:
> 
> > We consider port scan and brute force on ssh port as an attack, and even
 
...
> (For the record, our border routers drop inbound SYN on port 22 on *both*
> ipv4 and ipv6 address spaces.  It's amazing how few brute force
> attempts we see on our servers... :)

i think the best way, ( imho ) to discourage random incoming ssh connections
or anything else ( tcp-based ) is to run tarpit on ALL tcp based ports ... 
	one obviously would allow incoming 25/tcp traffic to mail servers
	and incoming 80/tcp to web servers, etc etc, but otherwise, all
	other incoming tcp ports gets unconditionally tarpit'd

	we used to get hundreds of thousands of garbage tcp connections per minute
	which basically disappeared after running tarpits as needed

	and the attackers ( port scanners ) pay a penalty for sending useless
	packets to tarpit'd ports

fail2ban/etc is okay but it's too limited since i want to deny all tcp connections
and specifically only allow certain incoming traffic which is trivial to 
implement with iptables + tarpits

/dev/null incoming packets is okay but it still occupied time/space/buffers
in the pipe and the attackers didn't feel any pain for sending the packets

doing ddos mitigation for your own IP# space is fairly easy to create
various policies ... doing the ddos mitigation for your customers down
the line using your routers can be tricky business and very messy if
either the customer nor isp doesn't change something ( aka more $$$ )

magic pixie dust
alvin
DDoS-Mitigator.net


From jabley at hopcount.ca  Thu Mar 31 20:18:49 2016
From: jabley at hopcount.ca (Joe Abley)
Date: Thu, 31 Mar 2016 16:18:49 -0400
Subject: shipping from US to Telstra (ex-Pacnet) facility, 11 Chun Kwong St,
 Hong Kong
Message-ID: <FEE385C3-ACF5-47C0-A426-572010AC3BC1@hopcount.ca>

Hi all,

If anybody has recently managed to ship equipment from the US to the Pacnet (now Telstra) facility at 11 Chun Kwong St, Hong Kong and doesn't mind comparing notes, any chance you could drop me a line off-list?

We have some shipping confusion, and it would be great to see an example of paperwork that is known not to have failed.

Thanks,


Joe


From baldur.norddahl at gmail.com  Thu Mar 31 23:38:31 2016
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Fri, 1 Apr 2016 01:38:31 +0200
Subject: Capacity planning , transit vs last mile
In-Reply-To: <56FCC8D4.1040806@vaxination.ca>
References: <56FCC8D4.1040806@vaxination.ca>
Message-ID: <CAPkb-7C-mFj_obxxYgSuLyGtNEpykm8MmaMb6my7qCkHafUTNg@mail.gmail.com>

You will find that total data download per month is unrelated to service
speed except for very slow service.

If you have too few users the pattern becomes chaotic.
Den 31/03/2016 08.52 skrev "Jean-Francois Mezei" <
jfmezei_nanog at vaxination.ca>:

>
> Canada is to hold a 3 week long hearing on discussing whether the
> internet is important and whether the farcical 5/1 speed promoted by the
> government is adequate.
>
> In this day and age, it would be easy to just set FTTP as target
> technology and be done with it, but too many want to have a policy that
> is technologically neutral.
>
> To this end, I will not only be proposing that subsidized deployments
> not only meet advertised service speed standards, but also a capacity
> per end user metric for the last mile technology  as well as for the
> backhaul/transit.
>
> (One of the often subsidized companies deploys fixed wireless which
> delivers the advertised speed for the first week, but routinely gets
> oversubscribed after a while and customers feel like on dialup.)
>
>
> I know that for sufficiently large ISPs, they currently provision just
> over 1mbps of transit capacity per end user (so 800-1000 customers per
> 1gbps of transit). The number rises by over 30% a year as usage grows.
> (The CRTC can get exact figure from telecom operators and generate
> aggregate industry-wide growth in traffic to do yearly standard
> adjustment).
>
> QUESTION:
>
> Say the policy is 1mbps per customer if 1000 customer or more.  Is there
> some formula (approx or precise) to calculate how that 1mbps changes for
> smaller samples ? (like 500 customers, 200 ? )
>
>
>
> And on the last mile portion where one has typically few users on each
> shared capacity segment (fixed wireless, FTTP, cable), are there fairly
> standard oversubscription ratios based on average service speed that is
> sold in that neighbourhood ? (for instance if I have 100 customers with
> average subscibed speed of 15mbps, how much capacity should the antenna
> serving those customers have ?
>
>
> I realise that each ISP guards its oversubscription ratios as very
> proprietary, but aren't there generic industry-wide recommendations ? My
> goal is to have some basic standards that prevent gross over
> subscription that result in unusable service.
>
> As well, I want that a company pitching a broadband deployment be able
> to demonstrate that the technology being deployed will last X years
> because it has sufficient capacity to handle the number  of customers as
> well as the predicted growth in usage each year.
>
>
> Any help ? comments on whether this is crazy ? sanity check ?
>
>
>
>
>
>

From jason.m.lee at gmail.com  Tue Mar 29 12:23:41 2016
From: jason.m.lee at gmail.com (Jason Lee)
Date: Tue, 29 Mar 2016 07:23:41 -0500
Subject: Colocation Server Lifts
Message-ID: <CABD5cRfNExPSjm6tQj5ARnwQiL-BXCFPJS=q232LvyWZ1QEjCw@mail.gmail.com>

Hi NANOG community,

A few questions I have for the community regarding server lifts at colo
facilities.

1. Is a server lift something you would typically expect a colo facility to
provide?

if yes,

2. Do colo facilities typically allow customers to just use them or provide
an operator?
3. Is it a free offering or something they rent out?
4. What would be the typical device weight you would lift?
5. What would be the max device weight you would lift?

Thanks,

Jason

From magicboiz at hotmail.com  Thu Mar 31 08:12:07 2016
From: magicboiz at hotmail.com (magicboiz at hotmail.com)
Date: Thu, 31 Mar 2016 10:12:07 +0200
Subject: Some doubts on large scale BGP/AS design and black hole routing risk
Message-ID: <BLU436-SMTP4563E5D7AB798A68A82915B0990@phx.gbl>

Hi everybody!


as part of laboratory work at the university,  I'm working on a BGP 
design study, and I would like to post some questions regarding IP 
address space allocation and its impact on BGP which are breaking my mind :)

Let's suppose we have an ISP/AS with two POPs: PARIS and LONDON. These 
two POPs are connected with redundant leased lines. Each POP has a BGP 
router speaking eBGP to different ISP providers/upstreams and also, each 
POP run its own OSPF area/ISIS area. Something like this:


  <INET> ---eBGP---<LONDON POP-ospf area1>===redundant leased lines 
(ospf area0)===<PARIS POP- ospf area2>---eBGP---<INET>

Now, this AS/ISP gets one /22 prefix from it RIR (RIPE in this case), 
and starts to announce it to its upstreams in PARIS and LONDON at the 
same time.


My questions are:

1. What could happen in the case of total failure in the redundant 
leased lines? Black hole routing between POPs?

2. What are the best design methods to avoid this scenario?

    2.1: adding a third POP creating a triangle? What if a POP looses 
connection with the other two POPs at the same time? Another black hole?

    2.2: requesting another prefix and allocating 1:1 prefix:POP, so in 
the scenario each POP only would announce its prefix to the upstreams?

    2.3: other?



Thanks in advance!
J.


From iamzam at gmail.com  Thu Mar 31 11:41:10 2016
From: iamzam at gmail.com (DV)
Date: Thu, 31 Mar 2016 07:41:10 -0400
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <56FCF2F7.9060709@yahoo.fr>
References: <56FCD97D.8050201@yahoo.fr>
 <E141D8F9-B375-4DE7-A6F8-E2EF552D30B0@n5tech.com>
 <D0DF71A6-EFA7-4C19-A06F-7AC79F67A37A@n5tech.com> <56FCF2F7.9060709@yahoo.fr>
Message-ID: <CAEiuvJCzSVuvL4ZzYpOzKiye7Efib1dNct+ToPMf7h6phA+8Qg@mail.gmail.com>

I have noticed this and especially the strange format of the packets with a
SYN/ECE/CWR flag combination: http://pastebin.com/jFCDAmdr

This may be $whoever trying to establish network performance/congestion via
ECN or it could be something else like a fast scan technique or OS
fingerprinting


On Thu, Mar 31, 2016 at 5:50 AM, marcel.duregards--- via NANOG <
nanog at nanog.org> wrote:

> I can not blame them to not answer to all of the thousands emails
> destined to their abuse mailbox. And the goal of my email was not to
> call them on public forum, but rather to know how others ops deal with
> it, and also if MS (and competitors) have automatic detection of such
> 'illegal' traffic, and if not why ?....
>
>
>
>
>
> On 31.03.2016 10:18, Todd Crane wrote:
> > Oh and,
> >
> > I?m assuming you contacted Microsoft?s abuse? If not, it?s not cool, not
> to mention unprofessional, to publicly call them out on such a public forum
> without giving them an opportunity to correct it first.
> >
> >> On Mar 31, 2016, at 1:15 AM, Todd Crane <todd.crane at n5tech.com> wrote:
> >>
> >> Marcel
> >>
> >> Depending on what is on those machines, I would just recommend using
> fail2ban. The default is that if an ip address fails ssh auth 3 times in 5
> minutes, their ip gets blocked via iptables for 5 minutes. This is enough
> to thwart most scripted attacks, especially those from a certain government
> in Asia. This is configurable to various applications, timing schemes, and
> blocking/jailing mechanisms.
> >>
> >> -Todd
> >>> On Mar 31, 2016, at 1:02 AM, marcel.duregards--- via NANOG <
> nanog at nanog.org> wrote:
> >>>
> >>> Dear Nanog'er,
> >>>
> >>> We are facing a lot of port scan and brute force attack on port 22 (but
> >>> not limited to) from Microsoft AS 8075 range toward our own infra, or
> >>> toward our customers.
> >>> We have sent email to abuse at microsoft.com, but no answer.
> >>>
> >>> source ip are:
> >>> NetRange:       40.74.0.0 - 40.125.127.255
> >>> CIDR:           40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16,
> >>> 40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12, 40.120.0.0/14
> >>> NetName:        MSFT
> >>>
> >>>
> >>>
> >>> We consider port scan and brute force on ssh port as an attack, and
> even
> >>> as a pre-DDOS phase (could be use to install botnet, detect unpatched
> >>> host, and so one).
> >>>
> >>> It's one thing to propose services and make money over an infra, it's
> an
> >>> other thing to take care that you clients do not use this infra to make
> >>> illegal stuffs.
> >>>
> >>>
> >>> How do you deal with such massive amount of 'illegal' traffic ?
> >>>
> >>> Thank,
> >>> Best Regards
> >>> Marcel
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> He are some examples (we have more than 3000 such packets per day just
> >>> from them, probably Azure), and source ip is always differents of
> course:
> >>>
> >>>
> >>> Flow Filtering Expression
> >>> src AS 8075 and dst port 22 and packets=1
> >>> Limit Flows
> >>> 40000
> >>> Sorting
> >>> By Date
> >>>
>
> >>
> >
>

From diotonante at gmail.com  Thu Mar 31 13:19:32 2016
From: diotonante at gmail.com (Davide Davini)
Date: Thu, 31 Mar 2016 15:19:32 +0200
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <56FCD97D.8050201@yahoo.fr>
References: <56FCD97D.8050201@yahoo.fr>
Message-ID: <56FD23E4.2030201@gmail.com>

On 31/03/2016 10:02, marcel.duregards--- via NANOG wrote:
> We are facing a lot of port scan and brute force attack on port 22 (but
> not limited to)

Maybe not super useful in your case but talking about SSH the sysadmin
solution would be to disable password login and use just keys.

Also, as someone else said, fail2ban... because it's a lot of fun. :)

Ciao,
Davide



From ramirezcyrus at yahoo.com  Thu Mar 31 14:56:16 2016
From: ramirezcyrus at yahoo.com (cyrus ramirez)
Date: Thu, 31 Mar 2016 14:56:16 +0000 (UTC)
Subject: how to deal with port scan and brute force attack from AS 8075 ?
In-Reply-To: <5370.1459434003@turing-police.cc.vt.edu>
References: <56FCD97D.8050201@yahoo.fr>
 <5370.1459434003@turing-police.cc.vt.edu>
Message-ID: <1099146124.272730.1459436176440.JavaMail.yahoo@mail.yahoo.com>

You could use Shields Up to view your vulnerabilities... obvious ones, and remedy...?Cyrus Ramirez

 

    On Thursday, March 31, 2016 10:21 AM, "Valdis.Kletnieks at vt.edu" <Valdis.Kletnieks at vt.edu> wrote:
 

 On Thu, 31 Mar 2016 10:02:05 +0200, "marcel.duregards--- via NANOG" said:

> We consider port scan and brute force on ssh port as an attack, and even

So explain to me why you don't have ACLs that silently drop inbound SYN
packets on port 22 from outside your allocated address space?? (And if
you can't do it at your border because you sub-allocate address space
to customers, figure out how to use iptables or similar to block it on
the target hosts, or only apply the ACL for your own subnets).

If you have a *legitimate* business case for needing to SSH in from outside,
there are fine products such as OpenVPN (and not-so-fine like the one we
have in production - although it's mostly usable too, and achieves the goal
of presenting you as being inside our corporate address space)

Also, move your SSH service to some port other than 22, and consider
putting 'Password Authentication no/PubKeyAuthentication yes' in your
sshd_config.

I admit never understanding why people run their systems in a low-hanging
fruit configuration, and then are surprised that miscreants go looking for
low hanging fruit.

(For the record, our border routers drop inbound SYN on port 22 on *both*
ipv4 and ipv6 address spaces.? It's amazing how few brute force
attempts we see on our servers... :)


  

From takashi.tome at gmail.com  Thu Mar 31 11:45:09 2016
From: takashi.tome at gmail.com (takashi tome)
Date: Thu, 31 Mar 2016 08:45:09 -0300
Subject: Capacity planning , transit vs last mile
In-Reply-To: <56FCC8D4.1040806@vaxination.ca>
References: <56FCC8D4.1040806@vaxination.ca>
Message-ID: <CAJEcmSkaeUpjA3pGotgMUbZ_JiKN6KgR=HBze4Tfp371uU977Q@mail.gmail.com>

Like. Good question.
There are a lot of papers on traffic model, but it is still an open issue...

takashi.tome


2016-03-31 3:51 GMT-03:00 Jean-Francois Mezei <jfmezei_nanog at vaxination.ca>:

>
> Canada is to hold a 3 week long hearing on discussing whether the
> internet is important and whether the farcical 5/1 speed promoted by the
> government is adequate.
>
> In this day and age, it would be easy to just set FTTP as target
> technology and be done with it, but too many want to have a policy that
> is technologically neutral.
>
> To this end, I will not only be proposing that subsidized deployments
> not only meet advertised service speed standards, but also a capacity
> per end user metric for the last mile technology  as well as for the
> backhaul/transit.
>
> (One of the often subsidized companies deploys fixed wireless which
> delivers the advertised speed for the first week, but routinely gets
> oversubscribed after a while and customers feel like on dialup.)
>
>
> I know that for sufficiently large ISPs, they currently provision just
> over 1mbps of transit capacity per end user (so 800-1000 customers per
> 1gbps of transit). The number rises by over 30% a year as usage grows.
> (The CRTC can get exact figure from telecom operators and generate
> aggregate industry-wide growth in traffic to do yearly standard
> adjustment).
>
> QUESTION:
>
> Say the policy is 1mbps per customer if 1000 customer or more.  Is there
> some formula (approx or precise) to calculate how that 1mbps changes for
> smaller samples ? (like 500 customers, 200 ? )
>
>
>
> And on the last mile portion where one has typically few users on each
> shared capacity segment (fixed wireless, FTTP, cable), are there fairly
> standard oversubscription ratios based on average service speed that is
> sold in that neighbourhood ? (for instance if I have 100 customers with
> average subscibed speed of 15mbps, how much capacity should the antenna
> serving those customers have ?
>
>
> I realise that each ISP guards its oversubscription ratios as very
> proprietary, but aren't there generic industry-wide recommendations ? My
> goal is to have some basic standards that prevent gross over
> subscription that result in unusable service.
>
> As well, I want that a company pitching a broadband deployment be able
> to demonstrate that the technology being deployed will last X years
> because it has sufficient capacity to handle the number  of customers as
> well as the predicted growth in usage each year.
>
>
> Any help ? comments on whether this is crazy ? sanity check ?
>
>
>
>
>
>